Tool Poisoning

Definition

Tool poisoning manipulates a tool-facing surface, such as its description, schema, or response, to induce unintended agent behavior. The relevant trust boundary is between information about a capability and authority to use that or another capability.

Tools are part of the agent’s decision environment. A capability description can influence selection, while a result can influence the next step. Neither surface should be able to create permission that the surrounding application has not granted.

What it covers

Discovery metadata

Inspect descriptions, schemas, routing, and changes to capabilities.

Returned content

Treat external responses as data with a defined trust level.

Privilege separation

Keep untrusted tool content from granting access to privileged tools.

Change review

Revisit approved integrations when the server or exposed tools change.

Separate a deceptive interface from a compromised implementation. Both deserve investigation, but reviewing metadata alone cannot establish that the underlying tool is safe. Identify the operator, deployment, exposed operations, and relevant version.

In practice

Practical design patterns by Min.

• Keep an inventory of approved servers and exposed capabilities.
• Validate structured responses while recognizing that valid structure does not prove safe content.
• Enforce resource permissions independently of tool prose.
• Evaluate metadata changes and response-driven tool pivots in a controlled environment.

Review newly introduced privileges and test whether a low-trust result can trigger a high-impact action. The test should inspect the actual service outcome, not merely whether the assistant’s visible explanation sounds cautious.

Working example

Why the controls matter

The status report may be legitimate data while its embedded instruction is not authorized. The export service independently checks access, scope, destination, and approval before any external transfer can occur.

Common pitfalls

• Approving a server once and trusting all later tool changes.
• Assuming a JSON response cannot contain malicious instructions.
• Relying on the model alone to enforce privileged-tool restrictions.

Output filtering can reduce some exposure but is not a complete security boundary. A receiving tool must enforce its own permissions even if an upstream model or parser misses the manipulation.

Questions for operational review

Use these questions to decide what evidence your team needs. They are editorial prompts, not a compliance checklist.

• Who controls tool metadata and updates?
• Can a response activate an unrelated privileged tool?
• Which service blocks an unapproved action?