auditing-multi-tenant-isolation

Auditing multi-tenant isolation: is every operation scoped to the caller's tenant

When one system holds many tenants' data, isolation is an invariant that has to hold everywhere at once: every query, cache read, storage access, search, and background job is scoped to the tenant the request is authenticated as, and to no other. A single unscoped operation is not one bug but a whole class of cross-tenant access at that point. This is the systemic view, distinct from asking whether one object reference is owner-checked; here the question is whether the boundary is enforced by construction across the codebase. You audit it by finding the tenant value at each data operation and tracing it back: does it come from the authenticated session, or from something the client controls, and is there a mandatory scope that covers this path at all. The decisive false positive is a central, invisible enforcement, a global scope or a row-level policy, so establish that first.

When to use

• One deployment or database serves multiple tenants, organizations, or workspaces, separated by a scope rather than by isolation.
• Data operations take an object identifier, a tenant selector, or run in a background job or export.
• You want to know whether any authenticated tenant can reach another tenant's data.

Scope check

Test cross-tenant access only in systems you own or are authorized to assess, using tenants you control. A confirmed bleed exposes another customer's data, so use only test tenants and coordinate disclosure. If you can't name the authorization, stop.

The loop

1. Establish the enforcement model first. Determine how tenant scoping is meant to be enforced: a mandatory global scope or base query that injects the tenant on every call, a database row-level policy bound to a per-request tenant, or per-query discipline where each query must add its own predicate. Which model is in force decides what an unscoped-looking query means, so settle it before flagging anything.