Access Control in RAG Retrieval

Access control in RAG is enforcing who-can-see-what at retrieval time so the model only receives chunks the requesting user is authorized to read. Semantic similarity alone does not know identity — without a permission filter the retriever becomes a privilege-escalation path through your own corpus.

Why does RAG retrieval ignore who is asking?

Because the default retriever ranks by embedding similarity (or BM25), not by the caller’s identity. Tian Pan’s 2026 enterprise write-up puts the failure cleanly: public-web RAG indexes unrestricted content; enterprise knowledge merges Confluence, Drive, tickets, and wikis — each with its own permission model — into one retrieval surface. The same query embedding from an intern and a hiring manager returns the same candidates unless a filter is injected.

That produces familiar paths: semantic overhang (an innocent question lands near a restricted HR chunk), cross-role contamination in a shared collection, and stale grants after someone is off-boarded. When another tenant’s documents appear, you are in multi-tenant leakage territory — a sibling failure mode of the same missing identity check.

Why isn’t a post-filter enough for RAG access control?

Post-filtering is not enough — and that is the claim the topical title promises. Two independent reasons show up across the ranking pages (Truto’s pre- vs post-filter comparison; Tian Pan’s application-layer critique; Gruenig’s March 2026 “just filter the output” section; Secure Patterns’ threat-model FAQ):

• Top-k waste. You retrieve the nearest neighbours first, then discard unauthorized hits. If most of the top-k were forbidden, the authorized set that remains can be thin or empty even though allowed documents exist further down the ranking.
• Trust boundary already crossed. If the model (or any intermediate step) has already processed a restricted chunk, suppressing secrets in the final string does not undo the exposure — conclusions and summaries can still leak. Output redaction and guardrails are last-resort layers, not the access-control boundary.

PII masking on the text itself is a different control — PII redaction — and still does not decide who may retrieve which doc.

How do you enforce permissions at retrieval time?

Constrain the candidate set before (or as) similarity runs so unauthorized chunks never enter context. Three patterns dominate the live teardown:

1. Metadata ACL / security filters — at ingest, tag every chunk with roles, users, or tenant IDs; every query appends a mandatory filter (Tian Pan’s vector-layer approach; OWASP RAG Security Cheat Sheet §4 on access-control inheritance; AWS’s grant-scope filtering pattern).
2. Partition / namespace isolation — search only the collection the caller is allowed to see (Secure Patterns’ “partition first, then filter within partition”).
3. External policy / ReBAC — resolve an allow-list of document IDs from a policy engine (SpiceDB-style relationship checks in the Pinecone/AuthZed guide; Cerbos query plans) and pre-filter the vector query to that set.

Modern stores expose some form of this — Weaviate multi-tenancy and filters, Azure AI Search security filters, and Pinecone metadata filters are the named examples in Tian Pan’s 2026 references. Application-only checks after an unfiltered vector query remain a thin defence if the retrieval call itself is open. Finer document-ACL mapping belongs on document-level permissions; tenancy mechanics on multi-tenancy.

How do you keep document permissions in sync with the index?

Propagate source ACLs into chunk metadata at ingest, and revoke on the same path as deletes. Gruenig’s permission-aware retrieval guide and Truto’s 2026 document-level RBAC architecture both treat stale permission data as a first-class failure: a correct filter expression is useless if the tags still say a contractor can read a doc they lost yesterday.

Minimum loop: tag at ingest → listen for permission and ownership changes → tombstone or re-tag when access is revoked → never ask the LLM to refuse on policy grounds. Deeper SharePoint/SaaS ACL propagation is the document-permissions page; orphaned vectors after delete are the stale-index failure.

How do you test RAG access control?

Treat the retrieval service as a security boundary — relevance evals alone will not catch it. Secure Patterns’ verification checklist and Tian Pan’s adversarial framing converge on the same tests:

• Same natural-language query as two roles must not return the restricted set to the lower role.
• Cross-tenant queries return empty or isolated namespaces only.
• A revoked user fails closed on the next request.
• Requests missing identity context fail closed — they do not fall back to “search everything”.
• Logs record eligible vs selected chunk IDs so you can answer what was retrieved.

Wire the suite into CI where you can; keep the trail in audit logging and the live signals in monitoring.