RAG security exposes the identity gap in retrieval pipelines

At a glance

What this is: This is a practical guide to RAG security that identifies where retrieval pipelines, vector stores, logs and generation stages can expose sensitive data or accept malicious content.

Why it matters: It matters because IAM and data governance teams now have to control not just access to data stores, but what an AI system is allowed to retrieve, trust and reuse in real time.

Context

RAG security sits in the gap between classical access control and AI runtime behaviour. A retrieval-augmented system does not just read documents, it selects, reuses and transforms external context during inference, which creates new exposure paths if the underlying data sources, embeddings or logs are not governed for machine consumption.

The article frames the core issue correctly for identity practitioners: existing IAM and data protection models were designed for users, services and repositories, not for model-mediated retrieval pipelines. Once the system can pull context dynamically, the security question becomes who or what can retrieve which data, under what conditions, and with what guardrails.

Key questions

Q: What breaks when retrieved content is treated as trusted context in RAG systems?

A: The main failure is that untrusted documents can influence reasoning as if they were authoritative instructions. That can distort answers, override policy language, and trigger unsafe tool use. Security teams should treat retrieval as a governed input boundary, with provenance checks, source review, and logging of the actual context passed into generation.

Q: Why do RAG pipelines create access control problems that standard IAM does not fully solve?

A: Standard IAM can control access to applications and repositories, but RAG also needs control over what context the system may assemble on behalf of a user. Without retrieval-layer governance, a model can expose information that the user could not directly reach, which turns context selection into an access decision.

Q: How do security teams know whether a RAG pipeline is leaking sensitive data?

A: Look for retrieved context that contains restricted records, prompts that surface confidential snippets, and logs that retain user inputs or generated answers. If the system can answer with information outside the intended audience or the logs contain sensitive text, the pipeline is overexposed and needs tighter filtering and logging controls.

Q: Should organisations use context-based access control for RAG instead of ordinary document permissions?

A: They should use both, but for different layers of the problem. Ordinary permissions protect the source system, while context-based access control helps govern what the AI retrieves in a specific request. Without both, the model can still assemble information in ways that exceed the intended access boundary.

Technical breakdown

How retrieval, vector stores and generation create a new trust boundary

RAG systems split work across retrieval, storage and generation. The retriever searches external knowledge bases, often backed by vector databases, and passes the selected context to the LLM for response construction. That architecture improves grounding, but it also creates a trust boundary around the retrieved content itself. If the source corpus includes poisoned documents, overexposed records or sensitive embeddings, the model can faithfully amplify the wrong material. Security has to account for the fact that semantic similarity is not the same as trustworthiness.

Practical implication: Treat the retrieval layer as a governed decision point, not a passive search function.

Why prompt injection is a retrieval-stage control problem

Prompt injection in RAG is not only a model prompt issue. It becomes dangerous when retrieved text is treated as trusted input simply because it was found through semantic search. An attacker who can place malicious instructions into documents, knowledge bases or vector-backed content may influence downstream model behaviour without ever compromising the model itself. The failure mode is weak input validation at the retrieval boundary, combined with an assumption that internal content is inherently safe.

Practical implication: Filter and validate retrieved content before it reaches the generation step.

Identity and access controls for RAG pipelines

RAG introduces an identity problem because the system needs permission to fetch context, not just to store it. Context-based access control, MFA for administrators, and tightly scoped IAM permissions are all attempts to constrain who can touch the corpus and what the model can see. But the deeper challenge is that the retrieval pathway often aggregates many sources, which can create accidental privilege expansion if controls are applied only at the application perimeter instead of at the document, index and query layers.

Practical implication: Apply least privilege to retrieval permissions at the corpus, index and query layers, not only to the application.

Threat narrative

Attacker objective: The attacker wants the RAG system to surface hidden data or follow malicious instructions so that sensitive content is exposed or abused through ordinary AI interaction.

