How Atlas isolates your data — multi-tenant architecture explained
Atlas is multi-tenant by design. Every record is bound to an — a unique identifier for your organization. The data layer enforces this on every query. There is no path through Atlas where one tenant's data can be returne…
How Atlas isolates your data
Atlas is multi-tenant by design. Every record is bound to an organizationId — a unique identifier for your organization. The data layer enforces this on every query. There is no path through Atlas where one tenant's data can be returned to another.
This guide explains how the isolation works and how we keep it intact.
The data-layer enforcement
Every entity in Atlas's data model — Contact, Account, Lead, Opportunity, Activity, Note, Project, Site, Knowledge File, Audit Log entry — carries an organizationId column. Every query that retrieves these records includes organizationId in the where clause.
This is enforced at the data-access layer, not the application layer. Code that tries to query without organizationId is rejected. Cross-tenant access is not a feature flag we forgot to ship; it is structurally impossible without rewriting the data layer.
The session enforcement
Every authenticated session is tied to one organizationId. The session token carries the org identity. Every API request, MCP tool call, and background job inherits this identity.
If a user belongs to multiple organizations (e.g., a consultant working with several clients), each session is scoped to one at a time. Switching organizations forces a fresh session.
The audit enforcement
Every mutation is logged in Atlas Audit with the actor's organizationId. If a query attempted to access another org's data and was rejected, the rejection is logged.
The testing enforcement
Atlas runs a continuous test suite (1,200+ tests) that includes cross-tenant access tests on every critical entity. These run on every commit. We fail the build if a cross-tenant access ever succeeds.
How this differs from "shared multi-tenant" SaaS
Some SaaS platforms share a single database across customers with row-level security as the only barrier. This is fragile — a misconfigured query or a missing filter can expose data.
Atlas's posture is row-level filtering enforced at the data-access layer (not just the application), backed by tests, backed by audit, backed by code review. Multiple defenses, not one.
What about single-tenant deployment?
On the Enterprise tier, Atlas offers single-tenant deployment — your own database, your own infrastructure, optionally in your own cloud account. For organizations with the strictest data-residency requirements, this is available.
Related articles
See it on your own data.
Connect your tools and Atlas shows you what matters.
Related articles
Bring your own LLM — explained
If you are buying a business platform that uses AI, you are also making a model decision. Often without realizing it.
What is approval-first AI?
Approval-first AI is a design pattern for business automation. Every AI write action is proposed by the assistant, surfaced as an approval, and executed only after a human (or a configured policy) says yes.
What is the Atlas Audit log?
The Atlas Audit log is a complete, searchable record of every mutation in your workspace — by every user, by every agent, by every API key, in every product. It exists to make a single question answerable in three clicks…
What is the integration tax?
The integration tax is the hidden cost — paid in hours, not invoices — of running your business on nine SaaS tools that don't talk.