Why Retrieval Is a Security Boundary
The subject of this series is the retrieval-augmented language model: a system that searches an external collection before asking a large language model (LLM) to answer, summarize, or act. This opening chapter focuses on the point where that search becomes a security decision. By the end, you should be able to trace a request from the user’s question to the external corpus, the retrieved context, and the model’s eventual answer or action—and understand why “will this content be retrieved?” comes before “what will the model do with it?”
That order matters because retrieval systems are usually introduced as accuracy machinery. They give a model access to newer or more specialized information than its original training could contain: a company’s documents, a collection of emails, a set of manuals, or current web pages. The model appears to be doing something simple. It finds relevant material, reads it, and responds.
But “relevant” and “trusted” are not the same property. A retriever ranks text by its relationship to a query. It does not, by that fact alone, establish who wrote the text, whether it is authoritative, or whether the model should obey sentences inside it. If an application lets retrieved text influence a model that can answer questions, call functions, or coordinate other agents, the retrieval decision is also the first decision about what an untrusted party may place in the model’s field of view.
The system behind the answer
A retrieval-augmented generation (RAG) system has at least four important parts. First, there is a user query: a request such as asking for a policy summary or an explanation of a recent event. Second, there is an external corpus, which may contain documents, messages, files, records, or web material. Third, a retriever compares the query with that corpus and selects a small set of results. Fourth, the LLM receives the query together with those results and generates an answer. In an agentic system, the last stage may also include calls to tools or handoffs to other agents.
The retriever commonly represents the query and documents as vectors—numeric descriptions used to compare semantic similarity. It then returns the top-K items, meaning the K highest-ranked matches. The exact value of K is an implementation choice, but the important relationship is stable: a large corpus is narrowed to the few items that will enter the model’s context.
That narrowing creates a boundary between information that exists somewhere in the corpus and information that can affect the next model response. A document left outside the retrieved set may have no influence on that request. A document inside the set is now present at the point where the LLM interprets language. The application has not necessarily declared the document trustworthy; it has made it available. Yet the model may not reliably preserve that distinction unless the surrounding system does more work.
The same pattern appears beyond a question-answering chatbot. A coding assistant may retrieve documentation before suggesting a change. An enterprise agent may search messages before preparing a response. A research tool may retrieve papers before drafting a synthesis. The retrieval layer is what connects the outside world to the model’s context in each case. The business consequences change with the application, but the security relationship remains: external content crosses into a model-controlled workflow.
The diagram shows why it is misleading to speak about “the model” as though it were the whole product. The corpus determines what can be found. The retriever determines what is exposed. The context builder determines how the material is presented. The LLM interprets it, and the application decides what outputs or actions are permitted. A weakness in one stage can be amplified by the next.
When data can speak like an instruction
Prompt injection is the broad problem in which input changes an LLM’s behavior or output in an unintended way. OWASP distinguishes two important paths. A direct prompt injection comes from the user’s own input. The user deliberately—or sometimes accidentally—places instruction-like material in the request and changes the model’s behavior.
An indirect prompt injection arrives through an external source. The user may ask for a summary of a page, a search over internal files, or an answer based on email. Somewhere in the material returned by that operation, there may be text aimed at the model rather than at the human reader. If the model interprets that text as an instruction, the external source has influenced the model without the user explicitly placing that instruction in the conversation.
This is not a claim that every sentence in a retrieved document will be obeyed. It is a claim about the channel through which influence can arrive. The user’s request and the retrieved material are both represented as language in or near the model’s context. Unless the application clearly separates their roles and validates what follows, the model may treat a document’s imperative language as relevant to its own behavior.
The distinction also explains why RAG and fine-tuning do not, by themselves, remove prompt-injection risk. Retrieval can make answers more current and useful, but it also imports content whose origin and intent may be outside the application’s control. Fine-tuning can shape behavior, but it does not turn every future external document into a trusted source. The system still has to decide what content enters context and what authority the model has after reading it.
The possible consequences depend on that authority. In a read-only assistant, an injection might distort a summary or produce a misleading answer. In a system with access to private records, it might encourage inappropriate disclosure. In an agent that can send messages, modify data, or invoke tools, the same kind of influence can become an external action. OWASP therefore treats least privilege, output validation, human approval for high-risk operations, and separation of external content as parts of the defense—not as optional additions after the model is deployed.
The first gate is not the final gate
The central question for indirect injection has two parts. First: does the poisoned item enter the model’s context? Second: once it is there, does the model or agent allow it to affect an answer or action? The first is a retrieval question. The second is a model-and-application question. They are related, but they are not interchangeable measurements.
Earlier demonstrations often made the second question easy to study by assuming the malicious content was already present. A test might designate a particular email as the one the user wants, put the item in a tiny corpus, or place an optimized trigger in the query itself. Those arrangements can show what happens after the model sees the content. They do not show whether a natural query would cause a poisoned item to beat the legitimate documents that normally compete for the top results.
The retrieval barrier was therefore a meaningful uncertainty. In the study examined by this series, unoptimized malicious text was not retrieved under natural queries in the initial benchmark setting. That result does not mean indirect injection is harmless. It means that a post-retrieval demonstration cannot settle the practical risk unless the path into context is also tested.
The later result is more consequential precisely because it addresses that missing gate. The researchers model a single injected item and a black-box attacker who does not control the LLM or inspect the corpus. They separate the content that carries an attack objective from a short retrieval-oriented trigger, then optimize the combined item for similarity to natural queries. Across controlled retrieval benchmarks, the optimized item often enters the top results. The paper then follows the retrieved content into RAG and agentic workflows, where the model’s ability to generate answers or use tools determines what happens next.
The point is not that a particular optimization procedure should be treated as a universal exploit, nor that every corpus is equally exposed. The paper evaluates embedding-based retrieval, sampled benchmark queries, and controlled agent workflows; it does not test every hybrid retriever or reranking system, and it does not measure the incident rate of live deployments. Its more durable lesson is about where to look. A security review that tests only the LLM after handing it a malicious document has skipped the boundary most responsible for deciding whether that document will be seen.
That boundary should also not be overburdened. Retrieval is the first security boundary in the path from external data to model behavior, not the only one. A system can reject a suspicious item before context assembly, mark retrieved material as untrusted, check whether an answer is grounded in authorized sources, restrict the tools the model can call, and require a person to approve consequential actions. These measures address different failure points. None turns prompt injection into a solved problem, but together they can keep a ranking decision from silently becoming an authorization decision.
The practical judgment for this series is therefore simple but demanding: treat retrieval as part of the security perimeter. Measure whether untrusted content can cross into context. Then measure whether it can alter an answer, trigger a tool, or pass through an agent handoff. Keeping those questions separate makes the system easier to reason about—and makes it harder to mistake a useful search result for permission to act.