Tool result injection is a prompt injection technique where malicious content is embedded in data returned by a tool, API, or external system. An AI agent that consumes the result may treat that content as instructions, which can alter tool use, data handling, or later prompts unless the output is strictly treated as untrusted data.
How tool result injection works
Tool result injection happens when malicious instructions are hidden inside the output of a tool, API, search result, file parser, or other external system. The agent receives the response as if it were ordinary data, but the embedded content is crafted to influence the model’s next decision.
The core danger is that the tool boundary is not the same as the trust boundary. A system can safely call a tool and still be vulnerable if it later lets the returned text affect prompts, planning, or tool selection without strong data-instruction separation.
Why tool outputs become a control boundary
Any agent that reads tool output is effectively handling untrusted input, even when the tool itself is legitimate. That matters because the result may contain attacker-controlled text, markup, code fragments, or “helpful” directions that are meant to be interpreted rather than displayed or stored.
This pattern often appears in retrieval, browser, ticketing, monitoring, support, and integration workflows, where the agent chains external results into later reasoning. If the system preserves too much authority across those steps, the injected content can redirect the agent away from the user’s real request.
What makes the technique dangerous
Tool result injection is dangerous because it can trigger second-order prompt injection: the malicious content is not in the original user prompt, so it may bypass initial filters and arrive through a trusted integration path. That can lead to tool misuse, data leakage, or unauthorized actions if the agent follows the injected instruction.
The impact is often wider than a single bad answer. An injected tool result can influence follow-on prompts, cause the agent to request sensitive resources, or steer it toward exfiltration paths that look like normal workflow output.
How to recognise and contain it
Defensive handling starts with treating every tool response as data only, not as instructions. That means the agent should separate retrieved content from system and task instructions, constrain what the model can execute from tool output, and avoid letting free-form text directly shape high-trust decisions.
Teams should also review the tool ecosystem around the agent, not just the model prompt. The more the workflow accepts rich text, external citations, code, HTML, or multi-step tool chaining, the more important it becomes to validate, sanitize, and scope what the agent is allowed to act on.
Practical examples of exposure
Search results, issue trackers, support replies, log viewers, and document summaries can all carry injected instructions if they ingest attacker-controlled content. The risk rises when the agent can call follow-on tools, access secrets, or act with the user’s permissions after reading that output.
Prompt Injection Guide covers the broader attack family, including indirect prompt injection and layered defences, while Sentry MCP Agentjacking 2026 shows how malicious tool output can become a real compromise path for AI coding agents.
Risk and Threat Considerations
Tool result injection can turn ordinary integrations into an attack path because the malicious payload arrives through a channel that developers often assume is already trusted. The main exposure is not just bad text, but the possibility that the agent will treat that text as a higher-priority instruction and act on it.
Failure mechanism: The agent fails to keep tool output at a lower trust level than user or system instructions, so embedded directives can alter planning, tool calls, or data handling.
Impact: The compromise can produce wrong actions, sensitive data exposure, credential misuse, or deeper abuse of downstream tools and connected systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK, OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1204 — User Execution | Tool result injection relies on malicious content being acted on through a trusted workflow. |
| Recommendation — Map injected tool content to T1204 and inspect downstream action paths for unintended execution. | ||
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | The term describes agent behaviour being steered into unsafe tool use by injected output. |
| ASI09 — Human-Agent Trust Exploitation | Injected output abuses the agent’s trust in external content and workflow context. | |
| Recommendation — Constrain tool invocation logic so untrusted results cannot select or chain tools. Separate trusted instructions from external content so the agent cannot elevate untrusted text. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | APIs and integrations become vulnerable when output handling and trust boundaries are configured unsafely. |
| Recommendation — Harden integration handling so API responses are validated before any agent consumes them. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | The issue is fundamentally about validating untrusted input before it influences processing. |
| Recommendation — Validate tool output before it can influence prompts, actions, or downstream processing. | ||
Practitioner Guidance
Why practitioners should care: Tool result injection is a design issue, not just a prompt-tuning issue. If an agent can read arbitrary external content and then act on it, the architecture must explicitly constrain how that content is interpreted and what authority the agent retains after reading it.
What to watch for: Be especially alert when tool output can be rich text, when the agent can recurse into more tools, or when retrieved content is allowed to influence later prompts without strict delimiting. Those are the conditions where injected instructions are most likely to survive into execution.
Related resources from NHI Mgmt Group
- What is the difference between prompt-based defenses and tool result parsing for indirect prompt injection?
- What is the difference between prompt injection and tool poisoning?
- What is the difference between prompt injection and MCP tool injection?
- How can organisations reduce risk from prompt injection and tool misuse?