1. Entry occurs when an attacker introduces malicious instructions or sensitive content into a knowledge base, document set or vector store that a RAG system trusts during retrieval.
2. Credential access and privilege abuse emerge when the retrieval pipeline has broad read permissions and pulls context that the requesting user should not be able to reach directly.
3. Escalation happens when the model transforms the retrieved content into a response, making the malicious or overexposed data actionable inside downstream workflows.
4. Impact is the leakage of sensitive information, misleading responses, or unsafe automated actions driven by content the system should never have trusted.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• 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.

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 security is an identity governance problem, not just an AI quality problem. The article makes clear that the real trust boundary is the retrieval pipeline, where documents, embeddings and logs become active inputs to model behaviour. That means access control, data protection and validation all have to extend into the AI runtime, not stop at the source repository. Practitioners should treat retrieval permissions as governed identity decisions.

Context-based access control is the right direction, but it exposes a broader governance gap. Classical IAM can decide whether a user reaches a system, yet RAG requires control over what context the system can assemble on that user's behalf. That is a different problem from ordinary document access. The implication is that identity governance must account for request context, not only account identity, when AI systems assemble answers from multiple sources.

Vector databases create an identity-adjacent exposure surface because they store retrievable knowledge, not just data. Once embeddings and indexed content can be queried at machine speed, overexposure becomes operationally easier to exploit and harder to notice. This is why retrieval-layer permissions, logging discipline and encryption need to be considered together. The practical conclusion is that a RAG programme needs corpus-level governance, not just application-level approval.

Reduce agency is the most important clue in the article because it shows where the control model still falls short. If a model can only safely operate when its actions are bounded and supervised, then autonomous retrieval and transformation are already beyond what traditional data access assumptions were built for. The named concept here is the retrieval trust boundary: the point at which retrieved content stops being passive reference material and starts becoming governed security input. Practitioners should design around that boundary explicitly.

RAG security will increasingly converge with broader AI security and identity governance frameworks. The article's references to IAM, validation, monitoring and encryption are all necessary, but none is sufficient on its own. The field is moving toward composite controls that combine identity, content validation and runtime policy enforcement. Teams should expect RAG governance to sit alongside NHI, human IAM and AI security rather than inside any one discipline.

What this signals

Retrieval trust boundary: RAG programmes fail when teams assume semantic search is equivalent to trusted access. The control point moves from document storage to retrieval decisions, so governance has to follow the context the model assembles, not just the underlying repository.

RAG adoption will push identity teams toward policy at retrieval time, not only at login or storage time. That shift matters because the model can create a new access path by combining sources, which means the programme now needs controls for what is retrievable, what is visible in logs, and what can be transformed into output.

For practitioners

• Define retrieval-layer access policies Scope permissions so that users and services can only retrieve the context they are legitimately allowed to influence. Apply controls separately to source repositories, vector indexes and generation workloads so the model cannot inherit broad read access by default.
• Validate retrieved content before generation Inspect retrieved passages for prompt injection, malicious instructions and sensitive data before the model uses them. Validation should happen at the retrieval boundary, not after an answer has already been produced.
• Encrypt vector stores and logs Protect embeddings, retrieved context and interaction logs with encryption at rest and in transit, then limit who can decrypt and inspect them. Logs often become the easiest path to unintended disclosure when they capture prompts, context or outputs.
• Limit the model's agency in critical workflows Keep RAG systems inside tightly bounded actions where human oversight remains mandatory for sensitive decisions. If a workflow can trigger external effects, the retrieval path and the resulting output need explicit approval gates.

Key takeaways

• RAG security is about controlling how AI systems retrieve, trust and reuse content, not only about protecting the model itself.
• The main failure modes are prompt injection, excessive access and sensitive data exposure through vector stores, logs and generated answers.
• Teams need retrieval-layer governance, content validation and bounded model agency if they want RAG to stay inside its intended security boundary.

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.
• 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.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• 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.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.