Tool poisoning: when an agent's tools turn against it
How tampered tool descriptions and crafted tool outputs steer autonomous agents into harmful actions — and the validation, isolation and provenance controls that stop it.
Definition
Tool poisoning is an attack that compromises the tools an AI agent relies on — or the outputs they return — so the agent makes harmful decisions. It includes tampered tool descriptions, malicious or hijacked APIs, and crafted responses designed to steer the agent toward unsafe actions.
An agent trusts its tools by design — that is the point of giving it tools. Tool poisoning weaponizes that trust. Instead of attacking what the agent reads, the attacker attacks what the agent uses.
Two surfaces: descriptions and outputs
Tool poisoning has two entry points.
Tool descriptions. An agent often chooses which tool to call based on a description. If that description is attacker-controlled or tampered with — a common risk with third-party MCP servers — the attacker can mislead tool selection or hide instructions in metadata the agent reads while planning.
Tool outputs. Whatever a tool returns becomes context the agent acts on. A compromised API, or a legitimate one returning attacker-influenced data, can deliver an injection through a channel the agent is built to trust.
The two surfaces and their controls, side by side:
| Attack surface | How it is abused | Common source | Primary control |
|---|---|---|---|
| Tool description | Misleads tool selection or hides instructions in metadata | Third-party MCP servers, tool registries | Pin, version and sign definitions; review changes |
| Tool output | Returns crafted data that acts as an injection | Compromised or attacker-influenced APIs | Validate and type-check; treat as untrusted data |
Why is tool poisoning dangerous?
The whole architecture assumes tools are reliable. Defenses tuned for user input do not watch the tool layer, so a poisoned output often arrives unscreened — and because the agent trusts it, it flows straight toward action. Combined with excessive agency, a single poisoned response can trigger an irreversible operation.
Defenses that work
- Treat tool outputs as untrusted data, never as instructions. Validate, type-check and constrain what comes back.
- Pin and review tool descriptions. Do not let third-party servers silently change what a tool claims to do; version and sign definitions where possible.
- Isolate execution. Run tools in sandboxes so a malicious tool cannot reach beyond its scope.
- Least privilege. A poisoned summarization tool must not be able to pay or delete — scope every tool tightly.
- Monitor traces. Watch for outputs that suddenly contain imperative language or trigger unusual follow-on calls; observability is your detection.
The principle
Trust in tools should be bounded, not assumed. Give each tool the least access it needs, verify what it returns, and keep a human in the loop for anything irreversible — the same defense-in-depth that the OWASP Top 10 for Agentic Applications prescribes. Terms are in the glossary.
Frequently asked questions
How is tool poisoning different from prompt injection?
Prompt injection plants instructions in content the agent reads, like a web page or a document; tool poisoning attacks the tool layer itself — either the description that tells the agent what a tool does, or the output the tool returns. The distinction matters because the two arrive through different channels and need different defenses. An injection rides in data the agent fetched; tool poisoning rides in a channel the agent is built to trust, which is exactly what makes it effective. A poisoned tool output is, in effect, an injection delivered through the back door: defenses tuned to screen user input never look at what an API returns. In practice the attacks overlap and chain — a poisoned tool can carry an injection, and an injection can point the agent at a malicious tool — so you should treat both tool descriptions and tool outputs as untrusted, not just the user's prompt.
What is a poisoned tool description?
Agents decide which tool to call partly from its description — the natural-language metadata that says what the tool does and when to use it. A poisoned description is one an attacker controls or has tampered with, and it works in two ways. It can mislead tool selection, nudging the agent to call the wrong tool or to use a dangerous one for a benign task. Or it can smuggle instructions into the metadata itself, so that simply reading the catalogue of available tools injects commands into the agent's planning. This is a particular risk with third-party MCP servers, where tool definitions come from outside your trust boundary and can change silently between calls. The defense is to pin tool definitions to known versions, review changes before adopting them, and sign definitions where the platform allows it, so a description cannot mutate underneath you.
How do I defend against it?
Treat everything the tool layer produces as untrusted, the same way you treat content fetched from the open web. Validate and type-check tool outputs, and constrain them to expected shapes rather than feeding raw responses straight back into the agent's context. Pin and review tool descriptions so a third-party server cannot silently change what a tool claims to do, and version or sign definitions where you can. Isolate tool execution in sandboxes so a malicious tool cannot reach beyond its scope. Apply least privilege so that even a fully poisoned tool cannot trigger a high-impact action — a summariser must not be able to pay or delete. Finally, monitor traces for outputs that suddenly contain imperative language or trigger unusual follow-on calls. No single control is sufficient; the point is layered containment so one poisoned tool cannot reach anything irreversible.
Are third-party MCP tools safe to use?
They are usable, but not safe by default — treat any external MCP server as untrusted infrastructure, not a trusted extension of your agent. The risk is that both the tool descriptions and the tool outputs come from outside your control, so a server can present a benign description, pass your review, then later return crafted data or change its definition between calls. That does not mean avoid them; the ecosystem is too useful. It means wrapping them in the controls you would apply to any untrusted dependency: pin specific versions, review the scopes each tool requests, run it with least privilege, and validate its outputs. For anything irreversible, keep a human approval step between the tool and the action. The convenience of a third-party tool is never worth giving it unscoped access to production.