Externalized authorization for RAG closes retrieval-layer data leaks

At a glance

What this is: This is a Cerbos analysis of how externalized authorization can enforce access control at the retrieval layer in RAG systems, preventing semantically similar but unauthorized documents from reaching the LLM.

Why it matters: It matters because IAM teams supporting RAG, vector search, and document retrieval need authorization to happen before retrieval, not after, or confidential content can leak through snippets, summaries, or model context.

Context

Retrieval-augmented generation systems introduce a governance gap when retrieval relevance is allowed to stand in for access entitlement. In practical terms, a vector search can return content that is semantically close to a question even when the requester lacks permission to view it, which creates an identity and data exposure problem before the application layer has a chance to intervene.

Externalized authorization addresses that gap by separating policy evaluation from application code and pushing the decision into the retrieval path. For IAM teams, the important shift is that access control becomes a pre-retrieval condition on the data source, not a post-processing filter on already exposed results.

Cerbos' example shows that this pattern applies across databases and RAG pipelines because the same policy can be translated into native query filters. The governance question is no longer whether the application can hide unauthorized output after the fact, but whether the underlying retrieval engine is prevented from seeing it in the first place.

Key questions

Q: How should teams prevent unauthorized documents from entering RAG results?

A: Push authorization into the retrieval step itself, so the search engine only evaluates documents the requester is entitled to see. If filtering happens after retrieval, unauthorized content can still surface in snippets, metadata, or intermediate context before it is removed.

Q: Why do post-retrieval filters still leave leakage risk in RAG?

A: Because the unauthorized item has already been selected before the filter runs. That creates a window for snippets, summaries, and orchestration components to handle protected content, even if the final response omits it.

Q: What should IAM teams require from vector database integrations?

A: They should require native metadata filtering that can express policy at query time, plus a clear mapping from policy attributes to store fields. If the backend cannot enforce those conditions directly, the integration is leaving enforcement too late.

Q: What is the difference between centralised authorization policy and application-side access checks?

A: Centralised authorization policy evaluates permissions in one governed layer, while application-side checks spread logic across services and teams. Centralisation improves consistency, auditing, and policy reuse, especially in distributed environments. Application-side checks can be faster to implement, but they often fragment rules, increase drift, and make it harder to prove that access decisions are applied uniformly.

Technical breakdown

Why similarity search is not authorization

Vector search ranks content by proximity in embedding space, not by identity or entitlement. That means a user can retrieve a document because it is semantically related to the query even when they should not be able to see it. In a RAG architecture, that mismatch matters because retrieval happens before generation, so any leakage at the search stage can flow into snippets, summaries, citations, or the LLM context window. Externalized authorization resolves the mismatch by making policy evaluation part of the retrieval decision rather than a later application check. The key technical point is that semantic relevance and access rights are separate predicates, and both must be satisfied before content is exposed.

Practical implication: move authorization checks into retrieval so similarity alone never determines what content is eligible for search results.

How policy plans become database and Chroma filters

Cerbos' PlanResources API partially evaluates policy into a plan, which is then translated into a native filter object for the target store. In the database case, that means query conditions are pushed down so only allowed rows are returned. In the Chroma path, the adapter maps Cerbos attribute paths to vector-store metadata fields and emits a ChromaDB Where filter, using logical operators and comparison operators the store supports. This is important because enforcement happens at query time, not after retrieval. The architecture preserves central policy definition while adapting the enforcement layer to each backend's filter syntax and capability limits.

Practical implication: standardise policy centrally, then validate that each retrieval backend can express the same entitlement logic as native filters.

Why post-retrieval filtering still leaks

Post-retrieval filtering is a weak control because it allows unauthorized content to be selected before it is removed. That creates at least three problems: wasted search budget on items that will be discarded, exposure through returned snippets or intermediate summaries, and dependence on downstream code to catch a decision that should already have been made. For RAG, that is especially risky because the LLM and its surrounding orchestration often see the raw retrieval set before any final presentation layer. If the unauthorized document reaches the retrieval stage, the control has already failed in a way that is hard to audit cleanly.

Practical implication: treat post-retrieval redaction as a fallback only, and test whether any unauthorized document can reach retrieval output at all.

