RAG rerankers and access control: where teams get it wrong

TL;DR: Enterprise RAG systems need both a retriever for recall and a reranker for precision, but placing access control after reranking can surface unauthorized documents because relevance scoring does not enforce permission boundaries, according to Protecto research. The control point has to sit between retrieval and reranking, where candidate documents can still be filtered before they reach the context window.

Editorial analysis by NHI Mgmt Group, based on content published by Protecto: “Why Is a Reranker Needed in RAG If We Have a Retriever?”.

Key questions

Q: How should teams place access controls in a two-stage RAG pipeline?

A: Access controls should sit between the retriever and the reranker, after candidate generation but before relevance scoring.

Q: Why can a high-precision reranker still create data exposure risk?

A: A reranker improves relevance, not entitlement.

Q: What breaks when retrieval returns more documents than the user should see?

A: The candidate set becomes the exposure surface.

Practitioner guidance

• Implement retrieval-stage authorization gates Apply per-request policy checks after initial retrieval but before reranking so only authorised candidates can be scored.
• Mask sensitive values before indexing Redact or contextually mask PII, PHI, PCI, and similar identifiers before chunks are written to the vector store.
• Log every retrieval and filtering decision Record what was retrieved, what was removed, and what entered the context window so reviewers can reconstruct exposure paths.

Bottom line: RAG pipelines create a distinct governance problem when retrieval and ranking are treated as one step instead of two.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →