RAG access control gaps expose a new identity governance problem

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Lasso Security's blog post: RAG systems create an identity governance problem when retrieval is not filtered by user permissions and document context.

Why it matters: IAM teams need to treat retrieval as an access decision, because LLM output can expose data that traditional file permissions were never designed to govern inside the query path.

Context

RAG, or retrieval-augmented generation, combines an LLM with external documents so the model can answer from current or internal sources instead of memory alone. That makes retrieval part of the access path, not just a search convenience.

The governance gap appears when vector search is run over content that was indexed without identity metadata or document-level permission filters. In that design, the model can retrieve content a user should not be able to see, even if the underlying file system permissions were broader than intended.

For IAM and NHI programmes, the question is not whether the model hallucinates less. It is whether the retrieval layer respects the same authorisation model that governs the source data, including role scope, document scope, and user context.

Key questions

Q: What breaks when RAG is connected to content without permission filtering?

A: The retrieval layer can return material the user was never intended to see, because similarity search is not the same thing as authorisation. Once that content is passed into the model prompt, the system can disclose sensitive information even when the source repository had some permissions structure in place.

Q: Why do RAG systems create a governance issue even when hallucinations improve?

A: Because the main risk shifts from answer quality to access scope. If retrieval is unconstrained, the system may produce a correct answer from content the user should not be allowed to access, which turns disclosure into an identity and permissions problem rather than a model accuracy problem.

Q: How should security teams decide between separate RAG instances and document-level filtering?

A: Use separate instances when segregation is the only reliable way to keep sensitive populations apart, but prefer document-level filtering when you need one knowledge base with fine-grained entitlements. The decision should follow the maturity of your metadata, role design, and operational tolerance for duplication.

Q: How can teams tell whether context-based access control is actually working?

A: Look for consistent denial of access from unmanaged devices, off-policy locations, and unsupported session times, while approved sessions continue to work without manual exception handling. If risky requests still succeed or every exception needs manual review, the control is not operating as a real decision layer.

Technical breakdown

Why vector search bypasses traditional file access assumptions

RAG systems split content into chunks, embed those chunks as vectors, and return the nearest matches for a query. If retrieval runs across the full index without permission metadata, similarity search becomes an implicit authorisation layer, which it is not. The model then receives whatever the retriever returns, so the security boundary shifts from the file store to the retrieval pipeline. That is why broadly accessible content buried in shared drives can become easy to surface through a conversational interface. The problem is architectural, not a prompt flaw.

Practical implication: treat retrieval as part of the access-control chain and verify that the search layer enforces the same entitlements as the source repository.

Separate instances versus document-level access control

The article describes two common enforcement patterns. Separate instances split content by population or sensitivity class, reducing cross-domain exposure but increasing operational overhead and duplication. Document-level access control attaches metadata to each indexed object so queries are filtered to what the user is allowed to see, which is more precise but harder to maintain at scale. Both approaches are compensating controls for a system that does not natively understand authorisation. The key trade-off is between segmentation simplicity and fine-grained governance.

Practical implication: choose the control pattern that matches your entitlement model, then test how reliably it stays aligned when roles, documents, and users change.

Context-based access control for RAG prompts and outputs

Context-based access control, as described in the article, evaluates the request and response against expected user behaviour and policy context. That means the system can weigh who is asking, what they are asking for, and whether the answer fits the permitted scope, not just whether the underlying document exists. This is more than filtering on a role claim. It is an attempt to govern retrieval in a language-driven interface where the requested concept may be broad, ambiguous, or hidden inside a document that also contains permitted material.

Practical implication: if you are using RAG in production, require a control that can inspect query context and response content before sensitive material is returned.

Breaches seen in the wild

• Hugging Face API tokens exposed 2023: Lasso Security found 1,681 live Hugging Face tokens in public code, 655 with write access, reaching 723 organisations including Meta; all were revoked.
• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.

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

RAG turns retrieval into an authorisation problem, not just a relevance problem. The article’s core insight is that the user is not only asking for information but entering an access path to indexed data. Once retrieval is driven by vector similarity, the system can surface material that was never meant to be discoverable through that interface. Practitioners should treat retrieval design as an identity governance decision, not an LLM tuning exercise.

