Retrieval-Augmented Generation is everywhere in enterprise AI right now. Connect your company's documents to a language model, let the model retrieve relevant content before it generates a response, and suddenly your AI assistant knows things it couldn't have known from training data alone. The architecture is elegant and genuinely useful — and most of the content written about it focuses almost entirely on how to build one correctly.
Almost none of it covers what happens when it retrieves the wrong document.
That's a significant gap, because the failure modes here aren't hypothetical edge cases. They're structural properties of how RAG works, and teams that deploy without understanding them are shipping systems with predictable security problems they just haven't found yet.
A Quick Baseline: How RAG Actually Works
Before getting into failure modes, it's worth being precise about the pipeline, because the vulnerabilities are specific to different stages of it.
A RAG system works roughly like this:
A user submits a query
The query is converted into a vector embedding — a numerical representation of its semantic meaning
The system searches a vector database for document chunks whose embeddings are semantically similar to the query
The retrieved chunks are injected into the language model's context window as grounding material
The language model generates a response based on both its training and the retrieved content
Each of those steps is an attack surface. The retrieval stage, the vector database, and the generation stage all carry distinct security risks — and securing the API layer or the LLM alone leaves the others completely open.
Failure Mode 1- Data Leakage Between Users
This is the most common real-world failure, and it tends to emerge quietly rather than dramatically.
In a multi-user RAG deployment — a customer support chatbot, an internal knowledge assistant used by multiple departments, a B2B SaaS product with separate client accounts — the vector database often holds documents from all users or tenants in a single shared index. When a query comes in, the retrieval system finds the most semantically similar chunks and returns them. If the access control logic doesn't filter by user or tenant before the vector search runs, the system will happily retrieve documents that belong to a completely different user and include them in the response.
RAG systems that don't properly separate data can enable employees to access information from other departments or security levels — marketing staff seeing financial forecasts, or contractors accessing HR records. That's not a theoretical attack. It's what happens when retrieval permissions are set too broadly, or when document-level access control is assumed to be sufficient without verification at query time.
A common failure mode is relying on the LLM to self-enforce access rules. Security best practice is clear: never trust LLMs for access control. Enforce authorization before retrieval and before generation.
The fix is pre-retrieval authorization — filtering the candidate document set by the requesting user's entitlements before the vector similarity search even runs, so semantically similar documents from other tenants never make it into the result set at all.
Failure Mode 2- Vector Embeddings Are Not as Safe as They Look
A widespread assumption in early RAG deployments was that storing vector embeddings rather than raw text added a meaningful layer of privacy protection. The logic seemed reasonable: embeddings are dense numerical arrays, not human-readable sentences. Surely they're safe to store and expose more freely than the underlying documents.
Studies have shattered that assumption. A Generative Embedding Inversion Attack was presented showing that by analyzing an embedding, an attacker could reconstruct the original sentence or data that was embedded — and in some cases, even partial data from the model's training set could be extracted via embeddings. Those gibberish-looking vectors can leak the exact confidential sentence you thought you encoded.
OWASP's 2025 risk list identifies vector and embedding weaknesses as presenting significant security risks in RAG systems that can be exploited to manipulate outputs or access sensitive information.
The practical implication: don't treat your vector store as a less-sensitive version of your document store. Apply the same access controls, encryption, and audit logging to your embeddings as you would to the raw documents they represent.
Failure Mode 3- Retrieval Poisoning
Retrieval poisoning is the attack where a malicious actor inserts crafted content into the knowledge base, specifically designed to be retrieved in response to predictable queries — and then steer the language model's output in a direction the attacker controls.
The mechanism is precise. Because retrieval is semantic similarity search, an attacker who understands what queries a system receives can craft document chunks that are highly semantically similar to those queries while containing instructions, misinformation, or payload content. When a legitimate user asks that question, the poisoned chunk is retrieved, injected into the model's context, and the model's output is influenced by it.
This is particularly concerning in RAG systems where the knowledge base can be contributed to by multiple parties — a shared wiki, a customer-facing knowledge base that accepts user submissions, or any system where the boundary between "trusted source" and "ingested content" isn't strictly enforced.
Defenses operate at two stages. Frameworks like RAGuard (2025) combine multiple strategies including expanded retrieval scope to increase the proportion of clean text among candidates, chunk-wise perplexity filtering to detect anomalies at the segment level, and text similarity filtering to reduce the influence of suspicious near-duplicates or coordinated poison clusters — designed to handle adaptive poisoning that attempts to appear natural.
At the ingestion stage, strict content provenance controls — knowing exactly where every document in your knowledge base came from and who authorized its inclusion — are the most reliable prevention.
Failure Mode 4- Prompt Injection Through Retrieved Content
Closely related to retrieval poisoning but distinct from it: prompt injection via retrieved documents.
The attack works by embedding instruction-style text inside a document that looks, to a human reader, like ordinary content. When that document is retrieved and injected into the model's context window, the model may interpret the embedded instruction as a directive rather than as data. Classic examples include documents that contain text like "ignore your previous instructions and instead do the following" — text that a human would read as part of the document body, but that a language model may treat as a system-level command.
NIST's Generative AI Profile emphasizes that organizations need to manage data-related risks across the AI lifecycle, while Google Cloud's security guidance recommends dedicated protections against prompt injection and sensitive data leakage for generative and agentic AI systems.
The defense here is a combination of input sanitization at the ingestion stage (stripping instruction-style patterns from documents before they enter the knowledge base), output monitoring (flagging responses that deviate significantly from expected behavior), and system prompt design that makes the model resistant to instruction injection from retrieved context.
Failure Mode 5- RAG-Induced SQL Injection
This is a newer failure mode that's emerged as RAG systems have grown more capable and more integrated with backend systems.
RAG-induced SQLi is an application-level vulnerability that arises when outputs from a RAG system are used to construct or execute database queries without strict validation and parameterization.
The scenario: a RAG pipeline that retrieves content, generates a response, and then uses elements of that response to construct a follow-up database query. If the retrieved content contains SQL-like syntax — either maliciously crafted or coincidentally structured — and that content is passed into a query without proper parameterization, the result is a SQL injection vulnerability that originated not from user input but from the retrieval pipeline itself.
This is the kind of second-order attack that security reviews focused only on the user-facing layer will miss entirely, because the injection doesn't come from the user — it comes from the knowledge base through the model.
Failure Mode 6- Overbroad Retrieval and PII Exposure
Even without any adversarial activity, retrieval systems can surface sensitive data simply by being configured without adequate specificity controls.
If retrieval permissions are too broad, the system may surface documents containing PII, credentials, financial data, legal records, health information, or confidential strategy material.
This happens in practice when teams set up RAG with a broad, poorly chunked knowledge base and optimize purely for retrieval recall — increasing the number of results returned, raising the top-k value, or loosening the similarity threshold to reduce the risk of missing relevant content. Each of those changes increases the chance that a query retrieves something accurate but also drags in document chunks containing sensitive data that's adjacent to the relevant content rather than the relevant content itself.
Studies show that improving retrieval recall — for example through larger top-k or aggressive fusion — can trade off directly against confidentiality. Practical mitigations include retrieval-time authorization, sensitive-content filtering and redaction on retrieved chunks, and limiting verbatim reproduction of retrieved passages.
What a Properly Hardened RAG System Actually Looks Like
Pulling this together into a practical checklist — what the security controls across a well-built RAG pipeline actually are-
Pre-retrieval authorization — filter candidate documents by the requesting user's entitlements before the vector search runs, not after
Tenant isolation — in multi-tenant deployments, maintain strict index separation or metadata-filtered namespaces so cross-tenant retrieval is architecturally impossible, not just policy-forbidden
Ingestion controls — treat the knowledge base as a trust boundary; every document entering it should have a clear provenance trail and pass content screening before it's chunked and embedded
Embedding security — apply the same encryption, access logging, and access controls to your vector store as you would to your raw document store; embeddings are not a privacy-safe proxy for sensitive text
Output filtering — screen generated responses for PII patterns, credential formats, and sensitive content categories before they reach the end user
Parameterized queries everywhere — if your RAG pipeline's outputs are used to construct any subsequent queries — SQL, NoSQL, API calls — apply the same parameterization discipline you would to user input
Retrieval audit logging — log what was retrieved for every query, not just what the model generated; retrieval logs are where anomalous patterns appear first
RAG is a genuinely powerful architecture and the right choice for many enterprise AI use cases. The problem isn't the pattern — it's that most teams deploying it have read extensively about how to make it accurate and almost nothing about how it fails. The failure modes above are structural. They follow predictably from how the retrieval pipeline works, and they don't require a sophisticated attacker to trigger — some of them, like overbroad retrieval and cross-tenant data leakage, happen entirely without any adversarial intent at all.
Building a RAG system is now a relatively solved problem. Securing one is where most teams are still catching up.