Retrieval-Augmented Generation is now the standard architecture for production AI systems that need to answer questions about private or recent data. The pattern is simple: embed documents into a vector database, retrieve semantically similar chunks at query time, and feed them to an LLM as context. It's elegant, scalable, and — in its default form — deeply trusting.
The trust model of a RAG system is implicit but significant: the LLM treats retrieved documents as ground truth. When the model is asked "What is our refund policy?" it reads the retrieved chunks and answers from them, with no inherent mechanism to question their authenticity. This trust is the attack surface.
How RAG Poisoning Works
An attacker who can write to the knowledge base — whether through a compromised ingestion pipeline, a public wiki with write access, or uploaded documents — can inject content designed to be retrieved for specific queries. The injected document doesn't need to be the only result; it just needs to appear in context. Once retrieved, it can contain embedded prompt injection: instructions disguised as legitimate content that redirect the model's behavior.
The attack compounds in agentic systems. A RAG-powered agent that can take actions — send emails, create calendar invites, execute API calls — becomes a vehicle for those actions once its context is poisoned. The attacker's instructions ride inside seemingly legitimate retrieved content, invisible to any log that only records the user's query.
"The vector database is the new SQL table. The question is whether anyone is treating it with the same security discipline."
The Defense Surface
Unlike prompt injection in the input layer, RAG poisoning is easier to mitigate in principle: you control the knowledge base. Access controls, write audit logs, and document provenance tracking are all conventional security measures that apply directly. The failure mode is organizational — teams that treat the vector database as an append-only cache rather than as a security boundary.
The harder problem is external RAG — systems that retrieve from the live web, third-party APIs, or user-provided documents. Here the attack surface is unbounded. The appropriate model is to treat all retrieved content as untrusted input, never as trusted instructions — but current LLM architectures make this distinction difficult to enforce architecturally. Until that changes, the most reliable defense is careful scoping: don't build RAG agents that can take irreversible actions without explicit human confirmation.