The leak goes around the tenant filter, not through it
How multi-tenant systems keep one customer's data from reaching another, and where that isolation actually broke in the published record: not at the authorization layer, but in the shared layers that have no concept of a tenant.
A field guide to tenant isolation built from seven published cross-tenant incidents (Steam 2015, Cloudbleed 2017, GitHub 2021, ChaosDB 2021, AutoWarp 2022, Atlassian 2022, ChatGPT 2023) and the placement designs of Salesforce, Shopify, GitLab, AWS Lambda and Cloudflare Workers. It gives an architect the placement spectrum with flip conditions, a three-class failure catalogue with a design rule per incident, the numbers the record supports, and a seven-rung ladder of tests that would have caught each published leak.
In every published cross-tenant incident in this corpus the tenant-scoping layer worked exactly as designed; the data crossed tenants in a layer with no concept of tenancy: an edge cache keyed by URL, a proxy buffer, a reused request object, a pooled Redis connection, a shared job VM, an operator's deletion script.
What you get out of it
- Isolation is enforced at one layer but a request crosses six; every tenant-blind layer in the reference path has a published incident attached to it.
- Ambient tenant context is the common root: GitHub's reused env hash, acts_as_tenant's persisting Sidekiq thread-locals and session-level SET under a pooler are the same bug in three runtimes.
- Both extremes of the placement spectrum work at scale (Salesforce's total pool, Shopify's pods); the middle models, schema- and database-per-tenant, are where operational accounts report getting stuck.
- The restore unit must equal the promised blast-radius unit: Atlassian had tested backups yet needed up to 14 days to restore 883 sites, because per-tenant restore from shared databases had never been the drill.
- The missing-filter bug class produces no postmortems at all; a correct-looking response to the wrong tenant fires no alert, so detection has to be built as a cross-tenant denial test suite.
Scope
Why this, now. GitLab's Cells programme is the first time a major SaaS has re-partitioned itself around a tenancy unit in public, and the 2021-2023 run of cross-tenant disclosures turned tenant isolation from a compliance checkbox into a published failure literature worth synthesising.
What it does not cover. Corporate network segmentation, Kubernetes multi-tenancy for internal teams, per-tenant encryption key management, and cell-based availability partitioning except where it doubles as a tenancy boundary (covered by the 2026-08-29 blast-radius guide in this collection).
Other field guides
When the secret leaks: the hour after exposure
A field guide to the race that starts when a token goes public: who is allowed to kill a credential automatically, how fast the machinery actually wo…
26 sources · 18 organisations · 7 postmortemsThe breach is a missing check. The outage is the checker.
Reconstructs the authorization layer from the accounts of Google, Airbnb, Carta, Netflix, Figma, Slack and Gojek: relationship tuples, precomputed in…
26 sources · 24 organisations · 5 postmortemsTrusting the build pipeline
A CI job holds every credential you own and, on a public repo, runs code proposed by strangers. This guide reconstructs seven incidents (Codecov, Cir…
22 sources · 20 organisations · 7 postmortems