auditing-multi-tenant-isolationlisted

# 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