RAG security gaps show why legacy IAM controls are not enough

At a glance

What this is: RAG security is the practice of protecting retrieval-augmented generation systems, and the key finding is that enterprise deployments face distinct risks across ingestion, retrieval, runtime, and supply chain layers.

Why it matters: It matters because teams building AI on live knowledge bases must govern data access, output leakage, and pipeline trust with controls that span NHI, autonomous, and human-facing systems.

👉 Read WitnessAI's full analysis of RAG security risks and controls

Context

RAG security fails when organisations treat a retrieval pipeline like a normal application stack. Retrieval-augmented generation gives models direct access to live enterprise knowledge, which means the security model now has to govern documents, vectors, permissions, prompts, outputs, and third-party components together.

For IAM and security teams, the core issue is not model accuracy alone. It is whether the identity and access boundaries around the retrieval layer are precise enough to keep customer data, internal policies, and proprietary knowledge from becoming ambient model context.

Key questions

Q: How should security teams govern access in RAG systems?

A: Security teams should govern RAG access at the retrieval layer, not only at authentication. That means mapping each workflow to the smallest possible set of collections, binding retrieval to user and service account entitlements, and separating sensitive corpora so one model path cannot reach unrelated business data. The goal is to limit blast radius before the model sees anything.

Q: Why do RAG deployments create more data exposure risk than standard chat systems?

A: RAG deployments connect the model to live enterprise content, so the model can surface data that was never meant to be public within that workflow. If retrieval scopes are broad or response controls are missing, the system can turn authorized access into accidental disclosure. The risk grows because leakage can happen through normal model behaviour, not just overt attack.

Q: What breaks when retrieval permissions are too broad in RAG?

A: Broad retrieval permissions collapse data separation. A user or service account can pull executive, HR, financial, or security records into the model context even when the request does not justify it. Once that content enters the prompt window, prompt injection and response leakage become easier to trigger, and the model can become a high-speed channel for overexposed information.

Q: How do organisations reduce supply chain risk in RAG pipelines?

A: Organisations should review every component that can shape retrieval, indexing, or output, including orchestration frameworks, connectors, vector databases, and embedding providers. The practical test is whether the component can write, read, or move sensitive data. If it can, it needs inventory, logging, and governance alongside the rest of the production stack.

Technical breakdown

Poisoned documents and prompt injection in RAG

RAG systems trust retrieved content as context, which makes document poisoning a high-impact attack path. An attacker who can place crafted content into the knowledge base can influence both retrieval and generation, especially when the model cannot reliably separate trusted instructions from adversarial text. The risk is amplified when ingestion pipelines lack provenance checks, when write access to the index is too broad, or when content sanitisation is weak. The article also points to research showing that a small number of poisoned texts can meaningfully alter outcomes, which is why retrieval hygiene is part of the security boundary, not a content-management side issue.

Practical implication: treat the knowledge base as privileged infrastructure and enforce provenance validation before any document reaches the retrieval layer.

Over-permissioned retrieval and data leakage through responses

RAG exposure often starts with authorization failure, not sophisticated exploitation. If all users share the same retrieval scope, the system can surface records that the requesting user should never see, and the model can then leak that data back in its output. This turns retrieval permissions into a control point that is every bit as important as prompt filtering. The article’s discussion of session-scoped tokens, response authorization, and bidirectional scanning shows that the boundary must extend from source collection to model output. In practice, the model’s service account and the namespaces it can query determine the blast radius of every request.

Practical implication: bind retrieval scope to user entitlement and enforce response filtering before sensitive content leaves the model path.

Vector poisoning, embeddings, and supply chain trust

Vector stores and embeddings introduce a second trust layer that many teams underestimate. The article notes that poisoned indexes, query-targeted retrieval patterns, and embedding reconstruction risks all widen the attack surface beyond the original source documents. That means a RAG programme has to watch for anomalous retrieval frequency, enforce access control on the vector database itself, and treat embeddings as potentially sensitive artefacts rather than harmless metadata. Third-party orchestration frameworks, embedding providers, and agentic connectors also expand the supply chain risk. Once those dependencies are in the path, the system is only as trustworthy as the least governed component.

Practical implication: secure the vector layer, monitor retrieval anomalies, and include AI pipeline dependencies in the software supply chain review.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

RAG security is an identity governance problem before it is a model-safety problem. The article shows that the decisive control points sit in retrieval permissions, ingestion provenance, and runtime output handling. That is exactly where identity, access, and data governance intersect, so the operating model must be built as a control plane for access to knowledge rather than a model-only safeguard. Practitioners should treat retrieval scopes as enforceable entitlements, not implementation details.

