What is Tool Poisoning?
Tool Poisoning is an AI-agent attack in which malicious or compromised tool metadata, schemas, implementations, updates, or returned content influence the agent to select unsafe actions or misuse its authority.
Quick Facts
| Created | Recognized as a distinct agent and tool supply-chain risk in the mid-2020s |
|---|---|
| Specification | Official Specification |
How It Works
Tool poisoning targets the trust boundary between an agent and its executable capabilities. An attacker may alter a tool description to hide instructions, publish a malicious package or MCP server, change behavior after approval, return prompt-injection content, or create a confusing tool that shadows a trusted one. The model cannot provide the security boundary: the host must verify tool provenance and versions, maintain an allowlisted registry, derive identity from trusted context, validate arguments and results, restrict network and file access, require confirmation for consequential effects, and monitor the exact tool version used by each run. See the <a href="https://qubittool.com/blog/ai-agent-tool-security-guide">AI agent tool security guide</a> for the threat and control matrix.
Key Characteristics
- Can enter through metadata, schemas, code, dependencies, updates, or tool results
- Exploits an agent's tendency to treat tool descriptions and output as operational context
- May remain inside granted permissions while steering them toward an unintended goal
- Can propagate through registries, MCP servers, skills, plugins, or delegated agents
- Requires supply-chain controls and runtime authorization rather than prompt-only defenses
Common Use Cases
- Threat modeling MCP servers, plugins, skills, and dynamic tool registries
- Reviewing tool provenance, signatures, versions, and dependency locks
- Testing agents against malicious descriptions and returned instructions
- Designing approval gates for destructive or external side effects
- Monitoring tool drift and post-installation behavior changes
Example
Loading code...Frequently Asked Questions
How is tool poisoning different from prompt injection?
Prompt injection is the broader manipulation of model behavior through untrusted content. Tool poisoning specifically compromises the tool boundary, including descriptions, schemas, code, updates, dependencies, or results.
Can a read-only tool be poisoned?
Yes. A read-only tool can return hostile instructions, private data from the wrong tenant, misleading evidence, or oversized content that affects later actions.
Does schema validation stop tool poisoning?
No. It checks shape, not provenance, authorization, destination safety, implementation integrity, or semantic truth. Those controls must be enforced separately.
What is the strongest defense against tool poisoning?
Use a verified and version-pinned registry, least privilege, sandboxing, argument and result validation, destination allowlists, explicit approval for high-impact actions, and tamper-evident audit logs.
How should tool updates be handled?
Treat material metadata, schema, dependency, or permission changes as a new reviewed version. Re-run security tests and do not silently inherit broader capabilities.