Tenant isolation keeps each customer's data and operations inside that customer's boundary, even when many customers share the same application and infrastructure. The boundary applies to reads and writes as well as background work, files, caches, search indexes, logs, and external integrations.
Where tenant context begins and travels
A system first derives tenant context from a trusted identity, domain, invitation, service credential, or another controlled mapping. That context then has to follow every operation that touches a tenant-owned resource. Accepting a tenant identifier directly from a request does not establish ownership.
An audit of vibe-coded software traces this context as data moves through the product. It checks whether synchronous requests and deferred work use the same boundary, and whether shared infrastructure preserves separation at each layer.
| Layer | Isolation question | Evidence to inspect |
|---|---|---|
| Request | How is the tenant established? | Session, token, account membership |
| Application | Which operations carry tenant context? | Policy and service interfaces |
| Storage | How are records scoped? | Queries, keys, database policies |
| Background work | Which tenant owns the task? | Job payload and worker context |
| Shared services | Can cached or indexed data cross tenants? | Cache keys, search filters, file paths |
Common ways the boundary breaks
Tenant leaks rarely require the entire application to ignore isolation. One unscoped path is enough. A dashboard query may be correct while an export job, autocomplete endpoint, or file download uses a global identifier.
The review searches for recurring causes:
- Caller-selected tenant: The request supplies an account ID that the server trusts.
- Unscoped lookup: A record is loaded globally before its tenant is checked.
- Shared cache key: Cached results omit the tenant dimension.
- Detached background job: Queued work stores a record ID but loses tenant context.
- Broad service credential: An integration can reach all tenants without a local policy check.
- Operational bypass: Support or administration paths use different isolation rules.
Isolation and authorization
Authorization decides whether an identity may perform an action. Tenant isolation adds a mandatory scope: the action must remain inside the identity's tenant boundary. A user can hold the correct role and still request another tenant's resource if the system checks only the role.
Object-level authorization enforces this relationship for individual resources. Row-level security can enforce tenant scope inside a relational database. Neither replaces the wider review of files, jobs, caches, external calls, and privileged operational paths.
How an audit proves separation
Tests use two tenants with similar data so accidental global queries cannot hide behind an empty result. Each sensitive read and write is exercised across the boundary. Denied operations must produce no data, mutation, event, cache entry, or queued task for the other tenant.
The audit output identifies how tenant context is established, where it is propagated, and which layers enforce it. That map is part of the review needed before generated software carries real users and data. It turns a broad promise of separation into checks tied to code and infrastructure.
