OWASP ASI02 Tool Misuse and Exploitation: Guide

An AI agent can do serious damage without exceeding a single permission, simply by calling the tools it was given in the wrong order, with the wrong arguments or for the wrong reason. OWASP ranks this second in the OWASP Top 10 for Agentic Applications for 2026 as ASI02 Tool Misuse and Exploitation. This guide goes beyond our overview of the full list: it turns the OWASP entry into tool-level requirements, explains how to design per-tool privilege profiles, a pre-execution policy point and tool budgets, and sets out the evidence an assessor should ask for. It is written for engineers who build or expose tools to agents (including MCP servers), IAM teams issuing the credentials those tools use, and the SOC teams who have to tell normal tool use from abuse. For the whole list, see the OWASP Top 10 for Agentic Applications Guide.

Key takeaways

ASI02 is misuse inside the lines. OWASP defines it as an agent using a legitimate tool unsafely while staying within its authorised privileges; escalation beyond those privileges is ASI03 and injected code execution is ASI05.
Privilege belongs to the tool call, not just the agent. OWASP asks for per-tool profiles covering scopes, rate limits and egress allowlists, expressed as IAM or authorisation policy where possible.
Planner output is untrusted input. A policy enforcement point outside the model should check every call's intent, arguments, schema and rate before it runs.
Chains are the threat, not single calls. A database read followed by an external send, or trusted admin tools strung together, can exfiltrate data with no malware for EDR to see.
Credentials decide the blast radius. Just-in-time, session-bound credentials and narrow tokens were exactly what was missing in the PocketOS and Replit production database deletions.

What it is and who it applies to

The OWASP GenAI Security Project published the Top 10 for Agentic Applications on 9 December 2025. ASI02 Tool Misuse and Exploitation covers agents misusing legitimate tools because of prompt injection, misalignment, unsafe delegation or ambiguous instructions, with outcomes such as data exfiltration, manipulated tool output and hijacked workflows. OWASP notes that tool selection, agent memory, dynamic tool discovery and delegation all widen the risk through chaining and unintended actions.

The entry's boundaries help with triage:

ASI02 versus ASI03 Identity and Privilege Abuse: if the agent stays inside its granted permissions, it is ASI02. If it gains rights it was not granted, through delegation, cached credentials or a confused deputy, it is ASI03. See the OWASP Agentic Top 10 ASI03 Guide.
ASI02 versus ASI05 Unexpected Code Execution: a tool used to run attacker-influenced code is ASI05. See the OWASP Agentic Top 10 ASI05 Guide.
ASI02 versus ASI04 Agentic Supply Chain: OWASP notes the overlap for MCP tool definitions. A poisoned tool package or server is a supply chain issue; the agent then calling it harmfully is tool misuse.
ASI02 versus ASI01 Agent Goal Hijack: goal hijack is often the cause, tool misuse the effect. Controls for ASI02 work whether the trigger was an attacker, a model error or an ambiguous user request.

OWASP maps ASI02 to T2 Tool Misuse in its Agentic AI Threats and Mitigations taxonomy, with T4 and T16 as contributing threats, and to the "Agentic AI Tool Misuse" core risk in the OWASP AIVSS scoring system. In MITRE ATLAS the closest techniques are AML.T0053 AI Agent Tool Invocation, AML.T0086 Exfiltration via AI Agent Tool Invocation and AML.T0101 Data Destruction via AI Agent Tool Invocation. ATLAS notes that for exfiltration the invoked tool may itself be legitimate, which is exactly the ASI02 pattern.

Who it applies to: anyone who gives an agent tools: function calling in an application, MCP servers, plugins and connectors in low-code agent platforms, shell and database access in coding agents, and browsing or computer-use capabilities. It applies equally to internally built tools and to third-party ones.

Structure and key requirements

OWASP lists six common examples and seven attack scenarios. The examples are the practical checklist for a tool review:

