Why reranker placement matters for RAG access control

At a glance

What this is: Protecto argues that RAG pipelines need separate recall and precision stages, and that reranking without access filtering can promote sensitive documents into the context window.

Why it matters: For IAM and NHI teams, the key issue is that permission checks must happen at inference time, before candidate documents are re-scored, or retrieval can become an access-control bypass.

Context

RAG systems fail when teams treat semantic retrieval as if it were also an authorization decision. Retrieval is designed to find likely matches at scale, while reranking is designed to choose the best answer from a smaller set; those are different control points with different risk profiles.

That distinction matters because the security boundary is not the embedding model itself, but the moment a candidate document is allowed to proceed toward the model context. In identity-aware retrieval designs, permission-aware retrieval is the governance step that keeps relevance scoring from outranking access policy.

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. That sequencing lets policy filter the candidate set before it can be promoted into the context window. If controls are applied later, the system may already have ranked sensitive content as the best answer path, which is too late to prevent exposure.

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

A: A reranker improves relevance, not entitlement. If it receives unauthorized candidates, it can elevate sensitive documents precisely because they are the best semantic match to the query. The risk is not incorrect ranking, but correct ranking applied to a candidate set that was never permission-filtered. Precision without access governance can amplify exposure instead of reducing it.

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

A: The candidate set becomes the exposure surface. Even if the final answer is filtered, sensitive documents may already have been scored, ranked, and placed into the context window, where downstream model processing can consume them. That means over-retrieval is not just a relevance issue; it is a governance failure that can leak restricted context into the generation path.

Q: How can organisations tell whether RAG access controls are working?

A: They should be able to show that unauthorized documents are removed before reranking, and that audit logs capture each retrieval, filter, and context-window decision. If the system cannot prove which candidates were blocked before ranking, then the control boundary is probably in the wrong place. Effective governance is visible in the retrieval audit trail, not just in final answer quality.

Technical breakdown

Why the retriever optimizes recall, not correctness

A retriever usually uses a bi-encoder, which embeds the query and each document separately and compares them with cosine similarity. That makes it fast enough to search large corpora, but it also means the model never evaluates the full query-document relationship in one pass. The result is a candidate set of semantically close documents, not a ranked list of definitively correct answers. In enterprise environments, that distinction matters because documents can share vocabulary while answering very different questions. The retriever is therefore a broad discovery mechanism, not a final relevance arbiter.

Practical implication: Use retrievers to narrow search space only, and do not treat top-k retrieval as a sufficient answer-selection control.

How rerankers change the trust boundary

A reranker, such as a cross-encoder or LLM-based reranker, evaluates the query and candidate document together. That lets it score actual relevance rather than vector proximity, which is why it improves answer precision. The operational downside is that reranking happens after candidate documents already exist, so it can intensify exposure if sensitive content is still present in the candidate set. In other words, a reranker is a ranking control, not an access control. If the candidate set includes unauthorized material, the reranker can elevate it precisely because it is the best match. See the Permission-Aware RAG Guide.

Practical implication: Filter candidate documents before reranking so precision scoring cannot promote content the user is not entitled to see.

Why the access-control boundary belongs between retrieval and reranking

The safest design places authorization after retrieval but before reranking. That sequencing lets the system apply per-request policy to the candidate set while the list is still small enough to govern, yet before relevance scoring can push unauthorized material into the prompt context. This is especially important in enterprise RAG, where documents may contain sensitive identifiers, regulated data, or context that should only be visible to specific users or agents. Once a document is ranked into the context window, output filtering is too late to prevent exposure during model processing.

Practical implication: Enforce context-based access control between the retriever and reranker so policy gates the candidate set before ranking.

Threat narrative

Attacker objective: The practical objective is unauthorized exposure of restricted content through a query path that looks like normal retrieval.

1. Entry occurs when a user query reaches the retriever and pulls back a broad candidate set that may include restricted documents.
2. Credential_harvested is not the issue here; instead, the risk emerges when the reranker scores the unauthorized candidates for relevance without checking permission.
3. Impact occurs when sensitive content is promoted into the context window, creating exposure even if the final answer is later filtered.

