A customer reports that your multi-tenant RAG assistant answered their question using content from a different company's internal document. Run the postmortem: what most likely went wrong at retrieval time, and what immediate and structural fixes do you put in place?
Free · 2 AI evals / day
This is a **cross-tenant data leak**, one of the most serious bugs a multi-tenant RAG system can have. The diagnosis starts from the symptom: a chunk belonging to a different company ended up in the prompt, and the model quoted it. So how did a foreign chunk get into retrieval at all?
The usual cause is that the search was not scoped to the asking tenant. Common shapes: everyone's documents live in one shared index with no per-tenant filter, so a semantically similar foreign chunk ranked into the top-k. Or a filter ran after generation or only hid results in the UI, so the chunk still reached the model. Or the document's tenant tag was missing or wrong.
The critical idea is that **the prompt is not a security boundary**. Once a foreign chunk is in the context window, the model can summarize or quote it, no matter what the system prompt says.
Immediately, treat this as a security incident: use audit logs to find what leaked and to whom, notify per your obligations, and contain it. Structurally, enforce a tenant filter on the search itself, tied to the user's authenticated identity, and ideally give each tenant a separate index.
The symptom is unambiguous: a multi-tenant assistant surfaced another tenant's content, a cross-tenant data leak. The root cause is almost always the same class of bug: **retrieval was not scoped to the requesting tenant's access boundary**. The postmortem should name which shape it took.
There are three common shapes. A single shared index with no tenant pre-filter, where a similar foreign chunk ranked into the top-k. A filter that ran in the wrong place — after generation, or only in the UI — so the forbidden chunk still reached the prompt. Or a metadata problem: a missing, stale, or wrong tenant tag, so even a correct filter let it through. The unifying lesson is that once a chunk is in context, the model can quote it; the prompt is not a security boundary.
The immediate response is incident handling, not a quality patch. Determine what was exposed and to whom, audit retrieval logs to scope the blast radius, notify per your obligations, and contain via an emergency filter.
The structural fixes are the real answer. Enforce a **mandatory tenant pre-filter at retrieval** so the search only considers the requesting tenant's chunks, with the tenant ID from authenticated identity, never anything the user can set. Prefer hard isolation — a per-tenant index or namespace — over a shared index trusting a single filter. Make missing or stale ACL metadata deny by default, and add continuous testing plus audit logging that asserts no result crosses a tenant boundary.
Quick reference
TL;DR
A cross-tenant leak means retrieval wasn't scoped to the tenant's ACL. Fix it with a mandatory pre-filter at search time from authenticated identity, ideally per-tenant isolation. The prompt is never the boundary.
Imagine a shared filing cabinet for many companies, where a clerk fetches papers for whoever asks. The right design is: before the clerk even opens a drawer, the building checks your badge and only unlocks your company's drawer. The leak happened because the clerk was allowed to pull papers from every drawer and was merely asked, politely, to ignore the ones that weren't yours — and one slipped through. Telling the clerk 'please don't read other companies' files' is not security; it's a suggestion. The fix is to lock the other drawers at the door, based on who you actually are (your badge, not a name you typed in). The strongest version gives each company its own locked cabinet entirely, so there is nothing to mix up.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
A single-tenant deployment where all data belongs to one customer There is no tenant boundary to enforce, so the pre-filter and per-tenant isolation machinery add complexity with no security benefit.
Per-tenant physical isolation when you have hundreds of thousands of tiny tenants Spinning a separate index per tenant can be operationally and cost-prohibitive at extreme tenant counts; a namespace or rigorously enforced filter with row-level security may be the pragmatic boundary instead.
Relying on retrieval scoping alone when documents also need per-user, not just per-tenant, ACLs Tenant-level scoping is necessary but insufficient when users within a tenant have differing access; you need finer-grained ACL filtering layered on top, or the within-tenant leak persists.
Quick scan · 2–4 min
Everything important, quickly.
Open by naming it a cross-tenant data leak and the governing principle: the boundary must be enforced at retrieval, before any chunk can enter context. Walk the three root-cause shapes — shared index with no pre-filter, filter applied post-generation or in the UI, and missing or stale ACL metadata. Hammer that the prompt is not a security boundary. Cover incident response: scope via logs, contain, notify. Then the structural fixes: mandatory pre-filter from authenticated identity, hard per-tenant isolation over a trusted filter, deny by default metadata, and continuous authorization tests. Close by rejecting the prompt-instruction control outright.
Real-world examples
Real products, models, and research that use this idea.
1Pinecone and Qdrant support per-tenant namespaces precisely so cross-tenant retrieval is physically impossible rather than filter-dependent
2SaaS RAG products derive the tenant ID from the authenticated JWT or session, never from a request body field the client controls
3Mature teams run an automated authorization test that queries as tenant A and asserts zero chunks tagged tenant B ever return
4Incident runbooks for these leaks scope exposure from per-query retrieval logs that record requesting tenant versus returned chunk tenants
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QWhy is deriving the tenant ID from a user-supplied request field a vulnerability even with a correct pre-filter?
Sign in or go Pro to see the approach for this follow-up.
QWhen does a shared index with a filter become acceptable, and what extra controls does it need?
Sign in or go Pro to see the approach for this follow-up.
QHow does indirect prompt injection via a retrieved document interact with multi-tenancy?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Trying to fix a cross-tenant leak with a prompt instruction telling the model to ignore other tenants' data — the prompt is not a security boundary, and once a foreign chunk is in context the model can quote it.