Excessive agency, one of the risks in the OWASP Top 10 for LLM Applications, is what happens when an AI agent has more functions, permissions or autonomy than its job needs. Reviewers who approve and monitor agents often see it first. They must be trained to read its signs in held actions, refusals and the record, and escalate early.
What does the OWASP list say about excessive agency?
The OWASP Top 10 for LLM Applications is a community-maintained list of the most important security risks in applications built on large language models. It includes prompt injection, sensitive information disclosure and excessive agency, among others. It is guidance, not law, but security teams, auditors and customers use it as a reference.
In substance, OWASP describes excessive agency as an agent being able to take damaging actions in response to unexpected, ambiguous or manipulated output from the model. It traces the problem to three causes:
- Excessive functionality. The agent has access to tools or functions it does not need, such as a delete function on an agent meant only to read.
- Excessive permissions. The tools it does need run with broader rights than necessary, such as write access to every customer record instead of one.
- Excessive autonomy. The agent can take high-impact actions without a person confirming them.
The suggested mitigations follow: limit tools, limit permissions, require human approval for high-impact actions, enforce authorisation in the downstream systems rather than trusting the agent, and log and monitor what agents do. The system side is covered in OWASP Top 10 for LLM Applications applied to AI agents.
Who does it apply to?
Anyone building or running LLM-based agents who chooses to use the list, which in practice is most security-conscious organisations. Reviewers in scope are the people closest to agent behaviour: approvers of held actions, workspace operators, agent owners, security analysts monitoring agent activity, and internal auditors. Boards of public bodies and regulated firms increasingly ask about it too. A plain-language definition is in what excessive agency is.
Why are reviewers the right people to train?
Design controls prevent most excessive agency. Reviewers catch what design missed, because they see the agent at work. Every action an agent takes meets five bounds at once: its role scope, its certificate, its sources, the customer's own limits, and the platform guardrails. The lowest bound wins, and each verdict names the bound that decided it. That record is where excessive agency shows up, if someone knows how to read it.
What should reviewers be trained to spot?
Actions outside the job. A held action that does not fit the agent's role, such as a support agent proposing a change to a customer's payment details, suggests excessive functionality. The reviewer should refuse it and report the agent, not just the action.
Allowed actions that should have been held. If an agent completes something that the reviewer would expect to be held, such as a refund above the usual amount, the bounds may be wider than intended. Reviewers should know each agent's certified depth, and the depth each action needs, well enough to notice.
Refusals that cluster. A sudden run of refusals at the role scope bound can mean the agent is trying to do things outside its job, often because of manipulated input. Refusals protect, but a pattern is a signal.
Actions driven by external content. Facts that arrive from outside, such as an emailed invoice or a web page, are marked external. An agent that proposes a payment because an email told it to is showing prompt injection turning into agency. An external claim cannot authorise a payment, and reviewers should treat any draft resting on one with suspicion.
Permissions out of step with the task. When reviewing an agent's configuration, reviewers should ask whether each connection and permission is needed for the capabilities the agent's role covers.
Pressure to approve. Agents can produce persuasive justifications. Reviewers must judge the action, not the prose around it.
Red-team exercises make these signs concrete. Red-teaming AI agents against the OWASP Top 10 describes how to build cases reviewers can practise on.
How do you meet the guidance and show it?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Limit functionality | Agent tools listed per capability; reviewers check fit to role | Tool register; review sign-offs |
| Limit permissions | Least privilege on agent connections; periodic review | Access reviews |
| Limit autonomy | High-impact actions held for named people | Hold and release log |
| Downstream authorisation | Target systems enforce their own checks | System configuration evidence |
| Logging and monitoring | Every verdict filed with the deciding bound | Append-only decision record |
| Reviewer competence | Training on excessive agency signs, with seeded cases | Training records; detection results |
| Escalation | Clear route to report an agent, not just an action | Escalation log; follow-up actions |
What will a security reviewer or auditor ask?
- For this agent, which tools does it have, and does each match a capability in its role?
- Which actions are held, and who releases them?
- Show us refusals by bound over the last month. What explains the patterns?
- How would a reviewer spot an action driven by injected content?
- What happened the last time a reviewer reported an agent?
The overall picture is in how the OWASP Top 10 for LLM applications applies to AI agents.
What does the list not cover?
It is not a regulation or a certification. It does not address fairness, customer outcomes or data protection law. It does not set training content. And it does not replace a full security programme such as one aligned with ISO/IEC 27001. The guide to AI literacy and certification places reviewer training in the wider model.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Where the Academy fits
Pryme Intelligence Academy's Operator track teaches how a governed agent decides and when something goes wrong, which is where reviewers learn to read verdicts and bounds. Its practicum requires no missed red line across two weeks of real review decisions. People who design agents take the Builder track, where limiting tools and permissions is part of preparing an agent for certification.
Questions people ask
Is excessive agency the same as prompt injection?
No. Prompt injection is manipulation of the agent's input. Excessive agency is the capacity to do damage when that happens. Limiting agency reduces the harm injection can cause.
Can reviewers fix excessive agency themselves?
Usually not. They spot and report it; agent owners and builders change tools, permissions and bounds.
How often should agent permissions be reviewed?
Whenever capabilities change, at each recertification, and on a regular cycle besides.