Overview

This chapter turns the evidence into a deployment review for RAG. It keeps relevance, provenance, model influence, and authority separate, starting with corpus admission and retrieval exposure, then preserving source identity through context, measuring answer influence, validating outputs, limiting tools, and requiring independent approval for high-impact actions. The study supports embedding-based retrieval as a practical security surface: in controlled benchmarks, optimized items crossed top results and later influenced RAG answers and agent workflows. It does not establish production incident rates, universal transfer, or protection behavior for untested hybrid and reranking pipelines. Control choices should match consequences, since filtering, provenance, approval, and least privilege affect recall, latency, engineering effort, and autonomy.

Learning outcomes

Retrieval is the first RAG security boundary, but model interpretation and application authorization determine whether exposure becomes impact.
A sound review preserves provenance and follows content from corpus admission through retrieval, context, influence, validation, and action approval.
The study supports testing comparable embedding-based systems, not claims about production prevalence, universal transfer, or untested hybrid pipelines.

Keywords

RAGProvenanceValidationAuthorizationLeast privilegeMonitoring

Designing the Boundary Before the Model Acts

The central question is no longer whether a retrieval-augmented system can find useful information. It is whether the system can keep relevance, provenance, model influence, and authority from collapsing into one decision. The evidence considered here supports a direct answer: retrieval is the first security boundary in RAG because it determines which external text becomes available for model interpretation. A poisoned item must cross that boundary before it can alter an answer or reach an agent, but retrieval is only the first gate. The model and application still determine whether exposure becomes influence, and whether influence becomes action.

That conclusion changes how a RAG or retrieval-augmented agent should be reviewed. A system is not secure merely because its model refuses some harmful requests, because its embedding model is large, or because a detector recognizes one conspicuous trigger. A defensible design asks who can place content in the corpus, how the retriever selects it, what provenance survives context assembly, what the model is allowed to propose, and which independent control authorizes an external effect. It measures the gates separately and makes uncertainty visible.

The boundary is where data becomes context

Retrieval is a security boundary for a simple causal reason: it changes the set of facts and instructions available to the model for a particular request. Before retrieval, a document may exist in an external corpus without affecting that request. After it enters the selected top-K results, it is present in the model’s working context. That transition is controlled by the user query, the clean corpus, the embedding model, the ranking rule, and the cutoff. It is a security decision even when the application created it for an ordinary quality goal.

The decision is not an authorization decision. A retriever answers which item is similar to the query. It does not establish that the item is accurate, that its author is trusted, or that sentences inside it may govern the model. A relevant email can still be untrusted. A current web page can still be unsuitable as an instruction source. An approved policy can be relevant evidence without having permission to order an agent to change a record. The system has to carry those distinctions separately because semantic similarity does not contain them.

This is why indirect prompt injection is different from a user simply writing an unwanted instruction into a prompt. In an indirect injection, the instruction-like content arrives through an external source that the user asked the application to search, summarize, or use. The user may never intend to give that source authority. Yet if the application retrieves the item and presents it to the LLM without a durable separation between data and governing instructions, the model may treat the external language as relevant to its own behavior.

The first gate is therefore exposure. A test that starts with malicious text already in the LLM’s context has removed the retrieval question. It can still reveal something about post-retrieval model behavior, but it cannot show whether natural queries and legitimate corpus competition would have surfaced the item. The paper’s contribution is to restore that missing part of the path. It asks whether a single inserted item can be optimized to enter the top results under natural queries, then examines what happens after the item is exposed.

The reported retrieval evidence makes the boundary concrete. Across 11 BEIR test collections and 100 sampled queries per collection, the study injects one malicious item for each query and measures Recall@5: whether the item appears among the five retrieved results. In the appendix, average Recall@5 rises from 28.4% with a three-token optimized trigger to 63.0% with five tokens and 94.1% with ten tokens. Five named datasets reach exactly 100% at ten tokens in the appendix table, while Natural Questions and FEVER are just below 100%. The unoptimized version fails to retrieve the malicious text across the datasets, while repeating the user query is generally weaker than the optimized approach at comparable lengths.

Those numbers should be read as exposure results under a controlled protocol.

Published by DeepMox

FAQ

What should a RAG deployment review check before indexing?

Before indexing, a RAG deployment review should check who can add or modify items, each source’s provenance, freshness and authority fields, and whether those fields survive transformations.

How should RAG systems handle high-impact tool actions?

RAG systems should require an independent authorization check and, for high-impact operations, human approval before a generated request can cause an external effect.

How should security controls differ between read-only and agentic RAG?

Read-only and agentic RAG should use different control thresholds because tool access and external effects make agentic workflows more consequential; both should treat retrieved content as untrusted until authorized.

Previous12 minRAG Defense: Why Simple Filters Fall Short

All chaptersBack to Topic

RAG Security Design: Before the Model Acts

Designing the Boundary Before the Model Acts

The boundary is where data becomes context

FAQ