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.
Articles Using This Term
Learn more about Tool Misuse in these articles:
Related Terms
Model Context Protocol (MCP)
Open standard defining how AI agents communicate with external tools, databases, and services through a unified interface for LLM-to-infrastructure interaction.
Tool Descriptor
The metadata an MCP server provides to describe a tool — its name, description, parameter schema, and usage notes — that an AI agent reads when deciding which tool to call.
Tool Poisoning Attack
An attack where malicious instructions hidden inside an MCP tool's description, schema, or output hijack the AI agent's behaviour without the user's awareness.
AI Agent
Autonomous software system powered by a large language model that can perceive, reason, and execute actions — including signing blockchain transactions — without continuous human oversight.
Cross-Tool Chaining
An attack pattern where multiple AI agent tools, each safe in isolation, are combined in a single planning step to produce an outcome no individual tool was authorised to deliver.
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