# What is Tenant Isolation?

Also called Multi-Tenancy Isolation, Data Segregation.

Tenant isolation is the separation of one customer's data, configuration, and workloads from every other customer's inside a shared system. It is enforced across storage, retrieval, caching, background jobs, and logs. Cross-tenant leakage, where one customer sees another's data, is generally treated as the most severe defect class in multi-tenant software.

Isolation models sit on a spectrum. A silo model gives each tenant separate infrastructure, which is the strongest boundary and the most expensive to operate. A pool model shares infrastructure and enforces separation in software on every access path. A bridge model mixes the two, isolating the most sensitive stores while pooling the rest. Most software as a service uses pooled or bridged designs.

In pooled designs the boundary is only as strong as its weakest access path. Enforcement is needed at the request layer, where tenant context is established from an authenticated identity rather than from a parameter the client supplies; in the database, often through row-level security so a forgotten filter fails safe; in object storage prefixes; and in every cache key, which is a frequent source of leaks.

AI features add access paths that are easy to overlook. Vector indexes rank by similarity and have no inherent notion of ownership, so tenant scoping must be applied as a filter in the query rather than after retrieval. Conversation memory, uploaded files, embeddings, evaluation datasets, and trace storage each need the same scoping, and a shared background worker must carry tenant context through the whole job.

Isolation is verified rather than assumed. Automated tests that attempt cross-tenant access on every endpoint, seeded canary records that should never appear in another tenant's results, and alerting on any query that executes without tenant context all catch regressions that code review misses. The tests matter most on paths added after the original design.

## Key points

- Silo, pool, and bridge models trade cost against boundary strength
- Tenant context comes from authentication, never from client input
- Row-level security makes a forgotten filter fail safe
- Vector indexes and cache keys are frequently missed paths
- Verify with cross-tenant tests and canary records, do not assume

## In practice

A shared vector index stores document chunks for every customer. The retrieval call originally filtered results after ranking, so a highly similar chunk from another tenant could occupy a slot and, in one code path, reach the model's context. Moving the tenant filter into the query itself, and adding a canary document that should never surface outside its own tenant, closed the gap and detects any regression.

## Related terms

- [Least Privilege](/en/glossary/least-privilege)
- [Data Leakage Prevention](/en/glossary/data-leakage-prevention)
- [Audit Trail](/en/glossary/audit-trail)
- [SOC 2](/en/glossary/soc-2)
- [Data Residency](/en/glossary/data-residency)

[Back to the AI Glossary](/en/glossary)