Security and privacy are foundational to Atlas

Data Handling

Atlas accesses your connected tools through OAuth 2.0 to read activity data for the purpose of generating a context graph that can be used to map out how work is performed. Here's what we access, what we store, and how we handle it.

What we access

When you connect an integration (e.g., Salesforce, HubSpot, Gmail), Atlas reads activity records such as deals, tickets, emails, and calendar events to map your operational processes.

What we store

We store the context graph we generate from your connected tools (entities, relationships, and activity metadata), integration metadata, and encrypted OAuth tokens. For underlying content like emails, Slack messages, and files, we store only the source identifiers — references that let us retrieve the original on demand from the connected system, but never the raw bodies, attachments, or message contents themselves. We request the minimum scopes needed for each integration.

Data residency

By default, all application data is stored and processed in europe-west4 (Netherlands, EU). For customers with US data residency requirements, we can deploy in a US region on request. Transactional email delivery uses Resend (US-based). Frontend assets are served via Firebase global CDN.

Encryption

At rest

OAuth tokens and API keys are encrypted using AES-256-GCM with PBKDF2-SHA256 key derivation (65,536 iterations) before storage. Each encryption operation uses a 12-byte random IV. The underlying database uses Google-managed transparent encryption.

In transit

All connections use TLS 1.2+. The API is served over HTTPS via Google Cloud Run with Google-managed certificates. WebSocket connections use WSS (WebSocket Secure).

Infrastructure

Atlas runs entirely on Google Cloud Platform in the EU.

Authentication

Atlas uses JWT-based authentication with short-lived access tokens and rotating refresh tokens.

All responses include security headers: HSTS, Content-Security-Policy, X-Frame-Options, and X-Content-Type-Options. CORS is restricted to the application domain.

Tenant Isolation

Every customer's data is isolated at the database level using PostgreSQL Row-Level Security (RLS).

• Every query runs within a user+tenant context — no cross-tenant data access is possible
• RLS policies use FORCE ROW LEVEL SECURITY — applies even to table owners
• Composite keys enforce user-tenant consistency on sensitive tables (e.g., OAuth tokens)

Integration Security

All integrations connect via OAuth 2.0 with PKCE (Proof Key for Code Exchange) — the most secure OAuth flow available.

• CSRF protection via UUID state parameter on every OAuth flow
• Tokens encrypted with AES-256-GCM before storage
• Automatic token refresh with 5-minute expiry buffer
• Minimal scopes requested per integration

Subprocessors

These are the third-party services that process data on our behalf.

Compliance Roadmap

We're building our compliance programme alongside our product. Here's where we stand today and what's coming next.