Most teams treat retrieval augmented generation as a plumbing decision. You point a retriever at a knowledge base, wire the top passages into the prompt, and ship. The security review, if it happens, checks the model endpoint and the API gateway and calls it done. That review misses the part of the system that changed. The moment you added external retrieval, you added a second trust boundary that behaves nothing like the model boundary you already know how to reason about.
The research consensus on this is now settled enough to argue from. RAG grounds generation in external knowledge and cuts hallucination, and that same coupling to an external store is what opens new attack surfaces that standalone models do not have (RAG Security and Privacy). The point of this walkthrough is narrow and practical. Three questions decide whether a RAG deployment is defensible: what the retriever may reach, how a poisoned document propagates once it is in the index, and where authorization is enforced. Get those three wrong and no amount of prompt hardening saves you.
The retriever inherits the old system and expands it
Start with the shape of the pipeline, because the attack surface maps directly onto it. A standard RAG system has four components: the general RAG pipeline, data ingestion, the retriever, and the generator (Securing RAG: A Risk Assessment and Mitigation Framework). Each is a distinct place where an adversary can operate, and the risks in one box do not stay in that box.
The first thing to internalize is that a RAG system does not replace the risk profile of the underlying LLM. It inherits it and adds to it. From a security perspective, RAG systems inherit the risks of the underlying system and expand the attack surface (Securing RAG: A Risk Assessment and Mitigation Framework). That framing matters because it tells you where to spend review time. You still own prompt injection and data leakage from the model. You now also own everything that touches the index.
A useful way to see the expansion is to line up the stages against the threat classes the literature attaches to each. Recent surveys divide the pipeline into retrieval, context construction, and generation, and attach a distinct set of attacks to each stage (Security and Privacy in Retrieval-Augmented Generation).
Figure 1: The seven attack classes one cross-paradigm survey places in the query-time pipeline. Retrieval carries four, generation two, context construction one. Two more sit at training and aggregation, off this chart.
The surveys overlap without converging. Poisoning is the one class every enumeration names, and membership inference appears in most of them. A cross-paradigm analysis places knowledge base poisoning, membership inference, index inference, and retriever manipulation at the retrieval stage, packing-time manipulation at context construction, and prompt injection and model extraction at generation, while gradient leakage and Sybil or collusion attacks sit at training and aggregation and appear only in federated and hybrid deployments (Security and Privacy in Retrieval-Augmented Generation). An end-to-end review guided by the RAG workflow categorizes core threat vectors such as data poisoning, adversarial attacks, and membership inference (Towards Secure Retrieval-Augmented Generation). The OWASP 2025 Top 10 for LLM and generative AI applications names the RAG-specific risks directly: prompt injection, data leakage, embedding inversion, data poisoning, cross-context information conflicts, and unintentional behavior alterations (Securing RAG: A Risk Assessment and Mitigation Framework).
What the retriever may reach
The first design question is scope. The retriever is code that reaches into a store on behalf of a user and pulls text into a context that the model treats as authoritative. Whatever the retriever can reach, the model can be made to speak. That single sentence is the whole confidentiality argument.
The subtle part is that confidentiality in RAG goes past what text comes back. It is also about what an attacker can infer from the system's behavior even when no sensitive document is returned. Adversaries can craft queries to infer whether a specific document exists in the knowledge base, or extract indirect clues about its content, structure, or authorship, even when that document is never explicitly returned (RAG Security and Privacy). The paper makes the stakes concrete: an attacker can probe a medical assistant to determine whether a particular diagnosis appears in the retrieval index, which can reveal information about a named patient (RAG Security and Privacy).
The same paper formalizes this so you can reason about it rather than hand-wave. It proposes what its authors call, to the best of their knowledge, the first formal threat model for RAG. It introduces a taxonomy of adversary types graded by their access to model components, documents, and training data, and gives formal definitions of threats such as document-level membership inference, document reconstruction, and poisoning (RAG Security and Privacy). The design consequence is direct. When you scope what the retriever may reach, you are deciding more than which documents can be returned in text. You are also deciding which documents an attacker can prove exist. A knowledge base partitioned by sensitivity, with retrieval scoped per request, shrinks both surfaces at once.
How a poisoned document propagates
Now the integrity side, which is where RAG surprises people. The knowledge base is not static reference material. It is an input channel. Anything that can write to the index, whether a document ingestion pipeline, a crawler, a wiki, or an upstream data feed, is a path into the model's context.
The asymmetry is what makes poisoning dangerous. Data poisoning attacks can manipulate system outputs by injecting a small amount of malicious text into the knowledge base (Towards Secure Retrieval-Augmented Generation). You do not need to compromise the model or corrupt the majority of the corpus. A few crafted passages that score well against likely queries are enough to steer the answer. Poisoning is prominent enough across the literature that it warrants dedicated defenses. One IEEE BigData paper is built entirely around securing RAG against poisoning attacks (Secure RAG against Poisoning Attacks), and a 2026 taxonomy of RAG attacks and defenses treats poisoning as a first-class category (Securing Retrieval-Augmented Generation: A Taxonomy of Attacks, Defenses, and Future Directions).
Poisoning also connects to injection, and the connection is where the propagation happens. A poisoned document is a delivery vehicle for indirect prompt injection. The retrieved text lands in the same context window as the system prompt and the user query, and the model has no native way to tell instructions in a retrieved passage from instructions you authored. Adversaries can manipulate retrieved evidence through prompt injection, retrieval poisoning, and context manipulation (Security and Privacy in Retrieval-Augmented Generation). The defense literature responds on both sides of the pipeline. The dual-perspective taxonomy organizes defenses into input-side controls such as dynamic access control and adversarial pre-filtering, and output-side controls such as data sanitization and leakage prevention (Towards Secure Retrieval-Augmented Generation). Neither side is sufficient alone. Pre-filtering catches known-bad content at ingestion, and output verification catches what pre-filtering missed once the model has spoken.
One surface deserves a line of its own, because it sits between retrieval and generation where reviews rarely look. The cross-paradigm analysis names context construction and evidence packing as critical but underexplored vulnerability surfaces, and shows how finite context budgets, ordering, truncation, and evidence displacement can affect privacy, factual grounding, and how well the system resists manipulation (Security and Privacy in Retrieval-Augmented Generation). An attacker who understands your packing order can arrange for a poisoned passage to land in the position the model weighs most.
Where authorization belongs
Here is the claim that departs from common practice. Authorization does not belong in the prompt, and it does not belong in the model. It belongs at retrieval, before any document enters the context.
The reason is the trust boundary. Once a document is in the context window, the model treats it as material to reason over, not as a permission to check. Instructions in the system prompt that say do not reveal restricted content are a request, not a control, and a poisoned or injected passage can override that request. The defenses that hold are the ones that never let the wrong document reach the context in the first place. The input-side literature names these directly: dynamic access control and privacy-aware retrieval mechanisms, applied at the retrieval step, are the controls that decide document reach per request (Towards Secure Retrieval-Augmented Generation). Decentralized access control is one of the mechanisms researchers propose specifically to enhance the security of RAG applications (Towards Secure Retrieval-Augmented Generation).
This is also where practitioner training has landed. A hands-on course on building and securing RAG teaches implementing information sensitivity controls that limit the answers the system can provide based on the rights of the user, treating that as a control layer distinct from prompt-injection defense (SEC495: Leveraging LLMs: Building & Securing RAG, Contextual RAG, and Agentic RAG). The two are taught as separate problems because they are separate problems. Sensitivity filtering decides what a user may see. Injection defense decides whether the content you did retrieve can hijack the model. You need both, and putting the first one in the prompt fails both.
Figure 2, my own reading of the defense literature rather than a measured result: no single control holds fully against any of the three threats, which is why the sources argue for controls on both sides of the pipeline.
The practical rule is to enforce the user's identity and clearance at the query, filter the candidate set before ranking, and treat every retrieved passage as untrusted content regardless of where it came from. That aligns authorization with the boundary that holds, rather than the one you wish held.
The walkthrough as a checklist
Put the three questions back together and you have a review that a senior team can run against any RAG deployment. First, scope: what can the retriever reach, and what can an attacker infer from behavior even without a returned document. Second, integrity: what can write to the index, how is written content filtered at ingestion, and how are outputs verified after generation. Third, authorization: is the user's clearance enforced at retrieval, before the context is built, or is it a sentence in the prompt.
The standards give you the vocabulary and the threat classes. The OWASP Top 10 for LLM applications and the NIST AI Risk Management Framework are named as technical frameworks that address specific vulnerabilities in large language models (Securing RAG: A Risk Assessment and Mitigation Framework). What they do not do is make the design decisions for you. Those decisions live in the three questions, and the retriever is where all three converge.