Over-permissioned knowledge retrieval is the named failure mode that matters most here. When a user or service account can query more collections than its role requires, the model becomes a distribution channel for data that was never meant to be visible. That failure mode is not solved by better prompts, because the breach happens at the entitlement layer. The implication is that RAG security depends on precise collection-level authorization and lifecycle-managed service account access.

Identity blast radius: RAG turns one weak retrieval identity into a data exposure path across multiple business domains. A single overly broad service account can surface financial records, HR data, security procedures, and proprietary research through one retrieval pipeline. This is why access scope, token boundaries, and response controls need to be reviewed together. Practitioners should measure blast radius as the practical unit of RAG governance.

Third-party AI dependencies now belong inside the identity control model. The article’s supply chain section shows that orchestration frameworks, connectors, and agentic components are not neutral plumbing. They can alter the trust boundary, introduce exposed execution paths, and create unseen data movement. Teams should extend governance to AI pipeline dependencies with the same discipline they apply to other privileged integrations.

RAG security validates the shift from static perimeter thinking to runtime policy enforcement. Once models consume live internal knowledge, risk moves to the moment of retrieval and output, not just to storage or authentication. That means policy has to be enforced when data is selected, transformed, and released. Practitioners should assume that legacy controls will miss the highest-risk part of the interaction unless runtime inspection is built in.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• That confidence gap persists alongside a separate finding that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which keeps retrieval and delegation risks hidden.
• For a wider governance view, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for the lifecycle controls that make delegated access reviewable.

What this signals

RAG pushes security teams toward runtime governance because the highest-risk events happen after authentication, when content is retrieved and released. That means the programme has to understand not just who can log in, but which data sources a model can touch and which outputs it can emit. Identity blast radius: is the right way to think about this shift, because one over-broad retrieval identity can expose multiple business domains at once.

The operational signal is simple. If your team cannot explain which collections a model may query, which service account owns that path, and how sensitive data is redacted before output, you do not have RAG governance yet. Aligning this with the NIST Cybersecurity Framework 2.0 helps teams separate identify, protect, detect, and respond duties around AI pipelines.

Enterprises should expect RAG to increase pressure on NHI controls rather than replace them. The governance answer is not a separate AI exception path, but a tighter integration of retrieval entitlements, source provenance, and monitoring into the same programme that already manages service accounts and secrets.

For practitioners

• Tighten retrieval entitlements by collection Map each RAG use case to the minimum set of collections it needs, then bind those collections to user and service account entitlements. Separate high-sensitivity corpora such as HR, finance, and security content so a customer-facing workflow cannot reach them by default.
• Treat ingestion as a privileged write path Require provenance checks, signed source attestation, and approval for any process that writes into the knowledge base or vector store. Restrict who can publish, reindex, or overwrite source material so poisoned content cannot enter through a routine workflow.
• Apply response-layer filtering before output leaves the model Use tokenization, redaction, and authorization checks on generated responses before they reach end users or downstream systems. Make sensitive-data release a policy decision, not an accidental side effect of retrieval.
• Monitor retrieval anomalies across semantically unrelated queries Flag documents that appear with unusual frequency across different topics, since that pattern can indicate poisoning, prompt steering, or index manipulation. Combine retrieval telemetry with audit logs from the vector database and the model service account.
• Include AI dependencies in supply chain reviews Extend SBOM and third-party review processes to orchestration frameworks, embedding providers, connectors, and MCP servers. Track which components can write, retrieve, or exfiltrate data so governance covers the full RAG path.

Key takeaways

• RAG security is an access governance problem as much as a model safety problem, because the retrieval layer determines what data the model can expose.
• The biggest exposure comes from broad retrieval scopes, poisoned content, and response leakage, all of which can turn normal model behaviour into a disclosure path.
• Teams should govern retrieval like a privileged access path, with provenance checks, least-privilege collection access, and output filtering before deployment at scale.

Key terms

• Retrieval-Augmented Generation: A design pattern that connects a language model to live external knowledge at query time. The model does not rely only on training data, so governance must cover the documents, permissions, and pipelines that feed retrieved context into the response path.
• Retrieval Scope: The set of collections, documents, or sources a RAG workflow is allowed to query. In practice, retrieval scope behaves like an entitlement boundary, because overly broad scope lets one model path expose data across business domains that should remain separated.
• Prompt Injection: A technique that places instructions into content the model may later consume as trusted context. In RAG environments, that content can arrive through documents, emails, web pages, or database records, which makes the attack a governance issue as well as a technical one.
• 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

RAG security and retrieval-layer access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is moving from pilots to production, it is worth grounding that work in the same lifecycle and governance model.

This post draws on content published by WitnessAI: RAG security risks and how enterprises can address them. Read the original.