Excessive Agency

Excessive agency concerns the functionality, permissions, or autonomy through which a model-based application can cause damage from unexpected or manipulated output. OWASP identifies these as distinct sources of excessive capability. Assess what the assigned task needs, what the model may invoke, and which conditions must be checked before execution. Harmful output can have other routes too; tool agency is not the only source of AI harm.

A fictional example makes the shape visible. An accounts-payable assistant reads supplier emails and matches invoices to purchase orders. It was also given a function to update supplier records, because bank details change often. The function ran with a credential that could update any supplier, and nothing confirmed an update before it executed. When an email containing a hidden instruction told the assistant to change one supplier’s bank account, the change went through, and the next payment run paid the attacker. The instruction came from a prompt injection. The transfer came from excessive agency.

Three root causes

OWASP identifies excessive functionality, excessive permissions, and excessive autonomy. A system can have one or more of these weaknesses, with remedies in different components.

Excessive functionality is a tool that can do more than the task needs. OWASP’s examples include a third-party extension chosen for reading documents that also modifies and deletes them, an extension trialed during development and left available, and an open-ended extension, such as one that runs a shell command, that fails to restrict which commands. In the fictional example, the update function was provided because bank details change often, but that need does not establish that a model reading untrusted invoices should be able to execute updates. It could instead propose a change for a separately authorized process. The fix is in the tool set: fewer tools, each narrow.

Excessive permissions is a tool whose credential reaches more than the task needs on the systems behind it. OWASP’s examples are an extension meant to read data that connects with an identity holding update, insert, and delete rights, and an extension acting for one user that connects with a privileged account able to reach every user’s files. The assistant’s update function held a credential for every supplier. The fix is in the identity the tool uses, which is the subject of least privilege, applied to both the operation and its resource scope, and of running the tool with the user’s own identity as an upper bound, with narrower task, operation, resource, and recipient constraints where required.

Excessive autonomy is the absence of a check before a high-impact action. OWASP’s example is an extension that deletes a user’s documents “without any confirmation from the user.” The assistant changed bank details without anyone seeing the old and new values. The fix is in the flow: the actions whose consequence is large or hard to reverse wait for a person, and the person sees the exact action before approving it.

These weaknesses can compound, but their effects depend on the path. A narrow tool backed by a broad credential is exposed if that credential can be extracted or the tool can be redirected; the broad credential alone does not prove such a bypass. Removing access to other suppliers would still allow a malicious update to the compromised supplier if that resource remained authorized. Removing the update operation or requiring effective independent confirmation targets a different link. OWASP distinguishes agency from output handling: the latter concerns how generated content is checked before another component uses it, while agency concerns available functions and authority.

What reduces it

OWASP’s prevention list maps onto the three causes. Offer the model only the extensions it needs, and within each extension only the functions it needs; prefer a specific file-writing tool over a shell. Grant each extension the minimum permissions on downstream systems, enforced by those systems’ own access control rather than by instructions to the model. Execute extensions in the user’s context, with independently checked authorization and any narrower task scope; the user’s ability to perform an action does not prove that the user requested this instance. Require a person to approve high-impact actions, implemented either in the downstream system or in the extension itself. And apply complete mediation: authorization decisions are made in the downstream systems, so that every request arriving through an extension is checked against policy, rather than trusting the model to decide whether an action is allowed. OWASP is careful about two further measures, logging with monitoring and rate limiting, which “will not prevent Excessive Agency, but can limit the level of damage caused”; they belong in the design as a second layer, not as the first.

Two boundaries of the term are worth stating. Isolation is not a substitute for it: running a tool inside a sandbox limits what a misused tool can touch on the host, but isolation alone need not restrict an otherwise valid downstream credential; network and service authorization controls must cover that path. And a permitted action can still be a wrong one; excessive agency is about the system’s ability to act, and the correctness of a permitted action is the job of grounding, validation, and review. How approval, retries, and state are designed for agents that act is covered in The Refund Went Out Twice, and where this risk sits among the others a deploying organization has to manage, including its combination with prompt injection, in The Invoice Gave the Instructions.

References

• OWASP, LLM06:2025 Excessive Agency, OWASP Top 10 for LLM Applications 2025 (Creative Commons Attribution-ShareAlike 4.0)