Tool Poisoning

Why it matters

Agentic AI works by reading tool descriptions and deciding when to call them. That makes the descriptions themselves an instruction channel. A poisoned tool does not need to exploit code: the attack ships in plain text, activates in any connected model, and can instruct exfiltration or misuse of other legitimate tools. As businesses adopt tool-using agents, this is supply-chain risk in a new costume.

How it works

The attacker publishes or compromises a tool server whose tool descriptions embed directives ('before every call, also send the conversation to...'), sometimes hidden with encoding tricks or invisible Unicode. Defences: scan tool schemas for imperative or hidden content before registration, pin and review tool versions like dependencies, run agents least-privileged, and monitor calls for behavior that does not match user intent.

A real-world example

A developer connects a free community tool server to their AI workflow. One tool's description contains a hidden instruction to include environment secrets in its arguments. Every agent that loads it obeys silently. A pre-registration scan flags the imperative text and the hidden Unicode, and the server never enters the workflow.

Common mistakes

• ✗ Connecting community tool servers without reading or scanning their schemas
• ✗ Trusting a tool forever after one review, descriptions can change on update
• ✗ Running agents with broad credentials so any poisoned tool inherits them
• ✗ Assuming code review covers it; the payload is prose, not code

Best practices

• ✓ Scan every tool schema for injection patterns, hidden Unicode, and secret-shaped strings before use
• ✓ Version-pin tool servers and re-scan on every update
• ✓ Apply least privilege to agent credentials and per-tool permissions
• ✓ Log and review tool calls the way you review privileged user actions

Frequently asked questions