OWASP lists excessive agency among the top risks for LLM applications: an agent able to take damaging actions because it has too much functionality, permission or autonomy. Holding high-impact actions for a person's approval answers the autonomy part, but only if approval is enforced outside the agent, shows exactly what will execute, and is bound to those parameters.
What does OWASP mean by excessive agency?
The OWASP Top 10 for LLM Applications names the most serious risks in applications built on language models. It includes prompt injection, sensitive information disclosure and excessive agency. Excessive agency is the risk that an LLM-based system performs damaging actions in response to unexpected, ambiguous or manipulated input. Our explainer on what excessive agency is covers the definition.
OWASP traces it to three root causes:
- Excessive functionality. The agent has access to tools or functions it does not need, such as a mailbox connector that can send and delete when it only needs to read.
- Excessive permissions. The tools it uses run with broader rights in downstream systems than the task requires.
- Excessive autonomy. The agent can carry out high-impact actions without independent verification or approval.
The mitigations follow: limit tools to what is needed, limit permissions, enforce authorisation in downstream systems rather than trusting the model, require human approval for high-impact actions, and log and monitor. Our piece on limiting what an agent can do under OWASP covers functionality and permissions; this one covers approval.
Who does it apply to?
OWASP guidance is not law. It is a widely used security reference for anyone building or deploying LLM applications, including agent platforms and the firms that use them. Security teams, auditors and customers increasingly use it as a checklist, so being able to show how you address each item is practical, whether or not anything requires it.
Which actions count as high-impact?
The answer drives the whole design, so make it explicit. An action is high-impact if any of these is true:
- It moves money or creates a financial obligation.
- It cannot easily be undone, such as deleting records or sending a message outside the organisation.
- It changes access, permissions or security settings.
- It has a legal or similarly significant effect on a person, such as declining an application or closing an account.
- It affects many records or people at once.
- It reaches the outside world in the organisation's name.
Everything else can run within bounds without approval, if the agent has earned that authority. Our answer to when an agent can act without human approval sets out the conditions.
How do you build approvals that hold?
A badly built approval step is theatre. Prompt injection can make an agent describe a harmful action as harmless, and a tired approver will click through. Five design rules close those gaps.
Enforce outside the agent. The approval check sits in the platform or the downstream system, not in the agent's instructions. The agent cannot execute a held action, whatever it is told.
Show the real parameters. The approver sees what will actually execute (payee, amount, recipient, records affected), generated from the action itself, not the agent's summary of it. The agent's reasoning can sit alongside, labelled as its view.
Bind approval to the parameters. If anything changes after approval, the approval is void and the action is held again.
Name the approver. Each held action goes to a named person with authority, not a shared queue. The agent cannot approve its own action, and neither can the person who asked for it, where separation matters.
Watch for fatigue. Too many approvals produce rubber stamps. Hold only what is high-impact, and track review times and rejection rates. Our explainer on the human gate covers the concept.
How do you meet the risk with controls and evidence?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| High-impact actions defined | Written list of action types that must be held | Approved action classification |
| Approval enforced outside the agent | Platform holds classified actions before execution | Verdict records showing holds |
| Approver sees real parameters | Approval view generated from action data | Captured approval screens |
| Approval bound to parameters | Changed parameters void approval | Re-hold records |
| Named approvers | Held actions routed to named people with deputies | Routing configuration and approvals |
| Fatigue detected | Review times and rejection rates monitored | Oversight quality reports |
| Logged and reviewable | Every held, approved and rejected action recorded | Append-only record |
Approval is one layer. Our answer on how to prevent excessive agency covers the others.
What will a security assessor or auditor ask?
- Which actions are held for human approval, and who decided?
- Can the agent execute a held action by any route?
- What does an approver see, and where does it come from?
- What happens if the parameters change after approval?
- How do you know approvers are not clicking through?
- Show us rejected actions and why they were rejected.
What does this not cover?
Approval addresses excessive autonomy. It does not remove the need to limit functionality and permissions, which stop harm even if an approval fails. It does not address prompt injection itself, only one of its consequences. And OWASP guidance is not a regulation: laws such as the EU AI Act, the GDPR's rules on automated decisions and sector rules may require specific human involvement on top. For why bounds must be enforced rather than requested, see our guide agent governance is a bound, not a model.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Where Pryme fits
In Pryme, held is one of four verdicts, enforced at the moment of action, not requested in a prompt. The minimum chain checks role scope, certificate, sources, the customer's limits and platform guardrails together, and the verdict names the bound that decided. Some actions are withheld for every agent at every depth, so no approval path exists to exploit.
Questions people ask
Is human approval enough to prevent excessive agency?
No. It answers excessive autonomy. You also need to limit what tools the agent has and what permissions they carry, so that a missed approval cannot cause wide harm.
Can a customer approve actions the agent takes for them?
Yes, for actions on their own behalf, such as a payment. The approval should happen in a trusted channel the agent cannot control, showing the real parameters.
How many actions should be held?
As few as possible while covering every high-impact type. If approvers face long queues of routine items, oversight will degrade.