RAG is the security blind spot in most AI deployments

01 Where RAG breaks

Document ingestion comes first. It converts your files into embeddings and writes them into a vector store. Poison a document here, with hidden text or crafted metadata, and the payload rides straight into the knowledge base. The vector database sits next. It holds those embeddings and returns the chunks that look semantically close to a query. Weak access control on that store means a well-shaped query pulls back records the user should never reach.

The retrieval layer then queries the store on the user's behalf and passes the matching chunks to the model as context. This is where injected instructions inside a retrieved document get their moment, because the model treats retrieved context as trusted. Finally the generation layer synthesises an answer from that context plus the user's question, and that is where data leaks into the response, where citations get hallucinated, and where one user's material bleeds into another user's answer.

02 The six weaknesses we find

Six flaws account for most of what we surface in RAG assessments. The first is indirect prompt injection through document poisoning. An attacker plants instructions inside a document that later gets ingested. A poisoned PDF might carry invisible text telling the model to ignore prior instructions and print the system prompt. When a routine question retrieves that document, the attack fires on its own. NVIDIA's AI Red Team reported in 2025 that indirect prompt injection succeeds in 61% of RAG systems that lack dedicated input sanitisation [ NVIDIA AI Red Team 2025 ] .

The second is cross-tenant data leakage. In multi-tenant deployments, weak access control on the vector store lets one tenant's query retrieve another tenant's documents. It is the RAG version of an insecure direct object reference, an old web flaw re-emerging in AI architecture. We find some form of cross-tenant leakage in 67% of the multi-tenant RAG systems we assess, from partial exposure to full knowledge-base access across the boundary. The third is metadata injection and filter bypass. Systems restrict retrieval by department, classification or role, but because the store ranks on semantic similarity rather than strict permission, a crafted query slips past the filter and returns restricted material anyway.

The fourth is context window stuffing. Force the retrieval stage to return a flood of chunks and you push the legitimate safety instructions out of the model's working context. Attacker-controlled content then dominates the model's attention. The fifth is the one that surprises most teams. Cornell University demonstrated in 2025 that embeddings can be reversed to reconstruct the original text with around 92% accuracy for common models such as text-embedding-ada-002 [ Cornell 2025 ] . Read-only access to your vector store is enough to rebuild the source documents, which kills the assumption that an embedding is a safely one-way function.

The sixth is the most durable. Poisoning the knowledge base is not session-specific like a live injection. It is persistent. A single malicious document affects every user who later triggers its retrieval, and it can redirect people to phishing pages through AI-generated answers, exfiltrate data inside benign-looking output, spread misinformation that appears to come from authoritative internal files, or hold a backdoor open until someone finds and removes it.

03 Why your scanner misses it

Traditional testing checks network security, web application flaws and authentication. RAG weaknesses live one layer above all of that, and four properties keep them out of a scanner's reach. They are semantic, not syntactic, so they exploit meaning rather than a code pattern, and a SQL injection scanner cannot read intent in a poisoned document. They are probabilistic, so the same attack might land 70% of the time rather than every time, which defeats a tool that expects a clean repeat. They are cross-component, spanning the document pipeline, the vector store and the model, three systems usually owned by three teams. And they are context-dependent, so success turns on what else sits in the knowledge base and how the model is behaving right now.

This is not a paper threat. The McKinsey Lilli breach exposed 3.68 million RAG document chunks and 266,000 OpenAI vector stores through a SQL injection in the API layer, opening the proprietary knowledge base behind the firm's AI platform. It amounted to 46.5 million messages of real-world proof [ CodeWall 2026 ] . It is not alone. Samsung engineers in 2023 fed proprietary chip designs into an AI-backed knowledge base that then became retrievable by other users. Through 2025, several law firms found their AI research assistants surfacing confidential client documents from unrelated matters because RAG access controls were too loose. In 2026, healthcare RAG systems produced HIPAA violations when patient records ingested into clinical assistants became retrievable across departmental lines.

04 Closing the pipeline

The fix is finite and mappable. Enforce access permissions at the vector store, not just the application, so every chunk carries its own access metadata. Sanitise documents on ingestion, scanning for hidden text, invisible characters and embedded instructions before anything becomes an embedding. Filter the output with a secondary model that checks each answer for data leakage, credential exposure and injection markers. Audit every retrieval query and the chunks it returns, and alert on unusual access patterns across tenant boundaries. Harden the embedding model against inversion, cap the number of retrieved chunks so the context cannot be stuffed, and audit the knowledge base on a schedule for documents that should not be there. Then test the whole thing adversarially, on a repeating cycle, with the six techniques above.

The regulator is already in this conversation. GDPR Article 25 requires data protection by design, and a RAG system leaking cross-tenant data fails it outright. EU AI Act Article 9 obliges high-risk systems to manage the risk of reasonably foreseeable misuse, and RAG poisoning is now well documented, so it is foreseeable by definition, with the August 2026 deadline closing in [ EU 2024/1689 ] . The NIST AI Risk Management Framework names data integrity and provenance directly, both of which poisoning attacks compromise [ NIST AI RMF ] . The numbers concentrate the mind: up to €15 million or 3% of global turnover for high-risk breaches under the AI Act, and €20 million or 4% under GDPR. Once your pipeline is closed, RTP Robin lets your team re-run these same attacks as the knowledge base changes, so the picture stays current between formal assessments rather than ageing the day the report is signed.