Tenant isolation for AI agents and RAG: why a tenant_id filter isn't enough

No other tenant's text was shown. Another tenant still changed the decision.

A procurement application helps customers review software renewals. Each customer is a tenant. Every database query carries the tenant ID, and users can open only their own organization's contracts.

A user at Customer B asks whether a renewal has a termination penalty that should block automatic approval. The application searches a shared vector index. Each chunk carries tenant metadata, but the search takes the 20 nearest chunks across all tenants first and filters afterward.

Eighteen of the 20 belong to Customer A. They're removed before the prompt is built, so no Customer A text reaches the user or the model. Two Customer B chunks remain. The clause that mattered ranked 23rd across all tenants and first within Customer B. It never made the cut.

The model sees two harmless chunks, finds no penalty and recommends renewal. A procurement tool updates Customer B's case.

Every local control held: the query was filtered, the index removed foreign chunks, the model saw only Customer B text, the tool updated a Customer B record, and no alert fired. Customer A simply used up the retrieval budget and pushed out evidence Customer B was entitled to.

Is a tenant_id filter enough for multi-tenant AI?

No. A tenant filter on database queries protects one store. AI applications carry tenant data through indexes, caches, features, model sessions, tool calls, outputs and logs, and the boundary has to hold in every one.

"Every query includes the tenant ID" is still the right rule for the database. It just isn't the application boundary anymore. The same tenant shows up in a row, a file path, a vector chunk, a cache key, a feature, a chat session, a sub-workflow call, a tool argument, an export, a trace and a replay. Lose the tenant in any one of them and you can disclose data, decide on the wrong evidence, act on the wrong record, or show operational data to the wrong administrator.

The definition includes influence on purpose. AI applications don't just return records. They rank, summarize, infer, route and act, and another tenant's data can change all of that without appearing in the answer.

The tenant is part of the identity, not a header

A tenant ID shouldn't be an optional string copied from a request header. It's part of who is acting and which resource is being touched. Derive it from trusted identity and policy, never from a parameter the caller (or the agent) supplies.

Local identifiers make this urgent. Two tenants can both have document 7421 or case 17. Those numbers mean nothing alone. The real identity is tenant plus resource type plus local ID, and sometimes legal entity or region too. Carry that tenant scope with the work across every step that reads data, picks a model, calls a tool, emits an event, writes a cache or records evidence. Within a tenant, the same discipline applies to business domains; see taxonomy-scoped authorization.

Where do tenant boundaries leak in an AI application?

They leak wherever data is selected, derived, remembered, acted on or recorded: retrieval and ranking, caches and features, model sessions and memory, agent and tool calls, generated outputs, logs and replay, and shared capacity.

Image · tenant-isolation-leak-surfacesHorizontal flow of one request for Tenant B through: Database, Files, Vector search, Features and caches, Model and memory, Agents, Tools, Outputs, Logs and replay. A dashed tenant boundary line runs above the whole flow. Mark the database as Usually covered in green and the rest as Often missed in amber. Small side panel: Capacity, with Tenant A and Tenant B sharing a queue.

Filter before you rank

Retrieval is the most important new tenant boundary, because it decides which information gets to influence the model at all. The control point isn't the final result set. It's candidate generation, filtering, ranking, reranking, chunking, summarization and context assembly.

OWASP's guidance on vector and embedding weaknesses points the same way: label chunks with access metadata, authorize at retrieval time, and don't rely on permissions captured at indexing. A sound retrieval path can answer:

• Which tenant scope governed candidate generation?
• Did any unauthorized item take part in search, reranking or summarization?
• Was the tenant filter applied before the top-k limit or diversity rule?
• Were query expansion, synonyms and reranker inputs drawn only from this tenant?
• Can you list every item that entered the context and every candidate excluded?

Shared indexes aren't unsafe in themselves. Separate indexes, tenant partitions and mandatory prefilters are all valid. What matters is that the choice is explicit.

Caches, features and derived data need the tenant too

Derived data is usually less protected than source data. A row has clear ownership; the embedding, feature, summary or cached response built from it often doesn't.

A cache key such as contract-summary:{document_id} is unsafe when document IDs are only unique within a tenant. A safer key includes the tenant, source revision and policy scope: contract-summary:{tenant_id}:{document_id}:{revision}:{scope}. The general rule is simple: anything whose contents or eligibility depend on the tenant either carries the tenant in its identity or lives in a store that enforces it.

Invalidation has to be tenant-aware as well. When a document's permissions change, a customer offboards or a legal entity moves, derived artifacts shouldn't stay reachable under the old assumptions. Provenance tells you which downstream artifacts came from the affected source and which decisions relied on them.

