In multi-tenant RAG, why must a tenant filter be an authorization boundary, not a ranking hint?

## Why the distinction is not pedantic Retrieval systems have two kinds of conditions and it is easy to blur them. A *preference* says one document should outrank another; it participates in scoring and can be outvoted by a strong enough signal on the other side. A *boundary* says a document must not be returned at all; nothing outvotes it. Tenant, ACL group, region and classification are boundaries. Recency and document type are usually preferences dressed as filters. The failure mode when you implement a boundary as a preference is precise: leakage becomes a function of similarity. A boost of, say, +0.15 on in-tenant documents means any out-of-tenant document whose similarity exceeds the best in-tenant one by more than that margin is returned. On a corpus of near-duplicate documents, that margin is crossed regularly. Consider a shared HR assistant serving employees in multiple countries, where a France-only parental-leave policy and the Brazilian equivalent are structurally identical documents differing in a few clauses. A Brazil-based employee's question about leave entitlement is close to *both*. The boost decides which one wins, and sometimes it decides wrong — and when it does, the model does not hedge. It reads the retrieved passage as ground truth and states French entitlements as the employee's own, with a citation. ## Where the predicate must live **Server-side, from the authenticated session.** The tenant and group set must be resolved from the caller's verified identity inside the retrieval service. Any design where the client passes `tenant_id` in the request body, or where the orchestration layer lets the model choose a scope, is forgeable — the model in particular is an untrusted component here, because prompt content it has read can influence what it asks for. If an agent has a retrieval tool, the tool's scope arguments must be narrowing options within the session's scope, never the source of the scope itself. **Before or during the search, not after — and never optional.** Post-filtering does technically remove out-of-tenant documents, so it is not itself a disclosure; but it makes correctness depend on a step that lives outside the index, which is easy to skip. Every path that reads the collection must carry the predicate: the chat endpoint, the async summarisation job, the eval harness that replays production queries, the internal debug console. A single unfiltered path is the whole breach. **Against payload that is current.** The most common real leak is not a missing filter but a stale one. Copying a document's ACL group list into the vector payload at ingestion time means that revoking a group's access changes nothing in the index until that document is reindexed — an interval that can be hours or days. Two robust patterns: push permission-change events into the index and update payloads promptly, or store stable group identifiers in the payload and resolve the *caller's* current groups from the identity system at query time, so revocation takes effect on the next query. ## Isolation strategies above the predicate A shared collection with a tenant predicate is the dense, cheap option: one index, good memory utilisation, one thing to operate. The alternative is physical isolation — a collection, namespace or database per tenant — where cross-tenant retrieval is impossible by construction rather than by correct code. Physical isolation costs per-tenant overhead and scales badly into the thousands of small tenants, and it complicates any legitimately cross-tenant feature. Most teams run a shared collection with a hard predicate and reserve physical isolation for tenants with contractual or regulatory separation requirements. The honest framing in an interview is that this is a spectrum chosen per customer segment, not a single right answer. ## Proving it works Scope enforcement is testable in a way most RAG quality is not. Seed the index with a poisoned corpus: documents in tenant B that are deliberately near-duplicates of tenant A's, then assert that a large sweep of tenant-A queries returns zero tenant-B ids at any k. Run that in CI on every retrieval-path change. Add a runtime invariant that inspects returned ids against the session scope and fails loudly — cheap, and it catches the path someone added without the predicate. Log the predicate alongside every retrieval so an audit can reconstruct what a given answer was allowed to see. ## What not to do when the scope is empty When the tenant predicate leaves nothing, the correct outcome is an empty result. Re-running without the predicate, softening it to a penalty, or returning the nearest out-of-scope passages "for context" each convert an unhelpful answer into a disclosure. Widening is only ever legitimate on preference predicates such as recency, never on boundaries.