Breaches seen in the wild

• CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
• McKinsey AI platform breach: McKinsey AI platform hack exposed 46M chats and sensitive data.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Retrieval and reranking are governance stages, not just model stages. The article correctly separates recall from precision, but the more important lesson is that each stage changes the trust boundary. Retrieval expands the candidate set, while reranking decides what gets elevated into the model context, so the control model must follow that sequence. For identity teams, this is the same design problem seen in other policy-sensitive pipelines: the system must decide what a request is allowed to touch before it decides what is most relevant. Practitioners should treat the boundary between stages as a governance checkpoint, not an implementation detail.

Context-based access control becomes mandatory once ranking is decoupled from permission. A reranker is designed to be blind to entitlement unless the architecture explicitly gives it only authorized candidates. That means the problem is not that rerankers are inaccurate, but that they are accurate against the wrong population if access filtering is missing. In NHI and agentic workflows, this matters even more because software identities can query at machine speed and repeatedly probe for sensitive documents. The control failure is a permission gap in the retrieval path, not a weakness in the ranking model.

Masked content changes the exposure profile, but not the governance requirement. The article’s masking approach reduces the chance that raw sensitive values reach the vector store, which is useful, but masking alone does not solve authorization. If the retrieval path is still over-broad, the system can continue to surface sensitive context, even when the exact strings are hidden. That is why identity-aware retrieval design belongs alongside data security controls, not after them. Teams should govern what the system can see before asking what it should rank.

Security teams should think in terms of candidate-set containment. The named concept here is candidate-set overexposure: the moment when an AI pipeline widens the set of documents available for ranking beyond what the requester is entitled to inspect. That failure mode is especially dangerous in RAG because the prompt window becomes the enforcement surface. The right governance model is to ensure authorization constrains the candidate set first, then let precision controls operate inside that boundary.

Read next: Permission-Aware RAG Guide

What this signals

Candidate-set governance is becoming the real RAG control plane. As retrieval pipelines get more capable, the main risk shifts from whether the model can find relevant content to whether it can be prevented from ranking the wrong content for the wrong requester. That makes policy enforcement between retrieval and reranking a design requirement, not an optimization. Teams should expect identity-aware retrieval architectures to become a standard expectation in regulated and multi-tenant environments.

A useful operating model is to treat the reranker as a bounded optimizer. It can improve precision only after authorization has already trimmed the candidate set, which means the governance challenge sits upstream of the ranking model. For programmes that already manage secrets, access entitlements, or sensitive records, this is the same principle applied to AI context construction: constrain what can be seen before deciding what should be answered.

For practitioners

• 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.
• Separate recall tuning from access policy tuning Tune retriever recall and reranker precision independently, then validate that access rules still hold at the candidate-set boundary.

Key takeaways

• RAG pipelines create a distinct governance problem when retrieval and ranking are treated as one step instead of two.
• Protecto’s analysis shows that relevance scoring can amplify exposure if authorization is not enforced before reranking.
• The control that matters most is the boundary between candidate generation and precision ranking, not the final response filter.

Related NHI Mgmt Group resources: Permission-Aware RAG Guide · Data Security Guide · RAG Security Guide

Key terms

• Retriever: A retriever is the component that searches external data sources for information relevant to a user query. It identifies the most useful documents or passages before generation begins. In production systems, retrieval quality depends on indexing, embedding choice, ranking logic, and how well the query matches the stored content.
• Reranker: A reranker is the second-stage component that scores a smaller candidate set to determine which documents are most relevant to a specific query. It improves precision by evaluating query and document together, but it does not inherently know whether a candidate is authorised for the requester.
• Candidate Set: A candidate set is the subset of rules that still might apply after an initial filter. Authorization engines shrink this set before checking conditions, and the efficiency of that shrink step often determines whether the evaluator stays usable at scale.
• Context Window: The context window is the text a model receives at one time, including prompts, retrieved documents, and conversation history. Security teams care about it because it becomes the practical boundary between trusted instructions and untrusted content, especially when the application assembles that text automatically.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps security and identity teams connect access control discipline to the broader systems that depend on it.