Context filtering is the missing control plane for enterprise RAG. Traditional permission models were built around files, folders, and applications with stable access boundaries. RAG collapses those boundaries by allowing a query to search across content that may be broadly indexed but narrowly intended. The named concept here is context-based access control, which is essentially governance over what the system may reveal given the requester, the request, and the response shape. That becomes the practical control point for AI-enabled knowledge access.

Separate instances reduce risk, but they also reveal how weak the underlying entitlements are. Splitting finance, HR, and general content into different RAG environments can contain exposure, yet the need for that segmentation is itself evidence that the source data estate is not cleanly governed. If “Everyone” permissions already exist in shared drives, RAG simply makes the latent problem easier to trigger. The implication is that identity and data governance must be aligned before retrieval automation is scaled.

Document-level access control is only as strong as the metadata discipline behind it. Fine-grained filtering looks precise, but it breaks when role mappings drift, metadata is stale, or documents are indexed without complete entitlement context. In that condition, the control appears present while the governance model is actually decaying. Practitioners should therefore audit the permission metadata pipeline with the same seriousness they apply to IAM lifecycle controls.

RAG governance will increasingly sit at the intersection of IAM, data security, and AI operations. This is not a pure GenAI issue and not a pure DLP issue. It is a retrieval-time policy problem that requires identity-aware enforcement, data classification, and observable decision logic in one chain. Teams that leave any one of those layers implicit will continue to expose information through well-intended AI search systems.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: Permission-Aware RAG Guide

What this signals

Context-based access control is the right mental model for RAG because the retrieval decision is not just about data existence, it is about whether the requester should be allowed to surface that data through a language interface. When index-time metadata and query-time policy drift apart, the model becomes a disclosure path rather than a productivity layer.

RAG programmes will increasingly need identity-aware retrieval controls that align with permission models in the source systems. That means treating access review, document entitlement hygiene, and retrieval logging as one governance workflow instead of three separate teams.

The practical shift for practitioners is simple: if the data estate still relies on broad shared-drive permissions, RAG will amplify the weakest part of that estate. The control problem moves upstream to the source permissions and downstream to the retrieval filter at the same time.

For practitioners

• Audit retrieval paths for hidden access bypasses Map where RAG queries are allowed to search and compare that path against the permissions model used by the source documents. Focus on places where broad indexing can surface content that users could not reasonably find through the original application or repository.
• Attach entitlement metadata to indexed content Require document-level metadata for role, user, or sensitivity before content enters the vector index, and validate that the filter is enforced at query time rather than only at ingestion.
• Test the effect of broad shared-drive permissions Look for files with inherited or permissive access that become newly discoverable through RAG, because conversational retrieval can expose them even when the file location was obscure.
• Define a context-based access policy Set rules for which request patterns, user populations, and response types are allowed to return sensitive material, then validate those rules against realistic prompts and document mixes.

Key takeaways

• RAG changes the security question from whether a model hallucinates to whether it is allowed to retrieve the material it uses.
• Broad indexing without permission-aware filtering can expose content that the user would never reach through the source repository itself.
• The strongest response is to align identity, metadata, and retrieval policy so the AI layer cannot bypass the data governance model.

Key terms

• Retrieval-augmented Generation: Retrieval-augmented generation is a pattern where an AI model pulls external information before generating output. The security challenge is that access rules can weaken when data is chunked, embedded, cached, or reused, so source permissions may not automatically follow the content into the model's context.
• Context-based access control: A policy model that authorizes access using the request’s identity, payload, origin, and intended action together. It is designed for systems where risk changes at runtime, especially AI agents and other NHI workloads that move through multiple tools and data sources.
• Resource-level access control: An authorisation model that decides access based on the specific object being touched, such as a table, repository, bucket, or record. For AI agents, it matters because tool approval alone does not explain whether the target resource is sensitive, destructive, or outside the intended scope.
• Vector Database: A data store that indexes embeddings so semantically similar content can be retrieved quickly. In RAG systems, the vector database is part of the trust boundary because it controls what context is surfaced, how often, and under which permissions.

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.