The cheapest way to build a SaaS is one big database with a tenant_id column. It is also how most cross-tenant incidents happen: one missing filter in one query and another customer's data is on the screen. For an AI control plane — which can read your code, run agents, and deploy apps — that blast radius is not a risk worth taking.

The tenant-column trap

Shared infrastructure pushes isolation into application code, which means isolation is only as good as the least careful query, cache key, or background job anyone ever writes. It holds until it doesn't, and when it doesn't, the failure is silent until it is a headline.

One organization, one stack

Cortex Cloud takes the opposite stance: every organization is provisioned as a complete, isolated stack — its own VM, its own identity provider, its own data store. There is no shared database to leak across and no noisy neighbour to throttle you. Isolation is the architecture, not a flag you remember to set.

Top-down, never sideways

Vendors still need to help, so operators can reach into an organization — but only through short-lived, signed delegation tokens that are scoped, expiring, revocable, and fully audited. A grant is a deliberate act with an expiry, not standing access:

grant scoped, expiring access# operator grants 60 minutes of support access into one org
$ cortex org delegate acme-labs --scope support --ttl-minutes 60
  → grant dlg_9f3a… issued · bearer cdl_f18b… · expires 10:41 · scope=support

# revoke the grant ID the moment it is no longer needed
$ cortex org revoke-delegation dlg_9f3a…
  → revoked · all delegated sessions invalidated

What you can prove

Because the boundary is structural, we can test it rather than trust it. Our suite asserts that an org account sees only its own org, that a tenant cannot enumerate or reach a sibling, and that operator access is always mediated by a live delegation. Cross-tenant denial is a test that must pass on every deploy — not a property we hope survived the last refactor.