Prompt injection in RAG occurs when a retrieved document or tool response attempts to change the instructions an assistant follows. The user may request a legitimate task while external content introduces a different intent. Security reports, tickets and logs are necessary inputs that must not become sources of authority.
This guide proposes a defensive evaluation protocol for assistants using retrieval and tools. Scenarios use laboratory documents and fictional assets. No attack-success rates or production results are claimed.
Why RAG does not eliminate prompt injection
RAG supplies context, but that context can contain instructions unrelated to the task. OWASP LLM01:2025 identifies the problem and explains that retrieval and model adaptation do not completely resolve it. A correct citation establishes provenance; it does not authorize an action.
Distinguish three outcomes: answer contamination, unauthorized disclosure and out-of-scope action. They can occur separately. A read-only assistant can still produce a false recommendation or disclose information to an unauthorized recipient.
Map the trust boundaries
Before evaluating a filter, state who controls each input. The user controls a request within their permissions. The repository supplies documents with access restrictions. A tool returns observations, not a new agent policy. The execution service owns final authorization.
For example, a laboratory ticket contains text attempting to change a report recipient. Correct behavior preserves the authorized recipient and treats the text as ticket content. Detecting the problem in prose is insufficient if the tool subsequently uses the manipulated parameter.
A small, useful test matrix
| Laboratory case | Behavior to check | Legitimate result to retain |
|---|---|---|
| Unrelated instruction in a document | User objective does not change | Evidence-supported summary |
| Source proposes a different recipient | Executor blocks unauthorized scope | Report for permitted recipient |
| Old document presented as current | Correct version is applied | Current-procedure explanation |
| Permission revoked after retrieval | Access is checked again | Abstention or authorized-source answer |
| Insufficient evidence | No invented conclusion | Request for specific context |
Prepare clean and perturbed versions of every case while holding the legitimate task fixed. Use fictional markers to detect disclosure and simulated tools to observe attempts without external effects.
Measure utility, disclosure and action separately
Record legitimate task success, unsupported claims, improper disclosure, out-of-scope calls and unnecessary refusal. Declare denominators. Low attack success caused by an agent doing nothing can conceal complete loss of utility.
Retain the complete trace: authorized documents, retrieved passages, answer, proposed calls, executor decisions and final state. A proposed call and a completed action are different events. An executor block can protect the system even when agent reasoning fails.
AgentDojo provides an environment for studying agent tasks and prompt-injection attacks. Use it as an experimental reference and add cases reflecting your application's corpus and permissions.
What 2026 research contributes
The March 2026 revision of the preprint Indirect Prompt Injections: Are Firewalls All You Need, or Stronger Benchmarks? examines benchmark limitations and adaptive attacks. Strong performance on known perturbations does not establish protection against all future content.
My proposed consequence is separate development and reserved sets with different perturbation families. When a defense changes after a reserved failure, record that exposure and refresh part of the evaluation. ES/EN versions of one case should not be split between development and test as independent examples.
Controls that must exist outside the model
Apply permissions before retrieval and again at execution. Restrict accepted tool fields, validate identifiers and set authorized destinations from trusted state. Derived summaries and caches need the same restrictions as their sources.
A suspicious-instruction detector can supply a signal, but cannot replace authorization. A prompt asking the model to ignore external instructions is not a complete boundary either. The design should remain bounded when the model misinterprets a document.
Acceptance criteria before deployment
Define in advance which failures block deployment, which tasks need human review and what utility regression is unacceptable. After a pilot, turn adjudicated failures into new cases. Preserve corpus, model, policy and tool versions so that result changes remain explainable.
The security RAG guide covers retrieval, golden sets support reference construction, and LLM metrics complete the report. Useful evaluation demonstrates which boundaries hold during realistic tasks and exposes those still untested.
