Excessive agency
Excessive agency is the risk that an AI agent takes a damaging action because it holds more functionality, permission, or autonomy than its task actually requires. It is LLM06 in the OWASP Top 10 for Large Language Model Applications, which defines it as "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM, regardless of what is causing the LLM to malfunction". The last clause is the important one. It does not matter why the model went wrong: a hallucination, a badly worded prompt, or an instruction hidden in a log line the agent was asked to read. What determines the damage is what the agent was holding when it went wrong. If the agent has a permission, a malfunction can spend it.
The three root causes OWASP names
- Excessive functionality. The agent has tools it does not need for its task: a database tool that can write when the job only ever reads, a file plugin that can delete because deleting came bundled with listing.
- Excessive permissions. The tools are right, but the identity they run under can do more than they expose. A read-only agent connected with a database user that holds write access is one prompt away from being a read-write agent.
- Excessive autonomy. The agent performs high-impact actions without a human confirming them, so there is no point at which a wrong decision can be caught before it lands.
These decompose the problem usefully, because they fail independently. An agent with perfectly scoped tools can still be dangerous if the credentials behind them are broad, and an agent with narrow credentials can still cause an outage if it is allowed to act unsupervised on something irreversible.
Why you cannot prompt your way out of it
The instinctive mitigation is to tell the model not to do the dangerous thing. This does not work, and the reason it does not work is structural: a system prompt is an input, and inputs are the part of the system an attacker gets to influence. Prompt injection is the case where untrusted text (a log line, a page the agent fetched, a comment on an issue) is read as an instruction. If the agent can be talked into an action, an instruction not to take it is a request, not a control.
Prompt injection and excessive agency are often conflated, and separating them is what makes both tractable. Injection is a cause: it is how a model comes to want the wrong thing. Excessive agency is the multiplier: it is what determines how much that costs. You will not eliminate the first. You can bound the second, and bounding it is an access-control problem with well-understood tools: the same least privilege applied to a non-human principal, and the same blast radius arithmetic used to check your work.
What actually reduces it
- Give the agent the smallest set of tools that does the job, and prefer tools that cannot express the dangerous action at all over tools that can express it and are asked not to.
- Run those tools under an identity scoped to exactly what they do, so a compromised agent cannot reach past its tools into the credentials underneath them.
- Require a human to confirm actions that are expensive to undo. Autonomy is a property you grant per action, not per agent.
- Log every action the agent takes, with the identity that took it, so an incident is reconstructable.
Which is to say: treat the agent as a principal. It gets an identity, a permission set, and an audit trail, exactly like an employee. And, exactly like an employee, it should not be handed production credentials on its first day because it seemed helpful. IBM's Cost of a Data Breach Report 2025 found that 97% of organisations that were breached through an AI tool had no AI access controls in place, which is less a surprising finding than a description of how new the practice is.