Retrieval-augmented generation is now the default architecture for enterprise AI. If an organization has built an assistant that answers questions over internal documents, a support bot grounded in a knowledge base, or a research tool that cites company data, it has built a RAG system. The pattern is popular for good reasons. It keeps a model current without retraining, it grounds answers in approved sources, and it gives the appearance of control over what the model says.
That last point is where the trouble starts. RAG feels like a safety mechanism, so most teams treat the retrieval layer as a feature rather than an attack surface. The opposite is closer to the truth. RAG works by taking content the model did not generate and placing it directly into the model's context, where it is read with the same trust as the system prompt and the user's question. The retrieval layer is the mechanism by which outside content reaches the model. That makes it one of the most security-relevant components in the entire system, and it is routinely the least reviewed.
What RAG Actually Does to the Trust Boundary
A model has no reliable way to tell instructions from data. Everything in the context window is text, and the model acts on whatever text is most relevant to the task in front of it. A traditional application keeps a hard boundary between code and the data it processes. RAG erases that boundary by design. The retrieved passage that was supposed to be reference material is read by the model as part of the conversation, and if that passage contains instructions, the model may follow them.
This is why retrieval poisoning matters. An attacker who can place content into a source the RAG system indexes has a path to influence model behavior for every user who later triggers retrieval of that content. The attacker never touches the model, the prompt, or the application. They edit a wiki page, file a support ticket, or upload a document, and they wait for the pipeline to do the rest. The instruction sits dormant in the index until a user's question pulls it into context.
The systems most exposed to this are the ones that index sources with low barriers to contribution. An internal wiki that any employee can edit. A ticketing queue that ingests customer messages. A shared drive that partners can write to. A product that lets users upload files for the assistant to reason over. Every one of those is a writable surface that feeds the index, and most RAG deployments index them without treating the content as untrusted input.
The Failure Modes Worth Planning For
Indirect prompt injection through retrieved content. This is the headline risk. A poisoned document instructs the model to ignore prior guidance, exfiltrate data, suppress a disclaimer, or steer the user toward a particular answer. Because the instruction arrives through retrieval rather than the user's prompt, input filtering on the user's message does nothing to stop it. The defense has to sit on the retrieved content, not the question.
Retrieval scope that ignores the user's permissions. Many RAG systems embed an entire corpus into one vector store and query it without reference to who is asking. The result is a system that will happily retrieve and summarize a document the user was never authorized to open. The model becomes an access-control bypass that no one designed on purpose. This is one of the most common serious flaws in RAG systems, and it is rarely caught because the application's own pages still enforce permissions correctly. The leak only happens through the assistant.
Sensitive data pulled into context and then logged. Retrieved passages frequently land in application logs, traces, and observability tooling. A RAG system that retrieves regulated data is now copying that data into every system that captures its context window. If the logging stack has a weaker control posture than the source repository, the pipeline has quietly downgraded the protection on that data.
Stale or revoked content that never leaves the index. A document gets deleted from the source system. The embedding built from it stays in the vector store. The RAG system continues to retrieve and cite content the organization believes it removed. For regulated data with retention obligations, an index that does not honor deletion is a compliance problem hiding inside an architecture diagram.
Embedding and vector store exposure. The vector database holds a numerical representation of the source corpus. Those embeddings are not encrypted text, but they are not harmless either. Research on embedding inversion has shown that meaningful content can be reconstructed from vectors. A vector store left open, or protected only by an API key in client-side code, is an exposure of the underlying corpus, not a separate low-value asset.
Where the Pipeline Should Be Hardened
RAG security is best approached as a set of controls placed at each stage of the pipeline rather than a single gate. Five stages are worth treating deliberately.
Ingestion. Decide what gets indexed and treat every source as untrusted by default. Content from writable or externally influenced surfaces should be tagged with its provenance at ingestion time so later stages can reason about it. Scanning ingested content for injection patterns will catch the unsophisticated cases, and while it will not catch a determined attacker, the provenance tag will.
Storage. The vector store deserves the same controls as the database behind it. Network isolation, authentication that is not a shared key, encryption at rest, and access logging. Metadata on each chunk should record the source, its sensitivity classification, and the permissions required to view it. That metadata is what makes the next stage possible.
Retrieval. Retrieval must be filtered by the requesting user's identity and permissions, not run against the whole corpus. The cleanest pattern is to pass the user's authorization context into the query and filter on the sensitivity and permission metadata stored with each chunk. If the system cannot answer the question "could this user have opened this document directly," it should not be retrieving that document on their behalf.
Context assembly. When retrieved passages are placed into the prompt, they should be clearly delimited and labeled as reference data, not instructions. This does not make injection impossible, but it gives the model a fighting chance and it gives downstream tooling a structure to work with. Passages from low-trust sources can be marked as such so the model treats them with appropriate caution.
Output. The model's response should be checked before it reaches the user or any downstream system. Citations should be verified against what was actually retrieved. Responses that act on instructions rather than answering the question are a signal that retrieval poisoning may have succeeded. For systems where the model can trigger actions, the action layer needs its own authorization checks that do not trust the model's judgment.
"Teams adopt RAG because it feels safer than letting a model answer from memory. It is safer in some ways. But it trades a hallucination problem for an untrusted-input problem, and the second problem is the one attackers know how to use."
Testing a RAG System Before an Attacker Does
A RAG deployment should not go to production without an exercise that treats the index as a reachable target. The test is straightforward to design. Identify every source the system indexes. For each writable source, place benign marker content carrying an instruction, then ask the assistant questions that should pull that content into context. If the marker instruction changes the model's behavior, the pipeline has confirmed indirect injection and the team has a finding to fix before it is a real one.
The permissions test is equally important and often more revealing. Take a low-privilege account and ask the assistant questions whose answers live in documents that account cannot open directly. If the assistant answers anyway, retrieval is not honoring authorization, and that is a finding worth stopping a launch for.
Neither test requires specialized tooling. They require someone to treat the retrieval layer as adversarial ground rather than assuming the architecture is self-securing. That shift in posture is most of the work.
The Bottom Line
RAG is a sound architecture and it is not going away. The problem is not the pattern. The problem is that the pattern is adopted as a safety feature and then operated without the controls a safety feature would require. Retrieval is the channel through which outside content reaches a model that cannot tell content from commands. Any team running a RAG system in a regulated environment should be able to say who can write to its sources, whether retrieval respects user permissions, and what happens when a poisoned document lands in the index. The teams that can answer those questions have a defensible system. The teams that cannot have an attack surface they have not looked at yet.