Excessive agency: the most damaging agent risk
Why over-broad permissions turn a small agent mistake into a major incident — and how least privilege, scoped tools and approval gates contain the blast radius.
Definition
Excessive agency is the risk that an AI agent holds more permissions, autonomy or tool access than its task requires. When exploited or triggered by error, broad privileges let a single bad decision cause outsized damage — deleting data, moving money or sending unauthorized communications.
Most agent incidents are not clever exploits. They are ordinary mistakes made by an agent that simply had too much power. That is excessive agency, and it is consistently the most damaging category in agent security.
The amplifier
Excessive agency rarely causes an incident on its own. It makes every other failure worse. A prompt injection, a hallucinated fact, a buggy plan — each is survivable if the agent can only read. The same event becomes a headline if the agent can also delete the database, wire funds or email customers.
So the risk is multiplicative: impact = likelihood of a bad decision × what the agent is permitted to do. You cannot drive the first term to zero. You can absolutely shrink the second.
- Read-only8/100
- Scoped write (sandboxed)28/100
- Broad write to production72/100
- Admin / unrestricted tools96/100
What does over-permissioning look like?
- A summarization agent that also holds send-email and delete scopes “just in case”.
- One shared credential used by every tool, so any compromise is total.
- Tools that run with admin rights because scoping them was more work.
- An agent that can act on production because that was the fastest path to a demo.
Each is a convenience paid for once, catastrophically.
Least privilege by task
Most tasks map cleanly onto a narrow scope. A few starting points:
| Agent task | Right scope | Never grant |
|---|---|---|
| Summarize documents | Read-only on the source | Write, send, delete |
| Triage support tickets | Read tickets; draft replies | Send without approval; refunds |
| Reconcile invoices | Read the ledger; propose entries | Post payments; admin rights |
| Deploy code | Open a PR; run CI | Merge to main; production secrets |
Containing the blast radius
- Least privilege per tool. Grant the minimum. If the task is to read, the agent cannot write.
- Prefer read over write, and sandbox writes until evidence supports more.
- Split capabilities across identities. A compromise of the reading identity must not grant the writing one — see non-human identity.
- Gate irreversible actions behind human approval.
- Drop unused capabilities. If normal operation never uses a permission, remove it.
The mindset
Assume the agent will, at some point, do the wrong thing — through error, drift or attack. Then design so that the wrong thing is survivable. That single assumption is what separates a robust agent from a future incident report. Terms are in the glossary.
Frequently asked questions
Why is excessive agency rated so highly?
Because it converts every other failure into a bigger one. On its own, a prompt injection, a hallucinated fact or a buggy plan is survivable — if the agent can only read, the worst outcome is a wrong answer. The same event becomes an incident the moment that agent can also delete records, move money or email customers. Excessive agency is therefore the amplifier sitting behind the most serious documented agent failures, which is why frameworks like the OWASP Top 10 for Agentic Applications place it at or near the top. The practical implication is that impact is multiplicative: how often the agent makes a bad decision, times how much damage its permissions allow. You cannot drive the first factor to zero, but you have near-total control over the second — and that is where the leverage is.
Isn't broad access just more convenient?
It is, right up until the day it isn't. Broad access feels efficient because you never have to stop and wire up a narrower scope, but that convenience is effectively a loan: you pay it back, all at once, the first time the agent errs or is manipulated. A summariser that also holds send and delete scopes saved you an hour of configuration and now can leak or destroy data on a single bad step. Scoping access to the task is a small, one-time engineering cost, and it caps the damage of every future mistake or attack rather than one specific scenario. Framed as risk, you are trading a little setup time today for a bounded worst case forever. That trade is almost always worth making, and it gets cheaper the earlier you make it.
How do I scope an agent correctly?
Start from zero permissions and add only what the task provably needs, rather than starting broad and trimming later. Grant each tool the minimum it requires, prefer read over write, and put write and spend behind a human approval step. Give different capabilities different identities, so that compromising the reading path does not hand over the writing path. Sandbox writes until you have evidence the agent behaves, then widen deliberately. Crucially, audit for unused permissions: if a capability is never exercised in normal operation, remove it, because it is pure downside. A good test is to ask, for every scope the agent holds, what the worst thing it could do with that scope is, and whether you would accept that outcome on a bad day. If not, the scope is too broad.
How is excessive agency different from prompt injection?
Prompt injection is how an agent is made to do the wrong thing; excessive agency is how much that wrong thing costs. They operate at different layers and you need to address both. Injection is an input-side attack — hostile instructions reaching the model — while excessive agency is a design-side weakness about the permissions the agent carries regardless of why it misbehaves. The reason security people emphasise excessive agency is that it is far more controllable: you may never fully stop a clever injection, but you can decide today exactly what an agent is allowed to touch. Fixing only injection leaves the blast radius intact; fixing only permissions still lets the agent be misled but contains the fallout. Defence in depth means narrowing the permissions and treating external content as untrusted, so that a successful injection meets an agent that simply cannot do much harm.