Excessive agency, in the OWASP Top 10 for LLM Applications, is the risk that a system takes damaging actions because it was given more power than its job needs. OWASP traces it to three causes: excessive functionality, excessive permissions and excessive autonomy. Each needs its own cut, and for AI agents all three must be enforced outside the model.
What does OWASP say excessive agency is?
The OWASP Top 10 for LLM Applications lists the most important security risks for applications built on large language models. Excessive agency is the entry most specific to agents. OWASP describes it as a vulnerability that lets damaging actions happen in response to unexpected, ambiguous or manipulated model output, whatever caused the output: a confused model, a poorly written instruction, or an attacker's injected text.
OWASP names three root causes:
- Excessive functionality: the agent has tools that do more than the job needs, such as a document reader that can also delete, a plug-in left over from testing, or an open-ended tool that runs any command.
- Excessive permissions: the tools connect to downstream systems with more rights than needed, such as write access where read would do, or a shared high-privilege account instead of the user's own rights.
- Excessive autonomy: high-impact actions happen without independent checking or approval.
The OWASP list is guidance, not law. For an overview of the term, see what excessive agency is.
Who does it apply to?
Anyone building or running an application on a language model that can call tools, retrieve data or take actions. Security teams use the list to plan design reviews and tests. Supervisors and auditors increasingly recognise it as a reference point for AI security, so firms in regulated sectors find it useful to show how each entry is addressed.
Why is it the central risk for agents that act?
Most entries in the OWASP list describe how a model can be confused or manipulated. Excessive agency decides how much damage follows. A model that misreads an instruction and has only read access produces a wrong answer. The same misreading with payment rights produces a loss. That is why OWASP's advice on prompt injection and excessive agency belongs together; our piece on OWASP prompt injection and agents that act covers the other half.
It also explains why the controls must sit outside the model. If the model decides whether it may act, a manipulated model will decide that it may. OWASP's term for the alternative is complete mediation: every request to a downstream system is checked by that system or a layer in front of it, not by the model.
How do you cut back each cause?
Cut functionality to the capability. List the actions the agent's job needs and give it tools for those only. Replace open-ended tools with narrow ones: "send a templated payment reminder to this customer" rather than "send any email". Remove tools left from development. Treat each tool as a capability with its own owner.
Cut permissions to the case. Connect tools with the narrowest rights that work, and where possible in the context of the specific customer or user, so an agent handling one account cannot reach another. Separate read from write. Avoid shared service accounts with broad rights.
Cut autonomy by action type. Decide, per capability, how far the agent may act: read, draft for a person to send, execute routine work within limits, or take actions that are hard to undo. Require a named person's approval for the last group, and enforce it in the layer that executes the action. Our piece on human approval for high-impact actions covers how to design that step.
Take an illustrative case. A retail bank builds a service agent that can look up transactions, explain fees and refund small charges. A design review finds three problems: the lookup tool can query any account; the refund tool has no limit; and a general "update customer" tool was added for testing. The fixes are a lookup scoped to the authenticated customer, refunds capped below a small amount with anything above held for a person, and removal of the testing tool. A later attempt to talk the agent into refunding a large sum ends in a held action, not a payment.
How do you meet OWASP's guidance on excessive agency?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Minimise tools | Tool list per agent matched to approved capabilities | Capability register; tool inventory |
| Minimise tool functionality | Narrow, purpose-built tools instead of open-ended ones | Tool specifications |
| Minimise permissions | Least-privilege credentials, scoped to the case or user | Access configuration; access reviews |
| Execute in user context | Agent acts with the rights of the customer or staff member it serves | Identity mapping |
| Limit autonomy | Approval by a named person for high-impact actions | Held-action records with approver |
| Complete mediation | Every tool call checked against limits outside the model | Verdict log for each call |
| Monitoring | Refused and held actions reviewed; unusual tool use flagged | Monitoring reports |
| Rate limits | Caps on how many actions an agent can take in a period | Configuration and breach alerts |
For a practical sequence, see how to prevent excessive agency in AI agents.
What will a security reviewer or auditor ask?
- List every tool this agent can call and what each can change.
- What credentials does each tool use, and could it reach another customer's data?
- Which actions need a person's approval, and where is that enforced?
- What stops a manipulated model from calling a tool it should not?
- Show us the record of the last action that was held or refused.
What does the OWASP entry not cover?
It does not tell you which actions a given business should allow, or what limits are appropriate; those are business and risk decisions. It does not create legal duties, though excessive agency maps closely to human oversight duties under the EU AI Act and to access controls in security standards. For the full list applied to agents, see how the OWASP Top 10 for LLM Applications applies to AI agents, and for binding rules, our guide to AI agent regulation mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Where Pryme fits
Pryme addresses all three causes outside the model. The brief lists the agent's capabilities, each with its own depth; customer limits narrow permissions; and every action meets the minimum chain of role scope, certificate, sources, customer limits and platform guardrails, with the lowest bound winning. Actions that should never happen at any depth are withheld at the platform floor.
Questions people ask
Is excessive agency only a problem when attackers are involved?
No. OWASP is explicit that ordinary model errors and ambiguous instructions can trigger it too. Limiting functionality, permissions and autonomy reduces harm from mistakes as well as attacks.
Can a well-written system prompt prevent excessive agency?
No. Instructions to the model can be ignored, misread or overridden by injected text. The limits have to be enforced by the systems the agent calls, or by a layer in front of them.
How often should an agent's tools and permissions be reviewed?
Whenever a tool is added or changed, and periodically like any privileged access. Tools tend to accumulate, and each addition widens what the agent can do.