Breaches seen in the wild

• Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Retrieval-layer authorisation is now the boundary that matters for RAG. Once semantic search is used to assemble the candidate set, the old assumption that application code can safely filter results afterwards no longer holds. That breaks the governance model many teams still use for search and document access, where relevance is computed first and entitlement is checked later. Practitioners should treat retrieval as the access decision point, not merely a ranking stage.

Similarity-based retrieval creates a new identity control failure mode. In a vector store, the system can return content that is contextually close but policy-ineligible, which means the access problem is not authorization blindness in the application, but entitlement blindness in the retrieval layer. Cerbos' query-plan approach makes that explicit by translating policy into backend-specific filters before search completes. The practical lesson is that RAG governance has to express who may search which metadata and which documents, not just who may read the final answer.

Externalized authorization is a control pattern, not a product feature. The architectural value is that policy stays central while enforcement is pushed to the place where data is actually selected. That reduces code duplication, narrows the exposure window, and makes entitlement logic more consistent across traditional databases and vector stores. For identity teams, the broader implication is that retrieval systems are becoming access-controlled data planes, and they need the same policy discipline as any other privileged resource.

RAG introduces a retrieval blast radius that exceeds the final output. Even when the LLM never outputs a protected document verbatim, the retrieval step may have already exposed sensitive context to snippets, embeddings, or orchestration components. That means governance has to consider the full retrieval path, not just the visible response. The practitioner conclusion is straightforward: if unauthorized data can enter the candidate set, the control plane is too late.

Authorisation models must now account for data shape, not only identity shape. Department, clearance, and other resource attributes become part of the entitlement logic because the retrieval engine needs enough structure to enforce policy natively. That is why metadata mapping is not a convenience detail but a governance dependency. Teams building RAG on enterprise content should design metadata and policy together, or they will recreate the same gap in every new vector index.

What this signals

Retrieval-time enforcement is becoming a core identity boundary for AI search. The control question is no longer whether the application can hide a result, but whether the retrieval engine can be prevented from seeing it. That shift will force IAM, data security, and AI platform teams to converge on shared metadata and policy design.

Access control for RAG should be treated as entitlement design, not output filtering. Once document selection is driven by embeddings, the system needs policy-aware filters that understand who may query which classes of content. Otherwise, vector search becomes a covert path around the organisation's normal authorization model.

For practitioners

• Push policy into retrieval Use externalized authorization so the retrieval layer evaluates entitlement before any document is selected for the prompt or response path.
• Map resource attributes explicitly Define stable metadata fields for department, clearance, and other policy inputs so query-plan translation can produce native filters instead of post-processing rules.
• Test the unauthorized-result path Run negative tests that prove an ineligible document never appears in candidate results, snippets, or intermediate orchestration logs.
• Treat vector stores as governed data planes Apply the same access-control discipline to Chroma or similar retrieval backends that you already apply to databases and other privileged repositories.

Key takeaways

• RAG creates a governance gap when semantic relevance is allowed to substitute for authorization.
• The important control point is retrieval, because post-retrieval filtering can still expose sensitive content before it is removed.
• IAM teams need policy-driven metadata filters so vector stores and RAG pipelines only consider documents the requester is entitled to access.

Key terms

• Externalized Authorization: A design pattern where access decisions are removed from application code and handled by a separate policy layer. This makes authorization easier to govern, test, audit, and reuse across services, especially when roles, attributes, and request context change frequently.
• Retrieval Layer: The stage in an AI application where documents, embeddings, or chunks are selected for use by the model. This layer is security-sensitive because it determines what information can enter the prompt or output path, making it a control point for both authorization and data leakage.
• Query planner: A query planner is the component that decides which order and direction to evaluate parts of an authorization request. In graph-based access control, it turns reachability into a cost-based routing problem, choosing paths that can reduce fan-out, short-circuit sooner, and limit unnecessary work.
• Metadata Filter: A datastore constraint that limits search results based on indexed attributes such as department, clearance, or document type. For AI retrieval, metadata filters are often the practical mechanism that turns policy into enforcement before unauthorized content reaches the LLM context window.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.