Access isolation

Isolation is the architecture, not a feature toggle: every user gets a dedicated AI Instance in the region your org chose, and multi-tenant enforcement holds at the database, transport, and compute layers.

An instance per user

Each member runs on their own AI Instance: a dedicated virtual machine with its own compute, storage, secrets, and keys. Instances come in sizing classes (Chat, Work Pro, and the larger Work classes), plus one always-on Org instance per organization. Nothing about your agents' execution is shared with another tenant, or with another user in your own org.

Idle instances sleep automatically: the platform tracks last activity and puts an idle Chat or Work Pro instance to sleep after a per-org configurable idle threshold, then wakes it on the next request. The Org instance is always on. A sleeping instance is deallocated, so it accrues no compute cost while asleep. Each wake runs a boot attestation: if the machine comes back different than it went to sleep as, the mismatch is surfaced, never silent.

Region pinned at setup

During onboarding, Step 1 asks for a region and city before you can advance. The promise is printed right on the selector: Your data. Your jurisdiction. Every AI Instance runs exclusively in the region you choose; your data, your models, and your conversations never leave it. The picker only offers regions the environment can actually provision into, so you are never sold a region that would fail at setup.

Setup wizard with the region and city selection
↳Region is chosen once, at setup, and every instance in the org is pinned to it.

What is enforced

  • →Row-level tenant scoping: every query is bound to your organization at the database layer. A request can only read or write rows owned by your org, enforced in code, not by convention.
  • →No cross-tenant egress: real-time channels, agent workspaces, and file storage are partitioned per org, with a continuous test suite asserting no event, broadcast, or object crosses an organization boundary.
  • →Per-customer compute isolation: agents execute in a dedicated, encrypted environment with separate compute, secrets, and keys, so execution is isolated, not just data.

Evidence for auditors

Organization Settings > Isolation describes each enforced control and offers an isolation attestation: a downloadable artifact summarizing the controls and the test coverage behind them, built so a security review can verify enforcement without reading source code.

The Isolation admin page describing each enforced control and the downloadable isolation attestation
↳The controls, stated plainly, with an attestation your security review can take away.

The Isolation page carries a Preview badge while it rolls out. The enforcement underneath (row-level security, the isolation test suite, per-user instances, region pinning) is live in the platform today.