OWASP example	What it looks like	Primary control
Over-privileged tool access	An email summariser that can also delete or send mail without confirmation	Split read and write tools; confirmation on send and delete
Over-scoped tool access	A CRM tool that can read any record when the agent needs one object type	Resource-level scopes and row-level filters in the tool
Unvalidated input forwarding	Model output passed straight to a shell or database tool	Parameterised operations, schema validation, no free-form command tools
Unsafe browsing or federated calls	A research agent follows malicious links or downloads content	Sandboxed browsing, egress allowlist, download controls
Loop amplification	A planner calls a costly API repeatedly, causing denial of service or bill shock	Rate limits, cost and call budgets, circuit breakers
External data tool poisoning	Third-party content steers the agent into unsafe tool actions	Restrict tool invocation once untrusted data is in context

The scenarios show how misuse happens in practice. OWASP describes tool poisoning, where tool metadata or schemas are altered so the agent relies on false capabilities; an indirect injection in a document that pivots the agent into a local script and sends logs elsewhere; a customer service bot whose order-history API can also issue refunds; chaining an internal-only CRM tool with an external email tool to send out a customer list; tool name impersonation, where a tool called "report" resolves before "report_finance"; chaining trusted admin tools to move logs out so endpoint monitoring sees no malware; and an auto-approved ping tool abused to exfiltrate data through DNS queries.

OWASP's eight prevention guidelines become these requirements (requirement wording is ours):

