OWASP ASI02 Explained: AI Agent Tool Misuse Attacks

TL;DR

OWASP ASI02 ("Tool Misuse and Exploitation") is item 2 of the OWASP Top 10 for Agentic Applications 2026. It covers attacks where an AI agent uses its tools in unintended, unsafe, or attacker-directed ways.
ASI02 fires under three conditions: tools have more privilege than the task requires, tool descriptors carry ambiguous or poisoned instructions, or multiple tools chain together to produce an outcome no individual tool was authorised to deliver.
Real-world ASI02 incidents include the WhatsApp tool poisoning attack (April 2025, Invariant Labs), CVE-2025-54136 "MCPoison" against Cursor IDE, and the June 2025 Asana MCP cross-tenant access bypass.
Defending against ASI02 is a runtime-control problem, distinct from the supply-chain framing of ASI04. The two overlap on poisoned-descriptor cases but require different mitigation layers.
The four operational controls that close most ASI02 exposure: least-privilege tool scoping, descriptor sanitisation, cross-tool composition policies, and tool-invocation logging with anomaly diff.

What ASI02 actually says

OWASP ASI02 is the runtime cousin of ASI04. Where ASI04 asks "is the tool you loaded trustworthy?", ASI02 asks "is the agent using its tools safely?" — even assuming the tools themselves are honest. The difference matters because tools that look harmless individually can be combined, abused, or driven beyond their intended scope by an adversary who manipulates the agent's reasoning.

The standard names three principal failure modes within the category:

Over-privileged tools. A tool that can read any file, write any file, or call any API hands the agent — and therefore any successful prompt-injection attempt — the maximum possible blast radius. ASI02 treats over-privilege as a structural failure regardless of whether the tool is "safe" in isolation.

Ambiguous or poisoned tool descriptors. A tool descriptor is read into the LLM's context as part of tool selection. Ambiguity in the description can cause the agent to pick the wrong tool for a sensitive operation; adversarial content embedded in the description can directly steer the agent toward attacker-chosen actions.

Tool composition attacks. Multiple tools, each safe in isolation, chained together can produce an outcome no single tool would have authorised. The classic example: a Git MCP server that can read repo content plus a Browser MCP server that can fetch arbitrary URLs lets an attacker exfiltrate private repos through a one-step chain.

How ASI02 differs from ASI04

ASI02 and ASI04 are frequently confused because they overlap on poisoned-descriptor cases. The cleanest way to separate them:

ASI04 is about provenance. The tool was shipped by an attacker (or an attacker-compromised channel). Defence is supply-chain hygiene: signing, pinning, registry trust.
ASI02 is about runtime use. Even an honestly-shipped tool can be misused by the agent if it is over-privileged, if its descriptor is ambiguous, or if it is composed with other tools to produce unauthorised outcomes. Defence is runtime control: scoping, sanitisation, composition policy.

A poisoned tool descriptor is an ASI04 finding when the focus is on how the descriptor got there (compromised npm package, malicious server). It is an ASI02 finding when the focus is on why the agent's runtime did not catch the manipulated descriptor before it influenced behaviour. In a Zealynx audit, both are typically reported because both layers need to hold.

Real-world ASI02 incidents

The disclosed-incident record from 2025–2026 contains multiple ASI02-shaped findings, drawn from the MCP Breach Index 2025–2026:

WhatsApp Tool Poisoning (April 2025)

Invariant Labs' April 2025 disclosure introduced tool poisoning attacks as a class. A malicious peer MCP server's descriptor included instructions that caused the agent to silently exfiltrate WhatsApp chat history through what looked like a normal tool call. This is the ASI02 root case: the agent had no guardrail between an externally-supplied descriptor and its tool-selection logic.

MCPoison — CVE-2025-54136 (Cursor IDE)

A Cursor IDE vulnerability (CVSS 8.8) where an attacker controlling an MCP server wrote unsanitised directives into tool descriptors that Cursor processed. The runtime accepted descriptor mutation post-install without diffing against the previous load — a textbook ASI02 control failure. Detection here would have caught the attack regardless of how the malicious server got installed.

Asana MCP cross-tenant access bypass (June 2025)

The Asana MCP server's tools were over-privileged: a single connection could read across tenant boundaries that should have been isolated at the tool level. This is the least-privilege tool scoping failure. The fix was scope-narrowing on the server side, but the agent runtime should also have enforced its own per-tenant scoping rather than trusting the connector's authority.

