Tool Misuse and Excessive Agency: When AI Agents Are Allowed to Do Too Much

Excessive Agency refers to the overly broad autonomy, permissions or functionality of an AI agent – it can do more than its task would require. Tool Misuse is the abusive use of legitimate tools: access is authorised, the usage is not. Both lead to unintended actions, data exfiltration and uncontrolled costs. In the OWASP taxonomy, Excessive Agency forms the umbrella under which Tool Misuse materialises as a concrete agent risk.

• Quick answer 1: Excessive Agency is the cause (too much autonomy/rights), Tool Misuse the consequence (a legitimate tool is used insecurely or for an unintended purpose).
• Quick answer 2: OWASP lists the topic in the LLM Top 10 2025 as LLM06:2025 and in the Agentic Top 10 2026 as ASI02 (Tool Misuse & Exploitation), published on 9 December 2025.
• Quick answer 3: The core countermeasures are least-privilege, scope-limited short-lived tokens, human approval for critical actions and hard rate or cost limits.

Why "being allowed to do too much" is the real agent problem

Classic LLM applications respond: a prompt goes in, a completion comes out. Agentic systems plan, choose tools, write to memory and act – with minimal step-by-step human approval. It is precisely this leap from "responding" to "acting" that makes the question of permissions the central security issue.

OWASP captures this in the LLM Top 10 2025 under LLM06:2025 Excessive Agency: granting unchecked autonomy to act to LLMs with insufficient permission scoping or human oversight. This entry was explicitly extended to agentic architectures in 2025 and is – according to the research – the biggest conceptual bridge that decision-makers need to internalise. Excessive Agency sits directly upstream of several agent risks in the OWASP Top 10 for Agentic Applications 2026, namely ASI02 (Tool Misuse), ASI03 (Identity & Privilege Abuse) and ASI10 (Rogue Agents).

Excessive Agency typically arises at three levels:

• Too many permissions – the agent inherits overly broad rights from the user or service account under which it runs.
• Too much functionality – the agent has access to tools that its task does not require at all (for example a delete or payment tool in a pure read-only use case).
• Too much autonomy – critical actions run without confirmation, for instance via enabled auto-approve or "YOLO" modes.

Tool Misuse (ASI02): legitimate access, illegitimate use

The OWASP description of ASI02 is precise: the agent operates within its authorised privileges but applies a legitimate tool in an insecure or unintended way – it deletes valuable data, calls expensive APIs excessively, performs destructive operations or exfiltrates information. The distinction from ASI03 is important: the access is legitimate, the usage is not.

Typical attack and failure vectors according to the research:

• Prompt injection that repurposes a tool – for example send_email, which is suddenly used to phish the entire customer base.
• Misalignment between the agent's interpretation of the task and the developer's intent.
• Insecure delegation – the agent hands a powerful tool to a sub-agent without contextual safeguards.
• Auto-approve / "YOLO" modes that disable confirmation prompts.

Risks in concrete terms: actions, data, costs

The three dimensions of damage can be clearly separated:

The cost dimension is particularly delicate in the agent world: OWASP lists it in the LLM Top 10 as LLM10:2025 Unbounded Consumption ("denial-of-wallet"). According to the research, multi-step plans multiply the token effort, which is why per-plan budget enforcement is mandatory.

Documented incidents (as of 2026)

The research names several substantiated cases that underpin the damage potential:

• Amazon Q Code Assistant (CVE-2025-8217, July 2025): attackers compromised a GitHub token and injected malicious instructions into the VS Code extension v1.84.0. Destructive prompts in combination with --trust-all-tools --no-interactive would have deleted file systems and cloud resources without confirmation. The extension was installed by roughly 1 million developers; the fix came with v1.85.0.
• OpenAI Operator (Embrace The Red, Johann Rehberger): malicious website content steered the agent into accessing authenticated internal pages and disclosing addresses, phone numbers and emails from GitHub and Booking.com.
• Langflow AI RCE (CVE-2025-34291): CrowdStrike observed several threat actors exploiting an unauthenticated code injection in Langflow – a widely used agent framework.

An illustrative Excessive Agency scenario is the manufacturing procurement cascade (2025) documented in the research: over three weeks, a procurement agent was gradually "convinced" that its authorisation limit was 500,000 US dollars. The attacker then placed 5 million US dollars in fraudulent orders across 10 transactions. The case combines Tool Misuse with the risk of human approvals being rubber-stamped (ASI09).

Countermeasures: defence in layers

The research structures the measures along the lifecycle. Importantly: no single safeguard is sufficient – the layers complement one another.

In addition, the research names two architectural principles for DACH practice: first, the gateway/proxy pattern in front of every agent as a central enforcement point for allow lists, schema validation, cost caps, rate limits and audit logging. Second, the identity question: every agent is its own Non-Human Identity (NHI) with its own credential lifecycle, short-lived tokens and just-in-time provisioning. According to the research, the most common deployment mistake among DACH SMEs is running an agent "just to make it work" under a service account with admin-equivalent rights. Safer is the delegated user identity – the agent acts as the human and is limited to that person's rights.

A word on the effectiveness of human approval: these gates frequently degrade in practice. OWASP lists this as a separate risk, ASI09 (Human-Agent Trust Exploitation) – automation bias and authoritative-sounding output lead to rubber-stamping. Effective gates therefore enforce the independent review of the evidence, not merely the sign-off on the agent's recommendation.

Example: permissions for a newsletter agent

A marketing agent is meant to create and send newsletter drafts. Excessive Agency arises if it is given full access to the email system. Least-privilege in pseudocode:

```
agent_role: "newsletter-draft"
tools:

• read_segment: scope=audience.read rate_limit=20/min
• create_draft: scope=campaign.write rate_limit=10/min
• send_campaign: scope=campaign.send rate_limit=2/h
  require_human_approval=true # Gate: check recipients + content
  deny:
• delete_contact, export_audience, billing.*
  budget:
  token_cap=500000/day usd_cap=20/day circuit_breaker=on
  token:
  type=short_lived ttl=15min
  ```

Effect: even with a successful prompt injection, the agent cannot export or delete contacts, cannot overload a paid bulk API and cannot send a campaign without human approval. The short-lived, scope-limited token devalues stolen credentials after 15 minutes.

For agencies and B2B

Anyone running AI agents for clients in marketing, sales or service bears responsibility for their permission design. A practical starting point: inventory every tool and every scope per agent, disable auto-approve for anything that deletes data, moves money or sends messages, and set hard cost and rate limits before an agent goes into production. Blck Alpaca from Vienna supports DACH B2B organisations in building least-privilege-compliant agent architectures along the OWASP Agentic Top 10. Please note: this article serves as professional information and does not constitute legal advice; please clarify specific compliance and liability questions with qualified advisers.