Excessive agency

Excessive agency is what turns a bad answer into a bad action. An AI agent granted more functionality, permissions, or autonomy than its task needs can carry out damaging operations when triggered — by hallucination, prompt injection, compromised tools, or a malicious peer agent. OWASP moved it from sixth to third in the 2026 LLM Top 10, the clearest signal that concern has shifted from what LLMs say to what they do.

The trigger is not the vulnerability. Excessive agency does not cause the malfunction; it sets the blast radius. A hijacked chatbot with no tools writes a bad summary; a hijacked agent with database access deletes records.

The three root causes

OWASP names three root causes. Excessive functionality is giving the agent tools with more functions than the task needs — a document reader that can also modify and delete, or a trial tool that was never removed. Excessive permissions is granting credentials beyond what the task requires — a tool that connects to a database with UPDATE, INSERT and DELETE when only SELECT is needed, or a tool reading every user’s files through a shared admin account. Excessive autonomy is allowing actions without human confirmation — deleting records, sending email, or making financial transfers without an approval step.

Why it matters

The confused deputy framing captures it: an AI tricked into acting against its owner’s interests with the owner’s credentials, limited only by what the system can actually do. This is not a research abstraction. Microsoft’s Zero Trust catalog treats it as an active attack technique.

What makes it dangerous is the gap between intent and capability. The developer intended an email assistant that reads messages; the chosen tool also sends them. A code assistant was given shell access that can execute arbitrary commands. These are design errors in the system around the model, which is what makes them fixable.

In practice

OWASP’s primary scenario is an email assistant granted send access when only read was needed. An indirect prompt injection delivered through a crafted email tricks the agent into scanning the inbox for sensitive information and forwarding it to the attacker. OWASP notes this could be avoided by eliminating excessive functionality (a read-only tool), excessive permissions (OAuth with read-only scope), or excessive autonomy (requiring the user to review and hit send on every outgoing message). Rate limiting on the send interface reduces the damage even when the other controls are absent.

The pattern repeats across domains. A database tool with full CRUD access instead of read-only. A code assistant with shell access left over from a development phase. An agent that approves its own actions rather than routing high-impact decisions to a human. Each case follows the same structure: the system was given more than it needed, and the gap between grant and need is where the harm lives.

Where definitions disagree

How wide the term decides what a claimed defence covers. OWASP scopes excessive agency to the vulnerability itself: the granting of excess capability, regardless of the trigger. Microsoft’s Zero Trust catalog treats it as an attack technique within a broader threat model, combining the vulnerability with the attacker’s use of it. MITRE ATLAS does not have a single excessive-agency technique, but maps the behaviour across tool invocation (AML.T0053), prompt injection (AML.T0051), jailbreak (AML.T0054), and external harms (AML.T0048) — a decomposition that treats excessive agency as an outcome of multiple intersecting weaknesses rather than a standalone risk.

The confused-deputy framing — an agent given the owner’s credentials and more tool capability than the task needs, tricked into using them — is AI Matter’s analysis of what OWASP describes, not a term either OWASP or Microsoft uses. OWASP scopes excessive agency to the vulnerability itself: the granting of excess capability, regardless of the trigger. Microsoft’s Zero Trust catalog treats it as an attack technique within a broader threat model, combining the vulnerability with the attacker’s use of it. The gap matters: a defence scoped to the agent alone misses the system-level design choices — the tool’s capabilities, the permissions on the credential, the absence of an approval workflow — that made the deputy confused in the first place.

Questions and answers

What is excessive agency?

Excessive agency is an LLM application vulnerability in which an AI system has been granted more functionality, permissions, or autonomy than its task requires, so that a trigger such as hallucination or prompt injection produces real-world harm. OWASP defines it as the vulnerability that enables damaging actions in response to unexpected, ambiguous or manipulated outputs, regardless of what is causing the LLM to malfunction.

How does excessive agency differ from prompt injection?

Prompt injection is the attack; excessive agency is the blast radius. Prompt injection causes the model to misbehave. Excessive agency determines what that misbehaviour can accomplish. A chatbot with no tool access may produce an offensive answer when hijacked; an agent with database write access may delete records. Same trigger, different consequences, because the system was built with different capabilities.

What are the three root causes?

OWASP names excessive functionality (tools with more functions than the task needs), excessive permissions (credentials that go beyond what the task requires), and excessive autonomy (actions performed without human confirmation). Most real-world incidents involve two or all three. A tool that can read and delete files, running with an admin account and no approval step, has all three.

How do you prevent excessive agency?

Architecturally. OWASP recommends minimizing tools and their functionality, avoiding open-ended tools like shell access, enforcing least-privilege permissions, executing tools in the authenticated user's own context rather than a shared privileged account, requiring human approval for high-impact actions, and implementing complete mediation so every action is validated against policy by an independent enforcement point rather than trusting the LLM to decide what is allowed.