← All guides · RAG in production

Permission-Aware Retrieval: Multi-Tenant RAG Without Leaks

Part 8 of RAG in production · 906 words · ~4 min read · published 2026-08-23 · updated 2026-08-23 · Markdown variant

How to enforce access control inside retrieval for multi-tenant RAG: authorization as mandatory pre-filters derived from the authenticated principal, tenant isolation mechanics, permission-negative testing, and the post-filter trap that produces empty answers.

Part of the Agentic RAG in Production: The Complete Operator Guide guide.

Multi-tenant RAG fails differently from single-tenant RAG: the dangerous failure is not a wrong answer but an answer someone was never allowed to see. The pillar guide groups permissions with freshness as correctness requirements; this article specifies the enforcement architecture.

Where does authorization actually happen?

The safe pattern derives filters from the authenticated principal and applies them inside every retrieval channel, before ranking:

1. Request arrives with verified identity (token, session, API key) — never with a claimed identity in the payload
2. The authorization layer resolves that identity to concrete filter predicates: tenant equals X, group in Y, clearance at least Z
3. Every retrieval channel — lexical, dense, fused — runs its query with those predicates attached
4. Fusion, reranking and assembly operate exclusively on already-authorized evidence

Anything the principal cannot see never enters a candidate list, so no downstream stage needs to remember the rules. The alternative architectures all fail recognizably: post-filters empty out results; two-pass retrieve-then-reauthorize wastes the leak window; prompt instructions are negotiation targets, not boundaries.

What does good tenant isolation require mechanically?

Four properties, checked rather than assumed:

• Metadata completeness — every chunk carries tenant ID and ACL groups captured at ingest (ingestion-time metadata is what makes this possible)
• Filter enforcement at the store — the vector index and lexical index both support filtered queries efficiently; a store that degrades under selective filters will tempt engineers into post-filtering, which is the trap above (vector database choice)
• Identity discipline end to end — the principal comes from verified authentication (agent identity), and service-side impersonation paths are audited
• Isolation verification — negative tests prove the boundary, continuously

Namespace-per-tenant versus shared-index-with-filters is the main architectural fork: separate namespaces give blast-radius isolation and simpler deletion but multiply operational overhead; shared indexes with mandatory filters are cheaper to run but depend entirely on filter discipline. Both are defensible; unenforced either is a leak.

How do permission changes propagate?

Permissions change on different clocks than documents do — roles shift, users leave, groups reorganize — and none of it touches source documents. Propagation therefore needs its own pipeline: policy changes emit events that update ACL metadata on affected chunks within a declared bound, exactly like document freshness (the freshness guide describes the same contract shape). Revocation lag is exposure time; measure it.

What about privacy obligations beyond tenants?

Residency, retention and subject-deletion duties apply to chunks because chunks contain the personal data. Concretely: deletion requests must reach tombstones inside SLA; regional commitments constrain where embedding stores run; retention expiry should sweep indexes, not just databases. The data privacy reference maps the obligations; the RAG-specific point is that ingestion multiplied copies of everything, so your compliance surface grew at ingest time too.

How should filters be represented in practice?

Three representations dominate, each with trade-offs worth naming:

• Boolean ACL filters — tenant equals, group in-set. Simplest to reason about and audit; struggles with complex hierarchies
• Document-level grant lists carried as chunk metadata — flexible per-document sharing (a doc shared with a partner group) at the cost of metadata updates whenever grants change
• Namespace/index-per-tenant — strongest blast-radius isolation and trivially correct deletion; operationally heavy at high tenant counts

Hybrids are common: namespace isolation for the hard boundary plus ACL filters inside a tenant for fine-grained sharing. Whichever representation you choose, derive it from one authorization source of truth so policy lives in exactly one place.

What do agents change about permissioning?

Agents request data with delegated authority — acting for a user or a workspace — so the principal your filters see must be the effective principal (the delegating user's scope), not the agent's own service identity. Delegation chains need careful propagation: an agent authorized to act for Alice inherits Alice's retrieval scope for this action, nothing more. Conflating the service identity with the delegating user is how agents accidentally become global readers; keep the mapping explicit in every retrieval call, and log both identities so audits can tell them apart.

What does done look like?

A multi-tenant RAG system is permission-done when: filters derive from authentication and run pre-ranking on every channel; the eval suite contains permission-negative cases that run in CI and production probes; revocation propagation is measured against a bound; privacy deletion propagates to chunks; and the security review covers the retriever with the same seriousness as the login page (security checklist). None of that is exotic — it is ordinary access-control engineering applied at the retrieval layer, which is precisely where skipping it costs the most.

The economics argue for doing this early: retrofitting permission metadata onto a large indexed corpus means reprocessing everything, while building filters in at ingest time costs almost nothing. Of all the production RAG investments, permission-aware retrieval has the worst retrofit-to-advance cost ratio — which is why the multi-tenant teams who skipped it end up rebuilding their indexes exactly once, on the day a customer asks the question every enterprise buyer eventually asks: prove my data cannot leak to your other customers.

The proof they want is exactly the artifact list from this article: filter-derived-from-authentication architecture, permission-negative test evidence, revocation-lag measurements, and a privacy story that includes chunks. Teams with those four artifacts pass enterprise security review in days; teams without them discover which of the two RAG failure modes matters most — not the wrong answer, but the answer someone else was entitled to.

#rag #security #multi-tenancy #permissions #production