Retrieval-augmented generation quietly became the default way enterprises ship useful AI. Instead of fine-tuning a model on proprietary data, teams bolt a retriever onto a general-purpose LLM and feed it relevant documents at query time. It is cheaper, faster to update, and keeps sensitive data out of model weights. It also introduces an entirely new attack surface that most security programs have not yet mapped, because the riskiest part of a RAG system is not the model at all, it is everything feeding it.
The core problem is trust. A RAG pipeline pulls chunks of text from a vector store and pastes them into the prompt as authoritative context. If an attacker can influence what lands in that store, they can influence what the model says and does. A poisoned support ticket, a booby-trapped PDF in a shared drive, a wiki page edited by a disgruntled contractor, any of these can carry instructions that the model reads as gospel. This is indirect prompt injection, and RAG is its ideal delivery mechanism precisely because the system is designed to ingest untrusted content and act on it.
"In a RAG system, your knowledge base is no longer just data. It is executable instruction, and you should secure it as if an attacker can write to it, because often they can."
Start by treating the ingestion path as a security boundary. Every document that enters the vector store should carry provenance, who created it, from which source, and with what trust level, so that retrieval can prefer high-trust content and flag the rest. Sanitize and strip content during ingestion the way you would untrusted user input, and isolate tenants so one customer's documents can never surface in another's responses. The most damaging RAG breaches in production have been mundane access-control failures: a retriever with broad permissions cheerfully returning documents the asking user was never supposed to see.
At query time, the controls shift to containment. Keep the retrieved context clearly delimited from system instructions so the model knows the difference between policy and payload. Constrain what the model is allowed to do with that context, especially when RAG feeds an agent that can call tools, send email, or query a database. Log the full chain, the query, the chunks retrieved, and the response, so that when something goes wrong you can reconstruct exactly which document drove the behavior. Output filtering matters too, because a retriever that surfaces a customer record can just as easily leak it into a reply.
The strategic takeaway is that RAG collapses the old boundary between data and code. The documents in your knowledge base now shape system behavior, which means data governance and application security are no longer separate disciplines for these workloads. Inventory your pipelines, threat-model each retriever as a place where untrusted input meets privileged action, and build the provenance, isolation, and logging before you scale. The organizations that get this right will keep shipping AI features fast; the ones that skip it are quietly running an injection vulnerability with a friendly chat interface on top.