Tool Misuse

The runtime use of an AI agent's tools in unintended, unsafe, or attacker-directed ways — through over-privilege, descriptor ambiguity, or unsafe composition. The class OWASP ASI02 covers.

Tool Misuse in the agentic AI security context is the runtime use of an AI agent's tools in unintended, unsafe, or attacker-directed ways. It is the threat class that OWASP ASI02 covers and the runtime-side counterpart to ASI04's supply-chain framing. Where ASI04 asks whether a loaded tool was shipped by a trustworthy source, ASI02 asks whether an honestly-shipped tool is being used safely by the agent at runtime.

Tool misuse fires under three principal conditions. Over-privileged tools carry more authority than the task requires, multiplying the blast radius of any successful prompt-injection attempt. Ambiguous or poisoned tool descriptors influence the agent toward wrong or attacker-chosen tool selection. Unsafe tool composition chains multiple individually-safe tools into combined actions no single tool was authorised to perform — the classic Git read + Browser fetch private-repo exfiltration is the worked example.

Why Tool Misuse Is a Distinct Class

Treating tool misuse as a runtime concern separate from supply-chain provenance is important because the defensive controls are different. Supply-chain hygiene (pinning, signing, registry trust) cannot block runtime composition attacks; runtime controls (scoping, descriptor sanitisation, composition policy) cannot block trojanised connectors at install time. A complete defence needs both layers, and an audit that conflates them tends to under-test one or the other.

The empirical record bears this out. CVE-2025-54136 ("MCPoison") is widely cited as a tool poisoning attack — accurate from the supply-chain side. But the runtime control that would have caught it independently of how the malicious server arrived is descriptor logging plus diff against previous load, which is an ASI02 control, not an ASI04 one. The Asana cross-tenant bypass of June 2025 has no supply-chain story at all — it is a pure ASI02 over-privileged-tool case.

Defensive Posture

Defending against tool misuse requires four operational controls: least-privilege tool scoping (each tool holds only what the task needs); descriptor sanitisation (descriptors are treated as untrusted input before reaching the LLM context); cross-tool composition policy (the host explicitly models which combinations are allowed); and invocation logging plus anomaly diff (every tool call is recorded, descriptor mutations are detected). The OWASP ASI02 explainer covers each in operational detail.

For the broader live record of tool-misuse-class incidents, see the MCP Breach Index 2025–2026, which catalogues the 2025–2026 disclosed CVEs and supply-chain breaches that fit the pattern.

Need expert guidance on Tool Misuse?

Our team at Zealynx has deep expertise in blockchain security and DeFi protocols. Whether you need an audit or consultation, we're here to help.

Get a Quote