When RAG Returns Another Tenant’s Documents

Your retriever returned chunks. They belong to another tenant — the answer cites documents the caller must never see. This page is about that exact failure: retrieved chunks carry a tenant_id that is not the caller’s. It is not the inverse case where a filter silently excludes the right document (that is wrong chunk, cause 5), and it is not within-tenant document ACL depth (see access control).

Before you redesign the index, log what came back. Record the query, the caller’s verified tenant, every retrieved chunk id, each chunk’s tenant_id metadata, and the filters the retriever claims it applied. Cross-tenant leakage is silent: no error fires, and the model answers confidently from foreign context. Reading the retrieval — not the chat reply — is where every diagnosis starts.

First, which of the five leak causes is it?

Cross-tenant RAG leakage has five recurring causes, and each has a different fix. Adding namespaces when the bug is an unkeyed semantic cache wastes a sprint; tightening a filter when the bug is permission lag leaves revoked users reading embeddings for days. Attack-vector writeups list many surfaces in order. The faster path is differential diagnosis: start from the one symptom, and run the single probe that rules each cause in or out before you change architecture.

Each row is a measurement you run on a seeded two-tenant corpus before you change production code. The sections below expand the symptom, the probe, the cause, and the fix.

A code path forgot the tenant filter

The most common production leak: tenant scope lives only in application code, so any path that constructs a vector query without the filter — a new feature, a refactor, a debug script against production, a background job without HTTP context — returns every tenant’s nearest neighbors. Barski (January 2026) frames it as being one missing WHERE clause from a breach; AppScale’s 2026 attack-vector taxonomy lists the same pattern as cross-tenant retrieval leakage when filters are application-enforced only.

The tenant ID comes from the request body

A verified session says the caller is tenant A, but the retriever trusts a tenant value from the request body, a header, or an LLM-parsed filter expression. Preporato’s cross-tenant lab (2026) stacks two bugs that show up in real systems: a caller-controlled tenant scope, and a metadata filter built by string concatenation — the filter analogue of SQL injection — so a crafted value breaks out of the tenant predicate.

You filter after retrieval instead of before

Retrieve-then-filter runs ANN across the shared index first, then drops unauthorized hits. Unauthorized vectors have already entered the candidate set. Mixpeek (tenant isolation guide) notes post-filtering can return fewer than the requested k results; perfecXion (March 2026) adds that starvation and timing differences can become existence side channels even when the final answer looks filtered.

The response cache is not keyed by tenant

Semantic response caches key on query embedding similarity. Without a tenant in the cache key, Tenant B’s paraphrase can hit Tenant A’s cached answer — including citations — and bypass every retrieval ACL. perfecXion (March 2026) measured a two-tenant deployment with 50 cached queries per tenant: at similarity threshold 0.70 the overall cache hit rate was 24.0% with 6.0% sensitive exposure; at 0.80 the overall hit rate was 4.0% with 0.0% sensitive exposure. Verify those figures on your own cache before you treat the thresholds as policy — the structural fix does not depend on the exact percentages.

Permissions changed but the index did not

Source systems revoke access immediately; the vector index only knows the ACL metadata from the last sync. perfecXion (March 2026) describes permission lag across SharePoint, Confluence, and Google Drive integrations where sync intervals are measured in minutes to days, and separately describes ACL translation loss: nested groups, negations, and expiring share links flatten poorly into key-value metadata, so the index admits principals the source system already excluded.

How do you prove isolation with one probe suite?

Rather than reason about the five causes one at a time, run them as one suite against a tiny in-memory stand-in for your retriever and cache. Given two seeded tenants and callable retrieve/cache hooks, this prints which leak cause fired. Swap the stubs for your real store — Weaviate multi-tenancy tenants, Pinecone namespaces, Qdrant collections, or pgvector RLS — without changing the assertions.

"""Cross-tenant leakage probes — five causes, one suite (stdlib only).

Wire retrieve() / cache_get() / cache_set() to your real stack before CI.
Each chunk is a dict: {"id": str, "tenant_id": str, "text": str}.
"""

def leak_rate(chunks, caller):
    if not chunks:
        return 0.0
    foreign = sum(1 for c in chunks if c["tenant_id"] != caller)
    return foreign / len(chunks)

def probe_tenant_leakage(*, retrieve, cache_get, cache_set, k=5):
    """Print which of the five leakage causes fired.

    retrieve(caller, query, *, tenant_from_body=None, apply_filter=True,
             return_prefilter=False) -> list[chunk] | (pre, post)
    cache_get(caller, query) / cache_set(caller, query, answer_chunks)
    """
    # Cause 1 — forgotten filter: same query with filter forced off
    normal = retrieve("acme", "secret roadmap", apply_filter=True)
    open_ = retrieve("acme", "secret roadmap", apply_filter=False)
    if leak_rate(open_, "acme") > 0 and leak_rate(normal, "acme") == 0:
        print("CAUSE 1 forgotten filter -> move tenant scope to storage layer")

    # Cause 2 — caller-controlled scope: auth=acme, body claims globex
    spoof = retrieve("acme", "secret roadmap", tenant_from_body="globex")
    if leak_rate(spoof, "acme") > 0:
        print("CAUSE 2 caller-controlled tenant -> derive tenant from verified session")

    # Cause 3 — retrieve-then-filter: foreign ids exist before post-filter
    pre, post = retrieve("acme", "secret roadmap", return_prefilter=True)
    if leak_rate(pre, "acme") > 0:
        print(f"CAUSE 3 retrieve-then-filter "
              f"(foreign_prefilter_rate={leak_rate(pre, 'acme'):.2f}) "
              f"-> filter-then-retrieve")

    # Cause 4 — cache without tenant key
    acme_ans = [{"id": "a1", "tenant_id": "acme", "text": "acme Q3 revenue MARKER"}]
    cache_set("acme", "what is our Q3 revenue?", acme_ans)
    hit = cache_get("globex", "what was the company's third quarter revenue?")
    if hit and any("MARKER" in c.get("text", "") for c in hit):
        print("CAUSE 4 cache cross-talk -> put tenant_id in the cache key")

    # Cause 5 — permission lag: simulate revoked principal still retrieving
    revoked = retrieve("revoked-user", "board minutes", apply_filter=True)
    if any(c.get("acl_allows_revoked") for c in revoked):
        print("CAUSE 5 permission lag / ACL loss -> fail-closed sync + ACL fidelity")

    if leak_rate(normal, "acme") == 0 and leak_rate(spoof, "acme") == 0:
        print("baseline retrieve as acme: PASS (no foreign tenant_id)")

The suite is deliberately transparent: each block is one row of the detection table above. Wire it to every retrieve entrypoint you ship — chat, tools, batch jobs, and admin search — because the forgotten-filter cause lives in the path you forgot to test.