Security Architecture

All client-to-Atlas, Atlas-to-database, and Atlas-to-sub- processor traffic uses TLS 1.2+ enforced. No unencrypted ports are exposed.

All persistent data is encrypted at rest by Supabase (Atlas's primary DB) using AES-256. Database backups are also encrypted.

Roster+ enrichment, Phantom Search candidates, Industry Atlas evidence, and BLS hiring-risk snapshots are retained indefinitely as Atlas property — they constitute the substrate for the Industry Capability Atlas product. This data is anonymized at the query layer for any cross-customer aggregation, never via deletion or destructive migration.

HRIS imports, CSV uploads, and direct customer pushes (e.g. pipeline data, attribution models) are retained only whencustomer_consent_for_atlas = TRUE. Without consent, customer-supplied data stays in the customer's workspace but is excluded from any Industry Atlas queries.

Every Atlas call to OpenAI passes store: false — eliminating OpenAI's default 30-day request retention window. Customer data is processed and discarded by OpenAI rather than logged for abuse monitoring. Enforced by a SDK- level wrapper and verified by our pre-merge audit script.

Primary data centers are in the United States (Supabase AWS US-East-1, Vercel US). EU data residency is available with our Enterprise tier — see Compliance Posture below.

All user access is authenticated via Clerk (SOC 2 Type II). Customer admins can enable SSO (SAML / OIDC) on the Enterprise tier.

Every database table is scoped by workspace_id with Postgres Row-Level Security (RLS) enabled. All API routes verify the requesting user's workspace before returning data. Cross-tenant access is impossible at the database layer — even Atlas operators using the service-role key are constrained by application-layer workspace checks.

Atlas engineering staff access production data only via a single service-role key issued to server-side code. There is no shared admin UI, no manual SQL console exposed beyond a tightly-controlled break-glass procedure. All operator actions on customer data are logged.

All API routes require a valid Clerk session. Admin-only endpoints (BLS refresh, candidate verification backfill, ml data ingestion) additionally check a ADMIN_CLERK_USER_IDS allowlist before executing.

Server-side function logs are systematically stripped of customer PII before they reach the log retention layer. Names, emails, LinkedIn slugs, JD body text, and outreach content are never written to logs — only opaque IDs and metadata. This policy is enforced by an adversarial audit script run on every pull request.

Every PR runs an automated security audit (scripts/security-audit.sh) that verifies: (1) ZDR is enforced on every OpenAI call site, (2) no PII is interpolated into any console statement, (3) all OpenAI usage flows through the wrapper that applies ZDR. Any PR that introduces a regression fails the audit and cannot merge.

Security issues can be reported to security@atlas.ai. Atlas commits to acknowledgment within 24 hours and a mitigation plan within 5 business days for high-severity issues.

Atlas notifies affected customers within 72 hours of confirming a security incident affecting their data. The incident response playbook covers containment, eradication, recovery, and post-incident reporting.

Atlas's current controls cover:

• Encryption in transit + at rest
• Row-Level Security + workspace isolation
• Zero Data Retention at OpenAI
• PII-stripped server logs
• Sub-processor list + DPA template
• Adversarial pre-merge audit

For customers requiring formal compliance certification or data residency:

• SOC 2 Type II report
• GDPR Article 30 ROPA + customer-controlled deletion workflows
• EU data residency (AWS Frankfurt + Dublin or Azure EU)
• Audit logs (per-row + per-action history on customer workspaces)
• 8-role RBAC with custom role definitions
• Annual penetration test report (third-party)
• Customer-controlled Azure OpenAI Service deployment

For enterprise security questions, certifications, or to initiate procurement, trust@atlas.ai.