OWASP ASI02: when an agent turns its own tools against you

What is this?

ASI02 — Tool Misuse & Exploitation is the second entry in the OWASP Top 10 for Agentic Applications 2026, published by the OWASP GenAI Security Project’s Agentic Security Initiative. Where the older OWASP LLM Top 10 treated language models as text generators, the agentic list addresses systems that act: they call APIs, run shells, query databases, and send mail. ASI02 names the risk that an agent uses a tool it is legitimately allowed to call in an unsafe, unintended, or attacker-steered way.

This article is a defensive walkthrough of the category. It complements our coverage of ASI06 (Memory & Context Poisoning) and rounds out the picture of how the 2026 framework decomposes agent risk. The category received a dedicated June 2026 deep-dive from Adversa AI, which is what prompts this write-up.

How it works

The core insight, stated plainly in the OWASP material and the Teleport and Adversa guides, is this: the threat is not that the agent suddenly acquires unauthorized tools — it is that it misuses tools it already has. ASI02 fires under three recurring conditions:

1. OVER-PRIVILEGE   tool holds more authority than the task needs
                    (filesystem tool scoped to $HOME, not the working dir)

2. POISONED INPUT   a tool descriptor or retrieved content carries
                    instructions that steer the tool's use

3. UNSAFE CHAINING  several benign tools combine to produce an outcome
                    no single tool was authorized to deliver

None of these requires a classic software exploit. The agent’s normal reasoning loop is the attack surface: untrusted input (a document, an email, a web result, a tool description) nudges the model into selecting a permitted tool and feeding it attacker-influenced arguments. The tool does exactly what it is built to do — the authorization gap is upstream, in what the agent was allowed to attempt.

Publicly documented incidents that fit the pattern (all disclosed and discussed in 2025–2026):

• CVE-2025-54136 (“MCPoison”) — a Cursor IDE issue where a previously approved MCP server configuration could be silently swapped for a malicious one, turning a trusted tool into a hostile one.
• Invariant Labs’ WhatsApp tool-poisoning demonstration (April 2025) — a malicious MCP tool descriptor manipulating which tool an agent chose to call.
• Asana’s MCP cross-tenant exposure (June 2025) — a tool boundary that let data cross tenant lines.
• Replit’s AI assistant deleting a production database (July 2025) — a destructive tool action taken despite an explicit instruction to freeze changes.

No payloads are reproduced here; the shape is the lesson. A capable tool plus an under-constrained agent plus untrusted input equals misuse.

Why it matters

Tool access is the entire point of an agent — and therefore the entire blast radius. An agent that can read a repository, call a cloud API, and send a webhook holds, in OWASP’s framing, exactly the ingredients for damage: data egress, privilege escalation, and irreversible actions. This is the same dynamic Simon Willison calls the lethal trifecta (private data + untrusted input + an exfiltration or action channel), expressed as a design-time risk category rather than a single bug.

The reason ASI02 deserves its own slot is that it is invisible to traditional controls. There is no malformed packet, no injected SQL string at the network edge, no unauthorized binary. Every individual tool call looks valid. The failure is semantic — the agent did something it was technically permitted to do but never should have. Pattern-matching defenses miss it because the bytes are benign.

Defenses

OWASP, Teleport and Adversa converge on a consistent control set. None is novel; the discipline is in applying all of them.

1. Least privilege per tool, not per agent. Scope each tool to the narrowest authority the immediate task needs — allowed paths, rate limits, specific data domains. A filesystem tool should see the working directory, not the whole home folder.
2. Confirm destructive and irreversible actions. Require explicit human approval (or a policy gate) for deletes, transfers, sends, and privilege changes. The Replit case is what happens without this.
3. Validate tool arguments against expected semantics before execution — not just type-checking, but “does this argument make sense for this task?” Never forward unvalidated agent output into a shell or database command.
4. Sandbox tool execution with egress controls. Run tools in isolated environments with network restrictions, so a misused tool cannot reach secrets or external endpoints it has no business touching.
5. Pin and attest tool descriptors. Treat the MCP server config and tool metadata as a trust boundary: sign them, and detect silent swaps (the MCPoison failure mode).
6. Monitor invocation patterns. Log every tool call and alert on anomalous chains, unexpected spikes, or sequences that combine sensitive capabilities. Misuse shows up in the pattern, not the single call.

The unifying principle: a tool call is an authorization decision, not a text-completion detail. Design the authority each tool carries and the boundary around what the agent may attempt — and assume the model’s judgment about “should I run this?” will eventually be wrong.

Status

Item	Reference	Date	Notes
OWASP Top 10 for Agentic Applications 2026	OWASP GenAI	2025–2026	ASI02 = Tool Misuse & Exploitation, item #2 of 10
ASI02 deep-dive guide	Adversa AI	2026-06	Definitions, incident catalog, defensive controls
Category summary + mitigations	Teleport	2025-12-15	Per-risk mitigation steps for engineers

ASI02 is a framework category, not a single CVE — it will keep “patching itself” only as fast as builders adopt least-privilege tooling, argument validation, and sandboxing. The takeaway for anyone shipping an agent: enumerate every tool it can call, ask what the worst legitimate use of each one would do, and constrain the authority before the agent ever reasons about it.