Because retrieved documents can carry instructions that look like context to the model, not like attacker input. Once the model treats those instructions as authoritative, the agent can be steered into unsafe outputs or tool calls. Instruction and data separation is essential when RAG is connected to actions or downstream systems.
How retrieved documents become an attack surface for agents
Retrieved documents are not just passive reference material. In an agentic workflow, they can become an input channel that competes with the system prompt, user intent, and policy rules. If the model is not strongly separating instructions from content, a malicious document can present attacker text as though it were trusted guidance, especially when retrieval is treated as authoritative context.
That is why the risk is fundamentally about instruction precedence. The agent may not know which text is data and which text is an instruction unless the surrounding architecture makes that separation explicit. When retrieval feeds a model that can act, the consequence is not limited to bad output, it can become unsafe tool use, unintended disclosure, or an action taken on behalf of the attacker.
For agent builders, this is one reason prompt injection is treated as a core agentic AI threat in the OWASP Agentic AI Top 10, and why document trust boundaries need to be designed before the agent is allowed to search, summarize, or execute.
Why RAG makes the problem worse when actions are enabled
Retrieval-augmented generation increases exposure because it expands the set of text the model may treat as relevant at runtime. In a plain chat setting, bad instructions in a document may still produce a bad answer. In an agent setting, the same text can influence tool selection, prompt construction, branching logic, memory updates, or downstream calls to APIs and systems of record.
The key failure mode is conflation. A retrieved passage can look like domain evidence, but if it contains embedded instructions, the agent may follow them as if they were part of the task. This is especially dangerous when retrieval sources include emails, tickets, web pages, wiki pages, logs, or other user-generated content that is not curated as policy-safe input. The more the agent is allowed to take actions, the more a poisoned document can convert a text-level issue into a control-plane issue.
That pattern is visible in real-world agent incidents and research, including NHIMG’s Agentic AI Security Guide, which treats prompt injection, tool misuse, and identity abuse as linked risks rather than separate curiosities.
Document-driven attacks also intersect with browsing and desktop automation. When an agent reads a page, file, or retrieved snippet and then acts inside a live session, the retrieved content can steer a signed-in workflow into the wrong site, wrong command, or wrong approval path, which is why the Browser and Computer-Use Agent Security Guide focuses on isolation, site scope, and confirmation boundaries.
How practitioners should reduce prompt-injection exposure in retrieval pipelines
Defensive design starts with treating retrieval as untrusted content, even when the source is internally hosted. The agent should receive retrieved text as data with explicit role labeling, and the system should avoid giving documents the same authority as instructions, policies, or tool directives. If the application cannot preserve that separation, the safe default is to narrow the agent’s action scope before broadening retrieval.
Good practice is to layer controls, not depend on a single filter. Useful controls include source allowlisting, content sanitization, instruction stripping where appropriate, per-document trust scoring, and explicit user confirmation before any high-impact action. Where the agent can reach tools or production systems, authorization should be task-scoped and constrained to the minimum necessary to complete the request, as detailed in the AI Agent Authorisation Guide.
Threat modelling also matters because not every retrieval source has the same risk. A trusted knowledge base, a live web page, and an end-user uploaded file should not be given equivalent authority. The right question is not whether the document is relevant, but whether it is allowed to influence instruction flow, tool calls, or memory. NHIMG’s Threat Modelling AI Agents guide is useful here because it maps those trust boundaries to concrete agent behaviours.
Risk and Threat Considerations
Retrieved documents become risky when the agent lacks a hard boundary between reference material and executable instruction. The practical threat is not just a misleading answer, it is attacker-controlled steering of tool use, approvals, data access, or follow-on actions through content the model was supposed to merely read.
Failure mechanism: The model assigns inappropriate authority to retrieved text, then propagates that authority into generation, tool selection, or state updates. A poisoned document can therefore act like a hidden control input, especially when the retrieval layer ingests untrusted or user-generated content.
Impact: The agent may reveal secrets, send data to the wrong place, take unauthorized actions, or chain into other systems with the user’s or agent’s privileges. At scale, the same weakness can turn a single bad document into repeated compromise across many sessions or workflows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI06 — Memory & Context Poisoning | Retrieved documents can poison agent context and alter behavior through hidden instructions. |
| ASI02 — Tool Misuse | Prompt injection becomes material when retrieved text steers unsafe tool calls or actions. | |
| ASI03 — Identity & Privilege Abuse | Injected instructions can abuse delegated authority when the agent acts on the user’s behalf. | |
| Recommendation — Separate data from instructions and validate retrieved content before it can influence agent state. Restrict tool access so retrieved content cannot trigger high-impact actions without policy checks. Limit agent privileges to task-scoped access and require approval for sensitive operations. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Injected retrieval can steer agents into disclosing secrets or sensitive context. |
| NHI-05 — Overprivileged NHI | The risk rises when agents have broad access that poisoned documents can exploit. | |
| NHI-10 — Human Use of NHI | Users often assume retrieved text is safe, then let the agent act on it without review. | |
| Recommendation — Block untrusted retrieval from reaching secret-bearing prompts or privileged outputs. Reduce agent privilege so retrieved instructions cannot translate into broad system access. Require human review before an agent executes retrieved instructions with real-world impact. | ||
| NIST AI RMF | GV — Govern | Prompt injection in agents is a governance issue for AI risk ownership and control boundaries. |
| MAP — Map | Understanding retrieval trust boundaries is part of mapping AI system context and risk. | |
| Recommendation — Define governance for which retrieved content may influence agent decisions and actions. Map retrieval sources, trust boundaries, and downstream actions before deployment. | ||
| NIST Zero Trust (SP 800-207) | PA — Policy Enforcement | Zero trust helps ensure retrieved content cannot bypass explicit authorization policy. |
| Recommendation — Enforce policy checks before any agent action derived from retrieved content. | ||
| MITRE ATT&CK | T1566 — Phishing | Malicious retrieved content often arrives through phishing or social engineering content. |
| Recommendation — Hunt for phishing-driven document delivery that seeds prompt injection payloads. | ||
Practitioner Guidance
What to verify: Confirm that the agent can distinguish retrieved facts from executable instructions before any tool call is allowed. If a document can change tool choice, memory, or approval flow, it is not being treated as inert context.
Decision rule: If the retrieved source is not fully trusted, do not let it directly influence actions that are hard to reverse, externally visible, or privileged. Require a separate policy check or human confirmation for those steps.
What good looks like: Retrieval improves answer quality without expanding authority. The agent can cite documents, but cannot silently inherit their intent, their embedded commands, or their hidden assumptions.
Practitioner takeaway: The control objective is not to eliminate retrieval, it is to make sure retrieved content can inform the agent without being able to command it.
Related resources from NHI Mgmt Group
- Why do coding agents increase the risk of prompt injection in enterprise environments?
- Why do autonomous AI agents increase the risk of prompt injection and agent hijacking?
- Why do RAG and AI agents increase prompt injection risk?
- What is the difference between prompt injection risk and identity abuse in agents?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 13, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org