What a Retrieval System Treats as Context
A retrieval-based LLM system is not one component that happens to know how to search. It is a chain of decisions about what to find, what to pass forward, and what the model may do with what it receives. This chapter focuses on those interfaces: the query, the external corpus, the embedding and ranking process, the assembled context, and the LLM or tool layer that consumes it. Understanding who owns each decision makes it possible to see why a relevance result can become a security boundary without becoming an authorization decision.
The distinction matters because a RAG application hides several different kinds of state behind one conversational answer. The corpus has its own history and authority. The retriever creates a temporary ranking for a particular query. The context builder selects and formats a small slice of that ranking. The model then produces language—or, in an agentic system, a request to use another capability. If those transitions are treated as one seamless act of “looking something up,” a security failure at one interface becomes difficult to locate.
Five responsibilities, one operating path
Start with the query. The user’s words are the request that gives the retrieval operation its purpose. They may ask for a summary, a policy explanation, or information about a current event. The application may also add system-owned instructions or transform the request before searching. Whatever the exact design, the query is not the corpus and does not carry the corpus’s authority. It is the condition against which the application asks whether an external item is relevant.
The corpus is the available world of records. It might be a document collection, a mail archive, a repository of technical material, or pages gathered from the web. The important architectural question is not merely where the data is stored. It is who can add, edit, remove, or label items before a retrieval request occurs. Those admission and maintenance decisions belong to the application or the organization that owns the source, not to the LLM that will eventually read the result.
That ownership distinction is easy to lose when an application treats every corpus item as equally usable. A document can be validly stored and still be the wrong authority for a particular answer. It can be current but unverified, relevant but adversarial, or accurate for one purpose and unsafe for another. The retriever can rank such an item highly without knowing any of those facts. A similarity score describes a relationship to the query; it does not certify authorship, accuracy, or permission to issue instructions.
The embedding model provides the comparison language. It maps the query and corpus items into a shared numerical space so that the application can estimate which items are semantically close. This is a powerful compression: a long collection becomes a ranked list that can fit within the model’s limited context. But compression also hides detail. The score records how an item matches the query according to the embedding model, not why the item is reliable or what kind of influence it should have.
The ranking operation turns that comparison into a per-request decision. If the system returns the top K items, it has not proven that they are the best sources in an absolute sense. It has selected the K items that won the competition defined by the query, the corpus, the embedding model, and the scoring rule. A result can therefore fail in two opposite ways. A useful source may be left out because it did not score high enough, or an untrusted source may be included because it scored higher than its competitors.
The context builder is the next interface. It takes the selected items and places them alongside the user’s request and any application instructions. At that point, content that was previously one record among many is available to the LLM during generation. Formatting, labels, ordering, truncation, and source metadata all affect what crosses this interface. The builder may preserve a document’s provenance—or reduce it to undifferentiated text. The LLM cannot be expected to recover authority information that the application discarded before the model saw it.
The LLM owns the interpretation of the assembled input, but it should not own every downstream decision. In a simple RAG system, it generates an answer. In an agentic system, the answer may be a proposed tool call, a message for another agent, or a step in a longer workflow. The model can be highly capable and still operate under an unsafe authority model. If an application lets retrieved text determine which functions are available, which credentials are used, or which irreversible actions occur, it has coupled language interpretation to authorization.
This is why a component tour is not enough. The security meaning lives in what crosses the interfaces. The query crosses into a ranking operation. Corpus items cross from storage into a candidate set. Top-ranked items cross into context. Context crosses into model interpretation. A model output may then cross into a tool or another agent. Each crossing can preserve, weaken, or erase distinctions about provenance and authority.
The sequence has an important asymmetry. The retriever can choose what the model sees, but it does not decide what the model is authorized to do. The model can propose an action, but the application or tool boundary should decide whether that action is permitted. If the same untrusted text is allowed to influence both choices without an independent check, the system has made a hidden dependency: ranking becomes a route to authority.
Relevance is not trust
The most important mistake in this architecture is to treat semantic relevance as a trust label. Suppose a user asks how a business process works. A document that contains the vocabulary of that process may be ranked highly. That tells the system the document is worth considering for the answer. It does not tell the system that every sentence in the document is an instruction from the application owner.
The distinction is clearer if the same document is given two different jobs. As evidence, it may be useful to quote, summarize, or compare. As an instruction source, it would be telling the model how to behave, what information to reveal, or which function to call. Those are different authorities. A RAG application can decide to show the document to the model without deciding that the document may rewrite the model’s governing instructions.
Indirect prompt injection exploits the ambiguity between those jobs. OWASP describes indirect injection as content from an external source—such as a website or file—that changes the model’s behavior when the model interprets it. The user may have asked only for a summary. The retrieved item may contain language aimed at changing that summary or influencing a later action. The security issue is not that retrieval found a relevant document; it is that the system allowed the document’s language to cross into a role with more authority than its provenance justified.
Clear separation can reduce that ambiguity. An application can identify external material as untrusted, preserve its source, and tell the model to use it as data rather than as a replacement for higher-priority instructions. It can also keep source identity and authorization metadata available to deterministic checks outside the model. These measures do not make an external document harmless, and they cannot guarantee that a model will always follow the intended distinction. They make the intended boundary explicit and give later controls something to inspect.
The top-K step is where exposure is decided. Let the corpus contain thousands or millions of items. The model does not read all of them for a single request; it receives the small set selected by the ranking rule. This creates a practical security gate. An item outside the selected set normally cannot influence that request through the RAG context. An item inside the set has crossed into the model’s working material, even if the application later rejects its instructions.
That gate is not binary in the sense of “safe” and “unsafe.” Retrieval can expose an item without the model acting on it. A model may ignore an instruction-like passage, a groundedness check may reject the resulting answer, or a tool boundary may block the requested operation. Conversely, a benign-looking item can create harm if the model infers an unauthorized action from it and the surrounding application accepts the result. Retrieval determines exposure; the later stages determine influence and consequence.
The paper at the center of this series makes that separation the basis of its evaluation. It notes that earlier indirect-injection studies often assumed the malicious content was already in context. That assumption is useful for studying model behavior after exposure, but it leaves the retrieval question unanswered. The paper first examines whether unoptimized malicious text is retrieved under natural queries, then studies how an optimized item can cross the ranking boundary, and finally examines RAG and agentic consequences. The sequence follows the actual system path instead of treating context as a free input.
The same logic explains why the size of a corpus is not a complete security answer. More documents can add legitimate competition, but it can also add more places for untrusted content to enter. What matters for a query is the strength and quality of the items that compete for the top positions, along with the ranking behavior of the actual embedding stack. A larger index is not automatically a more trustworthy index, and a smaller one is not automatically easier to secure.
Boundaries that should remain visible
A useful architecture assigns different questions to different owners. The corpus owner should govern admission, provenance, freshness, and source authority. The retrieval layer should expose how items were selected and preserve enough ranking information to investigate unusual results. The context-building layer should separate external content from application instructions and retain source identity. The model layer should interpret bounded inputs rather than silently expand its own permissions. The tool or agent layer should enforce authorization independently of generated language.
These boundaries also define failure conditions. If corpus admission is uncontrolled, the application begins with an integrity problem. If ranking is manipulated or poorly matched to the query, the wrong content may enter context. If context assembly erases provenance, later reviewers cannot tell what the model relied on. If the model’s output is treated as an authorization token, a retrieval mistake can become a tool action. If all of these concerns are placed in a single prompt, the system has no independent enforcement point when the model interprets the content differently than intended.
OWASP’s mitigation guidance follows this layered logic. It recommends constraining model behavior, defining and validating expected output formats, filtering inputs and outputs, separating external content, enforcing least privilege, and requiring human approval for high-risk operations. Those recommendations are not substitutes for a sound retrieval model. They are controls at different interfaces. A provenance label helps the context boundary; deterministic validation checks what the model returns; least privilege limits what a compromised interpretation can reach; human approval adds a decision point before serious consequences.
The resulting judgment is precise. A retriever answers, “Which items are most similar to this query?” It does not answer, “Which instructions may govern the model?” A context builder answers, “What will the model receive?” It should not answer, “What may the model do?” An LLM can propose a response or action, but a proposal should not become permission merely because it was expressed fluently.
Once those distinctions are explicit, the next question is no longer whether a poisoned item can be written in convincing language. It is how a single injected item can compete for the top results under a natural query without controlling the base model. That is the retrieval interface the next chapter examines.