After a user reports the assistant quoting another company's internal doc, run the postmortem

Short answer·Hard·4.0 · 0·~3 min

Attempt it

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.

Memory aid

Easy to grasp

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.

Key concepts

Retrieval-Augmented Generation LLM System Design

Detailed answer & concept explanation

~7 min read

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.

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.

Pinecone and Qdrant support per-tenant namespaces precisely so cross-tenant retrieval is physically impossible rather than filter-dependent
SaaS RAG products derive the tenant ID from the authenticated JWT or session, never from a request body field the client controls
Mature teams run an automated authorization test that queries as tenant A and asserts zero chunks tagged tenant B ever return
Incident 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?

QWhen does a shared index with a filter become acceptable, and what extra controls does it need?

QHow does indirect prompt injection via a retrieved document interact with multi-tenancy?

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.

60-second cheat sheet

The night-before-the-interview bullets. Scan these on the way to the call.

References

Primary sources. Skim if you want the original framing.