Least agency and least privilege per tool: each tool has a profile with allowed scopes, resources, rate limits and egress destinations, enforced by the tool or its gateway, not by the prompt.
Action-level authentication and approval: each tool call is authenticated as the calling agent; destructive actions need human confirmation with a dry run or diff of the effect.
Execution sandboxes and egress controls: tool and code execution runs isolated, with outbound traffic limited to approved destinations.
Policy enforcement middleware (OWASP's "Intent Gate"): a pre-execution policy point treats planner output as untrusted and validates intent, arguments, schema and rate before issuing short-lived credentials for the call.
Adaptive tool budgeting: cost, rate and token ceilings per tool and per run, with throttling or revocation when exceeded.
Just-in-time, ephemeral access: credentials issued for the call or session and expiring immediately after.
Semantic and identity validation (OWASP's "Semantic Firewalls"): fully qualified tool names, version pins, validation of what the call is meant to do, and fail closed when tool resolution is ambiguous.
Logging, monitoring and drift detection: immutable logs of every call and parameter change, with alerts on abnormal rates and suspicious chains such as a database read followed by an external transfer.

The MCP specification supports several of these directly. Its tools section says there should always be a human in the loop able to deny tool invocations, that clients must treat tool annotations as untrusted unless they come from trusted servers, that servers must validate inputs, enforce access controls, rate limit invocations and sanitise outputs, and that clients should show tool inputs to the user before calling, validate results, apply timeouts and log tool usage. It also recommends restricting tool names to 1 to 128 characters from a defined character set and keeping them unique within a server, which helps with the name collision problem. See the MCP Security Guide.

Identity and NHI requirements

Every tool call is executed by a credential, and that credential is a non-human identity. ASI02 incidents are usually decided by what the credential could do, not by what the model intended. In the PocketOS deletion, a coding agent found a Railway token in an unrelated file. It had been created to manage custom domains but was account-scoped, so one API call deleted the production database and its volume backups. See the PocketOS breach analysis.

Tools run as the caller, not as a super-user: ATLAS AML.M0028 AI Agent Tools Permissions Configuration recommends least privilege with delegated access, where tools receive the permissions, identity and restrictions of the calling agent. LLM06:2025 Excessive Agency similarly advises executing extensions in the user's context.
No token passthrough: the MCP security best practices state that MCP servers must not accept tokens not explicitly issued for them, because passing tokens through breaks audience separation, audit attribution and downstream controls.
Progressive scopes: start an agent with low-risk read scopes and require step-up for privileged operations, rather than requesting every scope up front. MCP lists wildcard and omnibus scopes as a common mistake. See the AI Agent Authorisation Guide.
Secrets out of the agent's reach: agents read files, so any credential in the workspace is a credential the agent can use. Broker credentials through a vault and inject them per call. See the Credential Vaulting for AI Agents Guide.
Environment separation in the credential, not the instruction: development agents should hold no production-capable credentials. In the Replit incident, an agent told to observe a code freeze still deleted a production database; Replit's response was to separate development and production databases. See the Replit breach analysis.

Implementation steps

Build a tool register. For each tool: owner, agents that can call it, operations (read, write, delete, send, pay, execute), resources reachable, credential used, egress destinations and whether it is internal, third-party or discovered dynamically. Flag tools whose credential is broader than their operations. See the AI Agent Tool and Plugin Security Guide.
Decompose broad tools. Replace "run shell", "execute SQL" and "call any HTTP endpoint" tools with narrow, parameterised operations. A tool that does one thing can be authorised; a tool that does anything cannot.
Write per-tool profiles. Express scopes, resource filters, rate limits and egress allowlists as policy in the tool gateway or authorisation service. Start in log-only mode to record what each agent actually calls for two to four weeks.
Insert the pre-execution policy point. Route every tool call through a gateway that validates the tool's fully qualified name and version, checks arguments against the schema, evaluates the call against the profile and the declared task, and mints a short-lived credential for that call only.
Add confirmation for destructive and external actions. Show the human the literal call and a dry run or diff. ATLAS AML.M0029 Human In-the-Loop for AI Agent Actions describes the same control and notes the trade-off with operational overhead. See the AI Agent Action Approvals and Spending Limits Guide.
Set budgets and circuit breakers. Per-run and per-day ceilings on calls, cost and tokens per tool, with automatic throttling and revocation. See the Denial-of-Wallet and AI Agent Cost Runaway Guide.
Sandbox execution and restrict egress. Run code, browsing and file tools in isolated environments with deny-by-default outbound rules, including DNS. See the AI Agent Sandboxing and Code Execution Guide.
Switch to enforce, agent by agent. Move profiles from log-only to enforce for the highest-impact agents first, with a named owner to approve exceptions.

Testing: before enforcement, replay a sample of real runs against the policy to see what would have been blocked. Add misuse cases to the test suite: a chained read-then-send, a call to a similarly named tool, a loop that exceeds the budget, and a destructive call reached from untrusted content.

Rollback: keep profiles per agent and per tool so that a broken workflow can be moved back to log-only for that tool alone. Soft deletes and independent backups are the rollback for the action itself; after the PocketOS incident Railway made all API deletes soft deletes for 48 hours.

Decision guidance

Choice	Option A	Option B	Guidance
Where to enforce	Inside each tool or MCP server	Central tool or MCP gateway	Small estates can enforce in the tool; at scale a gateway gives one policy, one log and one kill switch
Approval model	Human approval per action	Policy auto-approval with budgets	Human approval for irreversible, external and financial actions; policy approval for reversible, internal, low-value ones
Credential model	Agent identity with standing scopes	Per-call ephemeral credentials	Per-call for write and delete tools; standing narrow read scopes are acceptable for low-risk lookups
Tool discovery	Dynamic discovery from registries	Pinned allowlist	Pin in production; allow discovery only in sandboxed development with no production credentials

Evidence and assessment

Design evidence: the tool register, the per-tool profiles, and a threat model showing which tool chains can move data from internal to external destinations.
Configuration evidence: gateway policy, credential scopes per tool, egress rules including DNS, budget settings, and version pins for each tool and MCP server.
Test evidence: results of misuse test cases (chaining, name collision, loop amplification, destructive call from untrusted input) and replay results from log-only mode. NIST CAISI extended its agent hijacking evaluations with remote code execution, database exfiltration and automated phishing tasks, which are useful templates for tool misuse tests.
Operational evidence: alerts on suspicious chains and budget breaches with triage outcomes, and records of approvals and denials.

Detection and metrics

Log every call with agent identity, tool fully qualified name and version, parameters (with secrets redacted), result size, destination, approval decision and the credential used. Useful detections: a sensitive read followed within the same run by an external send or upload; first-time use of a tool by an agent; call rates far above the agent's baseline; DNS or network tools called with unusually long or high-entropy arguments; destructive calls outside change windows. See the AI Agent Observability and Incident Response Guide.

Metric	What good looks like
Share of tools with a documented, enforced per-tool profile	100% of write, delete, send and execute tools
Share of tool calls routed through the policy point	100% in production
Destructive or external calls executed without approval or policy decision	Zero
Tools whose credential is broader than their operations	Falling to zero
Budget breaches and suspicious-chain alerts, with time to contain	Every alert triaged; containment in minutes
Production tools and MCP servers pinned by version	100%

Mapping to other frameworks

OWASP's Appendix A maps ASI02 to LLM06:2025 Excessive Agency; the LLM10 link is our addition for loop amplification. ATLAS and NIST IDs are verified against the source catalogues; the ISO/IEC 27001:2022 row is our interpretation.

Framework	Item	Relevance to ASI02
OWASP Top 10 for LLM Applications 2025	LLM06 Excessive Agency; LLM10 Unbounded Consumption	Excessive functionality, permissions and autonomy; loop amplification and cost
MITRE ATLAS	AML.T0053 AI Agent Tool Invocation; AML.T0086 Exfiltration via AI Agent Tool Invocation; AML.T0101 Data Destruction via AI Agent Tool Invocation	The misuse itself
MITRE ATLAS	AML.T0110 AI Agent Tool Poisoning; AML.T0034.002 Agentic Resource Consumption	Poisoned tools; cost and resource abuse
MITRE ATLAS mitigations	AML.M0026, AML.M0028, AML.M0029, AML.M0030, AML.M0033	Agent and tool permissions, human approval, restricting tools on untrusted data, input and output validation
NIST SP 800-53 Rev. 5	AC-6, AC-3, CM-7, SC-7(5), SI-10, AU-12, SI-4(4)	Least privilege, enforcement, least functionality, deny by default, input validation, logging, outbound traffic monitoring
NIST CSF 2.0	PR.AA-05, PR.IR-01, DE.CM-01, DE.CM-09	Permissions, environment protection, network and runtime monitoring
ISO/IEC 27001:2022 Annex A	A.8.2, A.8.3, A.8.15, A.8.16, A.8.22	Privileged access, information access restriction, logging, monitoring, network segregation

Common pitfalls

Treating approval prompts as the control: the Replit agent ignored an instruction to freeze changes. Instructions in chat are not permissions; the credential and the gateway must refuse.
Reusing a convenient broad token: the PocketOS token was meant for domain management but was account-scoped. Tools inherit the worst credential within reach, including ones left in repositories.
Auto-approving "harmless" tools: OWASP's ping-tool scenario shows an auto-approved network utility used to exfiltrate through DNS. Read-only is not the same as no egress.
Reviewing tools one at a time: each tool can pass review while the combination of an internal read tool and an external send tool leaks data. Review and monitor chains.
Resolving tools by short name: without fully qualified names and version pins, a similarly named tool can be selected. Fail closed on ambiguity.
Allowlists that rot: ForcedLeak used an expired domain still on Salesforce's allowlist to move data out. Review egress allowlists for domains you no longer control. See the ForcedLeak breach analysis.

Practitioner checklist

Maintain a tool register with owner, operations, resources, credential, egress and version for every agent tool and MCP server.
Replace general-purpose shell, SQL and HTTP tools with narrow, parameterised operations.
Define and enforce a per-tool profile of scopes, resources, rate limits and egress destinations.
Route all calls through a policy point that validates name, version, schema and intent and issues per-call credentials.
Require human approval with a dry run or diff for destructive, external and financial actions.
Remove production-capable credentials from development agents and keep secrets out of agent-readable files.
Set call, cost and token budgets per tool and per run with automatic throttling.
Sandbox execution and browsing tools with deny-by-default egress, including DNS.
Alert on read-then-send chains, first-time tool use and rate anomalies, and test those detections.

OWASP Agentic Top 10 ASI02 Guide