Cross-tool chaining patterns

Not a single CVE but a recurring pattern documented across multiple Endor Labs and Equixly analyses: combinations of MCP servers connected to the same agent context produce compound capabilities. Git read + Filesystem write = arbitrary file injection into a repo. Browser fetch + Mail send = exfiltration through SMTP. Most production deployments do not audit MCP servers as a set; they audit them individually. ASI02 explicitly names this as in-scope.

Why agentic systems amplify ASI02 risk

Three properties make AI agents structurally more susceptible to tool misuse than classical applications.

The tool-selection step is non-deterministic. A traditional program calls a specific function based on deterministic logic. An agent picks tools by reading the tool catalog into the LLM's context and reasoning over it. Adversarial content in the catalog has weighted influence over this choice without needing a deterministic exploit.

Tool authority is delegated, not requested. The agent does not ask the user for permission before each tool invocation. It uses whatever authority the host granted at connection time. If a tool is over-privileged at the host level, every invocation inherits the over-privilege.

Composition is implicit. The agent can chain tools across multiple servers as part of a single planning step, with no explicit composition policy enforced by the host. Unless the host explicitly disallows it, "use Git to read repo, use Browser to fetch attacker URL with the contents" is a single agent decision rather than two.

Detection and mitigation

The four operational controls below close most ASI02 exposure documented in the 2025–2026 incident record:

1. Least-privilege tool scoping

Each tool the agent can call should hold only the authority the immediate task needs. For an MCP server providing file system access, this means scoping the allowed paths to a specific working directory rather than the user's whole home directory. For network tools, it means scoping the allowed domains. For credential-bearing tools, it means scoping the allowed actions per credential. The Asana cross-tenant case would have been impossible if per-tenant scoping had been enforced at the tool layer.

2. Tool-descriptor sanitisation

Tool descriptors should be treated as untrusted text before they enter the LLM's context. Strip known prompt-injection patterns. Enforce length limits. Quarantine tokens that look like instructions. Prefer the structurally validated parameter schema over the raw natural-language description for the agent's reasoning step. The MCPoison and WhatsApp cases would both have been blocked or significantly degraded by basic descriptor sanitisation.

3. Cross-tool composition policy

The host should explicitly model which tool combinations are allowed in a single agent step. Read tools and write tools across trust boundaries should require explicit user confirmation, not implicit chaining. Tools that touch external networks should not auto-compose with tools that read sensitive local content. The classic Git+Browser exfiltration chain would be blocked by a composition policy that flags any "internal-read → external-write" combination as a confirmation prompt.

4. Tool-invocation logging and anomaly diff

Every tool invocation — descriptor read, schema, parameters, return — should be logged in a way that supports diffing across runs. Sudden mutations in tool behaviour (a previously-benign tool returning crafted output, a descriptor changing post-install) are some of the few mechanical signals that catch a successful ASI02 attack in progress. The MCPoison-class descriptor mutation is invisible without this layer; it is trivial to detect with it.

For Web3 deployments specifically, an additional rule applies: tools that can sign transactions or access wallet credentials must be in a process boundary distinct from any tool that touches arbitrary external content. Composition between the two should be impossible at the host level, not policy-bound.

Are you audit-ready?

Download the free Pre-Audit Readiness Checklist used by 30+ protocols preparing for their first audit.

No spam. Unsubscribe anytime.

How Zealynx audits for ASI02

A Zealynx MCP Security Audit treats ASI02 as a runtime-controls audit, distinct from the supply-chain enumeration done for ASI04. The five focused tests:

Tool privilege survey. For each connected tool, what authority does it actually hold against the host's environment? What does the agent's task actually need? Findings flagged where authority exceeds need.
Descriptor adversarial test. Crafted descriptors mimicking the tool poisoning, MCPoison-style mutation, and ambiguity patterns are submitted into the agent's tool catalog. The runtime's defensive layer must filter or reject them.
Cross-tool composition map. Every pair (and small set) of connected tools is checked for composition-attack potential. Findings flagged where a composition can produce an outcome neither tool individually authorised.
Invocation logging completeness. Every tool invocation should be logged with descriptor content, parameters, and return value. Where logging is missing or incomplete, post-incident analysis is impossible.
Privilege-boundary trust test. For tools that touch credentials, signing authority, or external systems, the audit verifies that no other connected tool can compose with them in ways that leak that authority.