Models and memory mustn't become a shared session

The base model usually isn't the boundary. Everything around it is: prompts, retrieved context, tool descriptions, conversation history, working memory, prompt caches, provider-side retention and outputs. A shared model is fine when sessions, memory and caches are separated by tenant, context is assembled only from eligible sources, and provider, region and retention are chosen by policy.

Agents add a twist. Working memory can outlive one step, spawn child tasks or be written to long-term storage. Every memory item should be bound to tenant, purpose and retention, and a child agent can't broaden those just because it runs in the same process. Model choice is an isolation decision too: some tenants or data classes allow a public endpoint, others need a private deployment, a specific region or no provider retention.

Agents and tools can't broaden tenant authority

An agent can find a tool, build arguments and propose a plan. None of that proves the tool is allowed for this tenant or that the target record belongs to it. A broad service credential is the classic trap: the API authenticates the software and never checks that the object belongs to the tenant that started the work. That's broken object-level authorization, first on OWASP's API list for good reason.

Bind every consequential tool call to the tenant scope and delegated authority it runs under, the exact tenant-bound record, the allowed action and purpose, any approval, and a narrowly scoped credential meant for that one service. Event-driven workers should rebind the tenant when they resume rather than inferring it from a session variable. For how authority should narrow across hops, see AI agent identity and delegated authority.

Outputs and evidence are tenant data

Isolation often weakens after the answer is generated. The result lands in a shared cache, a file store, a notification, a webhook or a chat channel. Citations can reveal more than the prose. A generated link can point to an object the recipient can't otherwise reach. Check which tenant and record an output concerns, what shaped it, which fields may go to this recipient, where it may be stored and for how long.

Operational evidence deserves the same care, and often more. Traces, prompt captures, retrieval snapshots and tool payloads hold more than the user ever saw. A support engineer may investigate Customer B without being allowed to see Customer A. An auditor may need proof the boundary held without browsing the content. Logs and replay should be tenant-scoped, redacted by role and closed to cross-tenant inspection by default. The control that proves isolation mustn't become a leak itself.

Can shared infrastructure be tenant-safe?

Yes, when the isolation rules are explicit, enforced at every surface and tested. The danger isn't sharing; it's sharing with no clear owner of the tenant rules.

Then treat isolation as something you test continuously, not once. New caches, indexes, tools, mappings, model routes and support features reintroduce cross-tenant paths after the security review is done. A useful test set includes two tenants with identical local IDs, near-identical documents competing in shared search, cold and warm caches, permission revocation after indexing, offboarding, agents delegating across waits and retries, broad credentials reaching for another tenant's records, export and webhook paths, support and replay access, and noisy-neighbor load.

The invariant to test isn't "no foreign row returned." It's this: no other tenant's data, state, authority or artifact may influence or produce the output or the business effect.

Image · tenant-isolation-post-filterTwo panels. Left, Search then filter: 20 result slots, 18 colored Tenant A and struck out, 2 Tenant B left, the key clause shown outside at rank 23. Right, Filter then search: 20 slots all Tenant B, the key clause at rank 1 highlighted. Caption arrows: left leads to Renew automatically, right leads to Penalty found, needs review.

Common anti-patterns

Ten rules for end-to-end tenant isolation

1. Treat the tenant as part of identity and resource identity, never an optional parameter.
2. Derive tenant scope from trusted identity, not caller or agent input.
3. Carry tenant scope through data, retrieval, context, models, agents, events, tools, outputs and evidence.
4. Stop unauthorized candidates from affecting retrieval or ranking, not just from appearing.
5. Put the tenant in the identity of every derived artifact, cache entry, feature and memory item.
6. Check object-level ownership at every consequential tool call, even with a valid credential.
7. Choose model session, provider, region, retention and memory isolation by policy.
8. Treat logs, traces, lineage, replay and support consoles as tenant data.
9. Test disclosure, influence, action, evidence and noisy-neighbor cases with at least two hostile tenants.
10. Record which tenant's data and authority shaped each outcome.

The result: shared infrastructure without shared meaning

Multi-tenancy is valuable because it lets you share infrastructure, logic and operations. AI doesn't change that. It multiplies the places where the tenant boundary has to survive. Search selects evidence, caches and features create derived facts, models keep context, agents delegate, tools act, outputs travel and logs keep the history. Each surface can be locally correct while the application loses track of the tenant between them.

Hold the tenant as part of identity, enforce it at every surface, test it against hostile tenants, and keep a record of which tenant shaped each outcome. A database filter protects a query. Tenant isolation protects the application.