An attacker doesn’t need to breach your network to steal from your RAG pipeline. They just need to send an email. That’s what CVE-2025-32711 proved: a single hidden instruction, buried in a routine message, walked data out of an enterprise copilot with zero clicks and zero alerts.
The same retrieval pipeline that makes AI useful over your live enterprise data is the one quietly carrying instructions to the model on an attacker’s behalf, and prompt injection now sits at the top of the OWASP LLM list for exactly that reason.
If you’re a CISO or CAIO trying to move RAG from pilot to production, that’s the gap between an approved use case and an unmanaged breach, and it won’t close on its own. This article maps the four RAG threat layers, the shifts that occur when agentic workflows enter the picture, and the layered defense and governance model that holds from ingestion through runtime.
What Is RAG Security?
RAG security is the discipline of protecting retrieval-augmented generation systems from the distinct risks that emerge when large language models are connected to live enterprise knowledge bases.
Unlike securing a standalone model or a customized model with static weights, RAG security spans a full operational pipeline: the documents that enter the knowledge base, the retrieval controls that govern what gets surfaced at query time, the runtime environment where content enters the model’s context window, and the third-party components (orchestration frameworks, embedding models, vector databases, connectors) that underpin the entire stack.
Legacy data loss prevention and CASB tools were not built for this architecture. A browser-based DLP solution can observe that a user accessed an AI application. It can’t see what the retrieval pipeline surfaced, what instructions may have been embedded in a retrieved document, or whether a response included reconstructed content from a sensitive embedding. The visibility gap is structural, not a configuration problem.
Why the RAG Architecture Creates New Attack Surface
RAG creates a new attack surface because retrieval and generation share no trust boundary inside the model. Every document the retrieval pipeline surfaces becomes part of the model’s working context. Unless additional controls are applied, retrieved content can influence model behavior alongside system instructions, creating opportunities for prompt injection and context manipulation, which is why standard application security controls don’t apply cleanly.
RAG has displaced model customization as the dominant enterprise pattern for AI over live knowledge because it’s more operationally practical. Model customization embeds a static snapshot into model weights; RAG updates automatically when source documents change, without retraining cycles or associated compute costs.
That flexibility is why adoption has accelerated, but the architecture introduces a security challenge that has no direct equivalent in traditional software or prior AI deployment patterns. Two properties of the pipeline drive the risk:
- The trust gap between retrieval and generation. LLMs don’t distinguish between system prompt instructions and retrieved context; they process both as trusted input. When a document enters the context window, the model treats it with the same weight as intentional instructions. That’s not a bug to be patched; it’s how transformer-based models read sequential context. Any content the retrieval pipeline surfaces, legitimate or adversarial, carries implicit authority over model behavior, which is exactly what poisoned documents and indirect injection attacks exploit.
- Existing security tools don’t see the risk. A browser-based DLP solution sees that a user accessed an AI application. It doesn’t see embedded override instructions in a retrieved document, reconstructed PII in a response, or an agentic tool call driven by manipulated content. Closing that gap requires intent-based classification of what the retrieval event produced and what the model returned, not perimeter or endpoint controls operating at the wrong layer of the stack.
These two properties explain why securing RAG can’t be solved at the perimeter or the endpoint, and why the threat model has to be broken out layer by layer.
The RAG Attack Surface: Four Threat Layers
RAG security risk is best understood as four distinct threat layers, each corresponding to a different stage of the pipeline. Addressing one layer without the others leaves meaningful exposure.
If your security team is already running point on AI evaluations, you’ve seen how a single weak layer collapses the rest. The sections below map each layer in the order in which an attacker is most likely to encounter it.
1. Knowledge Base Poisoning (Ingestion-Layer Attacks)
Knowledge base poisoning is the most upstream threat in the RAG pipeline and one of the most effective. Adversaries inject crafted documents that are simultaneously optimized to be retrieved for targeted queries and contain embedded instructions designed to override LLM behavior when included in the context window.
The research confirms the severity. A USENIX Security 2025 study demonstrated that injecting just five poisoned texts per target question into a knowledge base containing millions of documents can achieve 90% attack success rates across multiple benchmark datasets and LLMs. Vector database manipulation compounds the risk: combined attacks that poison both document content and the embedding space are more effective than either approach alone.
This threat layer also includes less targeted but operationally significant risks—documents entering the knowledge base from unverified sources, stale or corrupted content that was never intended to be retrieved, and misconfigured write access that allows unauthorized parties to modify the index.
Controls at this layer: Document provenance tracking with cryptographic hashes, restricted write access to vector databases, ingestion-provenance validation, and periodic re-ingestion audits to surface anomalous content. Layering these controls can reduce poisoning attack success rates to 0%.
2. Unauthorized Retrieval and Over-Permissioned Pipelines
Most RAG data exposure in production environments stems from retrieval controls that were never properly scoped, rather than from sophisticated attacks. When all users share the same retrieval namespace, a customer-facing agent can surface executive communications, HR records, or merger documents that were never intended to be accessible through that interface.
The OWASP Top 10 for LLMs classifies this under Vector and Embedding Weaknesses. In multi-tenant RAG deployments, where a single vector store serves multiple customer contexts, insufficient namespace isolation creates cross-tenant leakage risk: one tenant’s queries surfacing another tenant’s documents.
Controls at this layer: Least-privilege access enforced at the retrieval layer, IAM policies applied to the model’s service account rather than just the user session, access-controlled namespace isolation in multi-tenant vector stores, and pre-context filtering that prevents retrieved content from entering the model unless the requesting identity is authorized to see it.
3. Data Exfiltration Through Responses and Embeddings
Properly scoped retrieval access doesn’t fully close the exfiltration risk. Two distinct mechanisms allow sensitive data to escape through the output layer even when retrieval controls are correctly configured.
The first is response-level exfiltration: attackers use prompt manipulation or indirect injection to force the model to include retrieved content in its output, or to direct an agentic pipeline to transmit data to an external endpoint. The second is embedding-level exfiltration: some decoder-based architectures can reconstruct text from embeddings, enabling attribute inference or direct text recovery from the vector store.
Both mechanisms require controls at the runtime and storage layers rather than at retrieval. WitnessAI, an AI security and governance platform for the enterprise, can help here. The
Protect module addresses this through real-time data tokenization that protects sensitive content before it reaches the model, combined with bidirectional inspection of inputs and outputs. Differential privacy during embedding generation, combined with strict RBAC and storage controls, can substantially reduce embedding reconstruction risk.
4. Indirect Injection and Supply Chain Compromise
Both vectors belong together because malicious instructions enter through content that appears legitimate, an instruction embedded in a trusted document rather than a malformed request from a known adversary.
Indirect prompt injection occurs when an attacker plants malicious instructions in external content like web pages, emails, PDFs, and calendar invites that a RAG pipeline retrieves at inference time. The attacker never touches the AI interface.
CVE-2025-32711 is the clearest example: a hidden instruction in an email caused an enterprise copilot to exfiltrate user data with zero-click, no-user-awareness. Defense requires content sanitization, Unicode normalization, runtime inspection of retrieved content, and intent-aware controls that prevent untrusted content from influencing model behavior or expanding an agent’s authority.
Agentic RAG: The Expanding Attack Surface
When RAG feeds an autonomous agent, every retrieval-layer vulnerability becomes a potential real-world action rather than a bad chat response. The blast radius of the four threat layers above multiplies as soon as the model can call tools, write to systems, or transact on your behalf.
The threat model described above assumes that RAG operates as a question-and-answer pipeline: a user submits a query, the system retrieves context, and the model generates a response. That assumption is rapidly becoming outdated.
As RAG moves into autonomous agent workflows, the consequences of a successful retrieval-layer attack expand significantly. An agent using RAG acts on the content it retrieves. A poisoned document retrieved by an agentic pipeline doesn’t produce a bad response; it may execute a tool call, write to a database, trigger a downstream workflow, or send an API request to an external service. The blast radius of every upstream vulnerability in the threat model above is multiplied when the retrieval pipeline feeds an agent with real-world capabilities.
The attack pattern is the same (malicious instructions embedded in retrieved content), but the impact surface is no longer bounded by what the model outputs in a chat window. It extends to every action the agent is authorized to take.
MCP Servers and RAG Pipelines
Model Context Protocol (MCP) has accelerated this transition by providing a standard mechanism for agents to connect with external knowledge sources, tools, and services.
RAG pipelines feeding into MCP-connected agents represent a new frontier in the RAG security field: malicious instructions can enter via a knowledge-base retrieval event and propagate across an agent’s full tool-call authorization scope.
The required controls at this layer are shadow agent discovery and MCP visibility: the ability to enumerate which agents exist in the environment, which knowledge sources they are connected to, and which actions they are authorized to take. Without this visibility, security and governance teams are operating blind to a class of risk that did not exist in traditional enterprise AI deployments.
A Framework for Secure RAG in Production
Securing RAG in production requires controls at all four stages of the pipeline. No single tool addresses the full surface, and attempting to solve RAG security with a perimeter-focused or response-only approach leaves the ingestion and retrieval layers unprotected.
If you’re moving RAG from pilot to production, the four control sets below map to the four threat layers and should be evaluated together rather than sequenced.
- Ingestion Controls. Verify sources and track document provenance: hash every document at ingestion, restrict and log write access to the vector database, and sanitize content from external connectors before it enters the index. Without provenance at ingestion, every downstream control is operating on data it cannot fully trust.
- Retrieval Controls. Enforce least-privilege retrieval so each pipeline queries only the collections it is authorized to access, with IAM applied at the service-account level and namespace isolation in multi-tenant stores. Correct scoping retrieval is the highest-leverage control for preventing routine data exposure in production.
- Runtime Defense. Apply bidirectional runtime inspection to prompts and responses, tokenize sensitive content before it reaches models, detect prompt injection and harmful outputs, and use intent-based classification to distinguish legitimate activity from malicious or policy-violating behavior.
- Governance and Auditability. Maintain retrieval-level audit trails—what was retrieved, when, by which identity, and what was generated from it—across both human users and autonomous agents in a unified governance console. Without that visibility built into the architecture, regulatory attestation becomes a reconstruction exercise rather than a reporting one.
The four control sets form a defense-in-depth model that holds from ingestion through runtime, ensuring no single failure at one layer collapses the security posture of the entire RAG pipeline.
WitnessAI and RAG Security
WitnessAI is the confidence layer for enterprise AI, providing a unified platform to observe, control, and protect AI activity across the full RAG lifecycle—from knowledge ingestion through runtime interactions and agent execution.
Observe provides continuous visibility into AI usage across employees, models, applications, and agents—including shadow AI, shadow agents, MCP servers, and the retrieval pipelines connected to enterprise knowledge sources.
Control applies unified, intent-based policies across retrieval, runtime, employees, and agents, enabling least-privilege access, intelligent governance, namespace isolation, approved-tool enforcement, and agentic scope controls.
Protect delivers bidirectional runtime AI defense through prompt and response inspection, real-time tokenization of sensitive data, prompt injection protection, harmful output filtering, and model runtime security.
If your organization is scaling RAG beyond pilots and needs security infrastructure that matches the architecture, book a WitnessAI demo to see how WitnessAI addresses the four threat layers in production.