The deliverable maps each finding to ASI02 (and ASI04 where the supply-chain origin is also relevant), with prioritised remediation guidance.

FAQ

1. What is OWASP ASI02 in one sentence?

OWASP ASI02 (Tool Misuse and Exploitation) is item 2 of the OWASP Top 10 for Agentic Applications, covering attacks where an AI agent uses its tools in unintended, unsafe, or attacker-directed ways — through over-privileged tools, ambiguous or poisoned tool descriptors, or unsafe tool composition across multiple connected servers.

2. How is ASI02 different from ASI04?

ASI02 and ASI04 are different layers of the same problem space. ASI04 is about provenance: was the tool you loaded shipped by a trustworthy source? ASI02 is about runtime use: even an honestly-shipped tool can be misused if it has more privilege than needed, if its descriptor is ambiguous or poisoned, or if it is composed with other tools to produce unauthorised outcomes. A poisoned tool descriptor is typically reported as both an ASI02 and ASI04 finding because both layers should have caught it.

3. What are the most common ASI02 attack patterns?

The three most common ASI02 attack patterns are: tool poisoning (adversarial content embedded in tool descriptors that hijacks agent behaviour, as in CVE-2025-54136 "MCPoison"); over-privileged tools (where the tool holds more authority than the task requires, as in the June 2025 Asana cross-tenant bypass); and cross-tool composition attacks (where multiple safe-looking tools chain to produce an unauthorised outcome, such as Git read + Browser fetch enabling private-repo exfiltration).

4. What real-world CVEs are tied to ASI02?

ASI02 maps to several disclosed CVEs in the MCP Breach Index 2025–2026, including CVE-2025-54136 ("MCPoison" against Cursor IDE, CVSS 8.8) where attackers controlling an MCP server wrote unsanitised directives into tool descriptors, and the broader Invariant Labs WhatsApp tool-poisoning class disclosed in April 2025. The Asana MCP cross-tenant access bypass (June 2025, no public CVE) is the canonical least-privilege failure case.

5. How do I detect a tool-poisoning attack against my agent?

To detect a tool-poisoning attack, log the full content of every tool descriptor at the moment it enters the LLM context, and diff against the previous load. A descriptor that mutates post-install — especially in ways that introduce instruction-shaped content ("ignore previous", "also send to", "do this before") — is the strongest mechanical signal of an active poisoning attempt. Without this logging, the attack is essentially invisible during execution.

6. How do I prevent cross-tool composition attacks?

To prevent cross-tool composition attacks, model the allowed combinations of tools explicitly at the host level rather than relying on per-tool security. Tools that read sensitive content should not auto-compose with tools that touch external networks. Cross-trust-boundary chains (read internal + write external) should require explicit user confirmation. Web3-specific rule: tools holding wallet credentials or signing authority must run in process boundaries distinct from tools that consume arbitrary external content.

7. What does "least-privilege tool scoping" mean for MCP?

Least-privilege tool scoping means each MCP tool should hold only the authority the immediate task requires. For a filesystem tool, scope to a specific working directory. For a network tool, scope to specific domains. For credential-bearing tools, scope per credential to specific actions. The host should enforce these scopes regardless of what authority the connector itself claims, since scope enforcement at only the connector layer fails when the connector is compromised.

8. How does Zealynx audit for ASI02?

Zealynx's MCP Security Audit tests for ASI02 across five dimensions: tool privilege survey (does each tool hold only what it needs?), descriptor adversarial test (does the runtime reject crafted poisoning patterns?), cross-tool composition map (which combinations produce unauthorised outcomes?), invocation logging completeness (can incidents be reconstructed?), and privilege-boundary trust test (is high-authority tooling isolated from arbitrary external content?). Findings are mapped to the standard with prioritised remediation guidance.

Glossary

Term	Definition
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.
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.
Least-Privilege Tool Scoping	The defensive pattern of granting each AI agent tool only the authority required for the immediate task — narrowed by path, domain, credential, and action — rather than the maximum authority the underlying connector can theoretically provide.

View complete glossary →

Are you audit-ready?

Download the free Pre-Audit Readiness Checklist used by 30+ protocols preparing for their first audit.

No spam. Unsubscribe anytime.