OWASP LLM06 excessive agency: a checklist for engineering leads

Excessive agency (OWASP LLM06:2025) is when an AI system takes damaging actions because it was given too many tools, too many permissions or too much freedom. The fix is structural: fewer tools, narrow rights, human approval for high impact actions, and authorization enforced by downstream systems rather than the model.

What triggers it?

OWASP says the damaging action follows unexpected, ambiguous or manipulated model output. Triggers include hallucination, a poorly performing model, and direct or indirect prompt injection. The impact depends on what the application can reach, and can touch confidentiality, integrity and availability.

OWASP names three root causes. Use them as the headings of your review.

• Excessive functionality. The agent has tools with capabilities it does not need, such as a read only document tool that can also modify or delete files, or a retired extension that is still available.
• Excessive permissions. The tool holds more rights downstream than required, such as database credentials with insert, update and delete when only select is needed, or one high privilege identity used for per user actions.
• Excessive autonomy. High impact actions run without independent verification or approval, such as deleting documents without user confirmation.

What is the checklist?

Work through it per agent, per tool.

Functionality

• Does the agent see only the tools it needs for this task?
• Does each tool implement only the functions required? A summarizer needs read only mail access, not send.
• Have you replaced open ended tools, such as shell execution or fetching any URL, with narrow tools built for one purpose?
• Are retired tools removed from the agent's list?

Permissions

• Is the downstream access limited by the database or service identity, not by a prompt?
• Do tools act in the context of the specific user, for example via OAuth with minimal scopes, instead of a shared high privilege account?

Autonomy and approval

• Is there a human approval step for high impact actions: deleting data, sending external messages, moving money, changing production?
• Does the approval show exactly what will happen, not a summary written by the model?

Mediation

• Does every downstream request pass an authorization check against policy, outside the model? OWASP calls this complete mediation.
• Are inputs and outputs sanitized, following secure coding practice such as OWASP ASVS, and do your pipelines run static and dynamic testing?

Damage limits

• Do logging, monitoring and rate limiting exist? OWASP notes they do not prevent excessive agency but they limit the damage.

How should a lead run the review?

Pick one agent. Write down each tool, the identity it uses and the worst action it can take. Ask what happens if the model is tricked into calling it with attacker chosen arguments. If the answer is acceptable, move on. If not, remove or narrow the tool before adding any prompt based guard.

Do this review again when someone adds a new tool, because capability tends to accumulate.

What to do

1. Inventory agents and their tools in one table.
2. For each tool, record the identity, permissions and worst case action.
3. Remove unused and open ended tools first, since that is the cheapest risk reduction.
4. Replace shared service accounts with scoped, per user access where the platform allows.
5. Add approval for the short list of high impact actions.
6. Make downstream services check authorization on every call.
7. Turn on logs for tool calls and review a sample weekly.

Where Safeguard fits

The Safeguard MCP server at mcp.safeguard.sh is designed to work with Claude, ChatGPT, Cursor or your own agent. Tenant admins can switch off any client type, which is one way to narrow what agents may reach. The checklist above applies to your own agents and tools as well.

Quick check

Sources

• OWASP, LLM06:2025 Excessive Agency

Last reviewed: 18 October 2026.