The more an agent can do, the more a single manipulation can cost you. Excessive agency is the gap between what an agent needs and what it is allowed. We explain how to close it without making the agent useless.
Every capability you give an agent is also a capability an attacker can borrow. That single sentence is the whole of Excessive Agency, and it is why we treat the scope of an agent's powers as a security decision, not a product one. The risk is not that your agent is too capable in the abstract. It is the gap between what the agent actually needs to do its job and what it is technically permitted to do. Attackers live in that gap.
OWASP lists Excessive Agency for LLM applications, and the newer agentic guidance reinforces it, because as systems move from answering to acting, this is the risk that converts a manipulation into real-world damage.
The three forms of "too much"
We find it useful to break excessive agency into three concrete excesses, because each has a different fix.
Too much functionality. The agent has access to tools and functions it does not need for its task. A support agent that can also delete records, send arbitrary emails, or call internal admin APIs is carrying powers waiting to be misused. Often these accumulate because a broad toolset was easier to wire up than a precise one.
Too many permissions. The agent's credentials reach further than its job requires. It can read the whole database when it needed one table, write when it only needed to read, act across systems when it should have been scoped to one. This is the least-privilege failure we keep returning to, because it is the multiplier on almost every agentic incident.
Too much autonomy. The agent can take consequential, hard-to-reverse actions without a human in the loop. Sometimes that is the right design. Often it is just the default, and no one decided that a high-stakes action should proceed unchecked; it simply did.
Why this is the risk that turns injection into impact
We have written about the breach chain: untrusted content hijacks the agent's goal, and then its permissions decide the damage. Excessive agency is that second step. A prompt injection against a tightly scoped agent is a contained event, because there is little the hijacked agent can actually do. The same injection against an over-powered agent is a catastrophe, because the attacker inherits everything you granted. The injection chooses the intent; the agency determines the blast radius.
This is why we tell teams that scoping an agent is not bureaucracy that slows the agent down. It is the control that decides whether your worst day is an incident or a disaster.
The honest tension
Here is the difficulty, stated plainly: capability is the reason you deployed the agent, and every restriction feels like it works against that. Tightening functionality, permissions, and autonomy takes effort and adds friction, and the path of least resistance is always to grant broadly so the thing just works. We understand the pull. But broad-by-default is exactly how agents end up holding powers nobody remembers granting, and the cost only becomes visible when something gets through. The goal is not a timid agent. It is an agent that is fully capable at its task and incapable of anything else.
What to do about it
- Minimise functionality. Give the agent only the tools its task requires. Remove the ones it does not use.
- Scope permissions to the task. Narrow credentials, least privilege, ideally per-agent identity. A hijacked agent should still only reach what its job legitimately needed.
- Gate high-stakes autonomy. Require human approval for consequential, irreversible actions. Decide deliberately which actions those are.
- Enforce policy on actions, not just inputs. An independent layer that checks what an agent is about to do, and blocks what falls outside policy, catches misuse that input filtering alone would miss.
Frequently asked questions
Doesn't a human-in-the-loop defeat the point of automation? Not if you apply it selectively. Most agent actions can proceed freely; you reserve human approval for the small set that are consequential and hard to reverse. That preserves the productivity gain while removing the catastrophic tail.
Isn't this just access control again? Permissions are a big part of it, yes, but excessive agency also covers functionality and autonomy, which access control alone does not address. An agent can have correctly scoped credentials and still hold a dangerous tool it never needed.
How does this connect to prompt injection? Directly. Injection is the trigger; agency is the amplifier. You have to defend both. Detecting the injection and constraining the agency are complementary, and neither replaces the other.
How Promptention helps
Our agentic defense is built precisely for this multiplier. We help enforce policy on what an agent is allowed to do and where it can send data, so that even a fully hijacked agent runs into a wall instead of running wild, and we catch the injection that would have triggered it in the first place. The strongest version of this control is also organisational, scoping each agent's functionality, permissions, and autonomy to its task, and we work with teams to get that right. Keep your agent capable. Just not capable of your worst case.
Promptention supports policy enforcement on agent tools and actions, aligned to OWASP LLM06: Excessive Agency and the OWASP Top 10 for Agentic Applications.
