What breaks when permissions do not persist from the source system into a RAG pipeline?

Why Permission Propagation Fails in RAG, and Why It Matters

When a retrieval-augmented generation pipeline does not preserve source-system permissions, it stops behaving like a governed application and starts behaving like an unfiltered synthesis layer. The security problem is not the model itself, but the broken trust boundary between the original system of record, the retrieval layer, and the response layer. That creates a direct confidentiality failure: answers can surface content that would never have been visible in the source application. For teams building chat over enterprise data, the distinction between “can retrieve” and “is allowed to disclose” is decisive.

This is where governance is often misunderstood. Many teams assume that indexing data into a vector store or document store is a technical replication task, but permissions are part of the meaning of the data, not just metadata. If access checks are not enforced at query time, the pipeline can aggregate content across users, groups, or datasets in ways the source system never permitted. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because access enforcement and information flow control are core control expectations, not optional implementation details. In practice, teams usually discover the problem only after a prompt returns a “helpful” answer that should have been blocked.

How Permission Preservation Should Work Across the Retrieval Path

A secure rag pipeline has to preserve authorization from ingestion through retrieval and response generation. That usually means the system must know who the requester is, what they are allowed to see, and whether each candidate chunk, document, or embedded passage is eligible for retrieval before it reaches the model. The retrieval layer should not simply find the most semantically similar text; it should find the most similar text that the requester is also permitted to access.

Operationally, this creates a few practical requirements. First, the source system or an authoritative authorization service must remain the decision point for access rights, rather than allowing the RAG index to become an independent source of truth. Second, permissions need to be evaluated at the right granularity. Document-level controls may be acceptable for some environments, but many organisations need finer scoping when one file contains mixed sensitivity. Third, the system should prevent “permission drift,” where an index or cache retains content after the user’s entitlements change.

• Use source-backed access decisions rather than copying permissions into the retrieval layer and hoping they stay current.
• Filter candidates before retrieval or before generation, depending on where the architecture can reliably enforce authorization.
• Keep audit evidence that shows which identity was authorised for which source object at response time.
• Test mixed-permission datasets, because those are where leakage is most likely to appear.

When these controls are working, the model can still answer questions accurately, but only from the slice of the corpus the requester is entitled to use. The guidance breaks down when permissions are implicit, stale, or reconstructed from incomplete metadata rather than enforced by a live authorization decision.

Where the Boundary Fractures, and What Teams Commonly Miss

Stricter permission enforcement often increases latency and implementation complexity, requiring organisations to balance user experience against confidentiality assurance.

One common edge case is blended retrieval, where results from multiple repositories are merged before the model sees them. That can create cross-tenant or cross-role leakage if the final response is assembled from partially authorised fragments. Another issue is inherited access. A user may be entitled to the original document in one system but not to the extracted passages in the RAG layer if those passages are repackaged with different context. Teams also underestimate how quickly revocation becomes a security problem: if a user loses access in the source system but the RAG index is not revalidated, the pipeline can continue disclosing restricted material.

There is no universal consensus on whether permission filtering should occur pre-retrieval, post-retrieval, or at both stages. The practical answer depends on the architecture, but the security requirement does not change: the user must never receive content solely because the model found it. When the control boundary is weak, the pipeline treats semantic relevance as if it were authorisation, and that is the mistake.

External guidance on machine-identity and delegated access is also useful when the RAG workflow depends on service credentials, because the pipeline often inherits access through non-human execution paths rather than an interactive user session. That matters when automation can read more broadly than the end user it is serving.

Risk and Threat Considerations

The primary risk is inadvertent data disclosure through broken authorization propagation. In a RAG pipeline, a user can receive restricted content if retrieval occurs against a broader corpus than the source application would permit, or if cached and indexed material outlives the user’s current entitlements.

Failure mechanism: The pipeline separates semantic search from access control, then trusts retrieval results without rechecking permissions at query time or response time. In blended datasets, one authorised fragment can pull in adjacent restricted text, and stale indexes can continue serving content after revocation.

Impact: Confidential records, regulated data, internal correspondence, or tenant-specific information can leak into chat responses, creating privacy exposure, policy violations, and loss of trust in the system’s outputs.

Practitioner Guidance

What to prioritise: Treat authorization as part of the retrieval path, not as a front-end concern. The first design question is whether the system can prove that every retrieved chunk was eligible for the requesting identity at the moment of response.

What to verify: Confirm that revocation, group changes, and tenant boundaries are reflected before retrieval results reach generation. If entitlement changes do not invalidate cached or indexed content quickly, the system should be treated as leaky by design.

Common mistake: Teams often test only whether the model answers correctly, not whether it answers only from data the requester was allowed to see. Correctness without authorization is the wrong success criterion for this pattern.

Practitioner takeaway: The real control objective is not “prevent the model from hallucinating,” but “prevent the model from disclosing anything the requester was never authorised to obtain.”

Related resources from NHI Mgmt Group

• What breaks when retrieval permissions are too broad in RAG?
• What breaks when open source intrusion detection is not tuned for pipeline activity?
• What breaks when package install logs do not identify the source machine or pipeline?
• What breaks when organisations treat a source of truth and a system of record as the same thing?