When that happens, the agent may carry out unintended actions, such as exposing sensitive data, calling restricted APIs, or altering a workflow it was not meant to touch. The attack succeeds because the malicious text enters through a trusted retrieval path. The result is compromise of execution integrity, often without any obvious infrastructure alert or direct attacker interaction.
Why Malicious Retrieved Content Is So Dangerous for AI Agents
AI agents are vulnerable here because retrieval often arrives wrapped in the same trust boundary as legitimate knowledge. If the agent cannot distinguish reference material from instruction, the malicious passage can redirect tool use, data handling, or workflow decisions without any obvious sign that the prompt chain was tampered with. That makes the issue more than prompt quality; it is an execution-integrity problem.
NHIMG’s research on agent behaviour shows why this matters operationally. In the AI Agents: The New Attack Surface report, 80% of organisations reported agent actions beyond intended scope, including unauthorised system access and sensitive data sharing. For teams building retrieval-augmented workflows, that is the clearest warning sign that trust in the source path is not the same as trust in the content itself.
In practice, many security teams discover the problem only after the agent has already acted on text that was never meant to be executable.
How the Abuse Works Inside an Agentic Workflow
The usual failure chain is simple: an agent retrieves content, the content includes hidden or overt instructions, and the model treats those instructions as higher-priority guidance than the user’s intent or the system’s policy. That can happen in search results, support tickets, knowledge bases, emails, documents, web pages, or any tool output that is later fed back into the model.
What makes this especially risky is that the agent often has real authority. It may be allowed to call APIs, update records, send messages, open tickets, or read scoped data on the user’s behalf. Once malicious instructions are interpreted as part of the task, the agent can become the execution layer for an attacker’s intent. This is why static role-based checks are not enough on their own: the access may be valid, but the decision to use it is being manipulated in real time.
Practical controls usually need to separate three things:
- content ingestion, so retrieved text is treated as untrusted by default
- instruction hierarchy, so system policy and user intent cannot be overwritten by retrieved content
- action gating, so sensitive tool calls require explicit validation before execution
For agentic systems, the most useful design pattern is to assume that any retrieved item can be adversarial until proven otherwise. That means limiting what the model can do with raw retrieval, constraining the tools it can invoke, and using short-lived credentials or just-in-time approval for high-impact actions. The OWASP Agentic AI Top 10 is useful here because it frames instruction manipulation as a governance and execution problem, not only a prompt-engineering problem.
NHIMG’s OWASP Agentic Applications Top 10 also helps practitioners think about where the trust boundary breaks down between retrieved context and agent action.
These controls tend to break down when agents are given broad tool access and long-lived credentials, because a single poisoned retrieval can turn into a direct, authenticated action path.
Where the Edge Cases and Failure Modes Show Up
Tighter guardrails often reduce autonomy and increase workflow friction, so organisations have to balance agent usefulness against the cost of verification.
Not every malicious instruction is overt. Some are embedded as indirect policy nudges, role-play framing, or content that tries to override the agent’s priorities without looking like a command. Current guidance suggests treating these as the same class of problem when the content can influence tool use or data disclosure. There is no universal standard for perfect detection yet, so confidence should come from containment and approval controls rather than from assuming a model will reliably “notice” the attack.
The biggest edge cases appear when the agent is operating across multiple systems. A harmless-looking retrieval in one source can cause the agent to pull sensitive data from another source, then forward it into a third system. That creates a cross-domain trust chain that is hard to inspect after the fact. Teams also underestimate how quickly this becomes a scale problem: the more agents, tools, and retrieval sources involved, the harder it is to tell whether an action was user-directed, policy-directed, or content-directed.
Risk and Threat Considerations
This is a material integrity and exposure risk because the attacker does not need to break the model directly. They only need to place instructions into content that the agent is likely to retrieve and trust. Once the agent acts on that content, the result can be unauthorised disclosure, workflow tampering, or abuse of privileged tools through a legitimate session.
Failure mechanism: The attack succeeds when the agent fails to separate untrusted retrieved text from trusted operational instructions, then executes actions with the permissions already attached to its toolchain or workload identity.
Impact: Sensitive data may be exposed, restricted systems may be touched, and audit trails may show apparently valid agent activity even though the triggering instruction came from hostile content.
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, CSA MAESTRO and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 — Prompt Injection / Instruction Manipulation | Retrieved malicious instructions are an instruction-manipulation attack on the agent. |
| Recommendation — Separate untrusted retrieval from executable instructions and block tool calls influenced by hostile text. | ||
| CSA MAESTRO | GOV — Governance | The issue is governed agent autonomy and trust boundaries across tools and retrieval. |
| Recommendation — Define approval gates for agent actions that can change data or invoke restricted systems. | ||
| NIST AI RMF | GOVERN — Govern, Map, Measure, Manage | AI risk governance should classify retrieval-driven agent actions as a managed trust risk. |
| Recommendation — Map retrieval exposure to AI risk controls and measure whether agents act on untrusted content. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | Agent misuse becomes harmful when the toolchain permits sensitive authenticated actions. |
| Recommendation — Restrict agent permissions so retrieved content cannot drive privileged access by default. | ||
| MITRE ATT&CK | T1204 — User Execution | The adversary relies on content causing the victim system to execute unwanted instructions. |
| Recommendation — Model poisoned retrieval as execution via trusted content and hunt for resulting tool abuse. | ||
Practitioner Guidance
What to prioritise: Treat retrieval sources as untrusted inputs whenever the agent can act on them. The highest-value control is not better parsing alone, but whether a retrieved item is allowed to influence a privileged action without a separate trust decision.
Decision rule: If the agent can read the content and also take external action, require a policy check or human confirmation before any action that changes data, sends data, or invokes a restricted API. If the action is low impact, preserve autonomy; if it is irreversible or sensitive, force an approval boundary.
What to verify: Verify that logs can show which retrieval item influenced the agent’s decision, which tool was called, and whether the action was pre-authorised. Without that chain, incident review will not be able to distinguish malicious content from normal agent behaviour.
Common mistake: Teams often harden the prompt but leave the retrieval path and tool permissions unchanged. That reduces obvious failures while leaving the real abuse path intact.
Practitioner takeaway: The safe design goal is not “an agent that never sees malicious text”; it is an agent that cannot turn malicious text into high-impact action without an explicit control point.
Related resources from NHI Mgmt Group
- Who is accountable when an AI agent processes malicious instructions embedded in a calendar invite or advertisement?
- How should organisations limit damage if an AI agent is exposed to malicious content?
- Who is accountable when an AI agent changes prices or processes a refund incorrectly?
- What breaks when malicious instructions are embedded in a Claude Code project file?