security

Security

Last updated May 11, 2026.

We treat your data and your candidates' data with care. This page is a plain-language summary of our security posture; ask security@imast.ai for the full technical write-up under NDA.

1. Infrastructure

imast.ai is a marketing site on Cloudflare Workers; the imast app runs on Google Cloud Run with Cloud SQL Postgres in europe-west1. App compute scales to zero between requests; we operate no long-running on-premise servers.

Database, object storage, and worker traffic are encrypted at rest (AES-256) and in transit (TLS 1.3). Backups are automated and replicated across regions.

Production environments are isolated from staging and developer environments at the infrastructure level.

2. Authentication

Sign-in uses Google OAuth, LinkedIn OIDC, or email + password (with verification) via Better Auth. Email + password credentials are stored as bcrypt hashes; we never store plaintext passwords.

Sessions are short-lived and rotated on each privileged action.

Internal admin access uses least-privilege IAM on Google Cloud and Cloudflare.

3. Secrets and keys

API keys, OAuth client secrets, and service-account keys live in Google Cloud Secret Manager and Cloudflare Workers Secrets, not in source. Rotation is annual or on incident.

Customer-supplied API keys (BYOK and Greenhouse Harvest) are encrypted at rest with AES-256-GCM under a Key Encryption Key managed by Secret Manager. We never write secrets to logs and we redact any incidental capture before persistence.

4. Application

CSRF, clickjacking, and content-type sniffing are mitigated by strict headers (HSTS, X-Frame-Options DENY, Referrer-Policy, X-Content-Type-Options).

Outbound calls to LLM, search, and email providers go through narrow allowlists.

Code review and a CI test suite gate every deployment.

5. Data isolation

Tenants are isolated at the database row level by user_id. The agent runtime never receives more than the requesting tenant's rows.

No customer data is used to train models. Prompts and completions are not logged with provider partners beyond what is needed for billing reconciliation.

6. Sub-processors

We publish our sub-processor list in the Privacy Policy and notify customers in advance of changes. Each sub-processor has a current DPA and SOC 2 (or equivalent) on file.

7. Incident response

Security incidents are triaged within 1 hour, contained within 4 hours, and disclosed to affected customers within 72 hours.

Report a vulnerability or suspected incident to security@imast.ai. We will acknowledge within 1 business day. We treat researchers in good faith and do not pursue action when work stays within our published scope.

8. Compliance

We design imast against SOC 2 control families and GDPR principles. We are not currently SOC 2 attested or formally GDPR-certified; if a customer requires either, the practical work is on our roadmap and we will commit to an attestation timeline as part of an enterprise agreement. ISO 27001 and HIPAA are on the longer-term roadmap.

9. Document status

This document describes our current practice in plain language. The legal entity that operates imast.ai is being formalised; jurisdiction, supervisory authority, and any operating-entity references will be added in a future version once incorporation is complete. Email privacy@imast.ai if you need an interim Data Processing Agreement.