Excessive agency means an LLM system can take damaging actions because its output was unexpected, ambiguous or manipulated. Controls that work shrink what the agent can do: fewer tools, narrower permissions and human approval. Logging and rate limits help afterward, but OWASP says they do not prevent it.
What does OWASP say LLM06 is?
OWASP's 2025 entry defines the risk by its effect, not its trigger. The cause might be a hallucination, a weak model, or direct or indirect prompt injection, including from a compromised extension or a peer agent. The page's point is that the cause does not matter. If the system can do something harmful, a bad output will eventually do it.
It lists three root causes:
- Excessive functionality. An extension offers functions the application does not need.
- Excessive permissions. An extension has more access to downstream systems than the job requires.
- Excessive autonomy. High-impact actions run without independent verification or approval.
What does that look like in practice?
OWASP's examples are ordinary. A tool meant to read documents also can modify and delete them. A trialled extension is left available after the team moved on. A tool that should run one command accepts any. A database identity has update, insert and delete rights when read was enough. A per-user feature runs under a shared high-privilege account that can reach every user's files.
Its worked scenario: an email summarising assistant has a tool that can also send mail. A malicious message uses indirect prompt injection to make it forward sensitive mail elsewhere. Each design choice in that story was avoidable.
Which controls actually work?
These are the preventive controls OWASP lists, in plain terms.
- Offer fewer extensions. An agent cannot misuse a tool it never had.
- Trim each extension's functions. Expose read, and leave write out unless it is needed.
- Prefer narrow tools over open-ended ones. A shell or a general URL fetcher is a poor fit. A tool that does one named thing is easier to bound.
- Limit permissions downstream. Enforce it in the database or service itself, not in the prompt.
- Act in the user's context. Use the user's own authentication and minimal scopes such as OAuth, not a shared service account.
- Require human approval for high-impact actions. Make the person see exactly what will happen.
- Use complete mediation. The downstream system checks each request against policy, instead of trusting the model to decide what is allowed.
- Check inputs and outputs. OWASP points to ASVS guidance and to SAST, DAST and IAST in the pipeline.
Which controls do not work, or only partly?
OWASP states that logging, monitoring and rate limiting do not prevent excessive agency, though they can limit the damage. Treat them as detection and containment.
Two more habits fail in practice, though the page does not name them. A system prompt that says "never delete files" is a request, and a model can be pushed past it. A confirmation dialog that appears for every minor action trains people to click through, so reserve approval for steps that matter and make the description specific.
How do you review an agent for this?
Write a list of every tool the agent can call. Beside each, write the real permission behind it, not the intended one. Then ask what the worst output the model could produce would do. If the answer is serious, the permission is too wide or the approval step is missing.
The MCP world makes this concrete. An MCP server exposes a catalog of tools to any connected assistant. Safeguard's tenant administrators can switch off client types, and this kind of switch belongs in your review: decide which assistants may connect, and with which identity.
What to do
- Inventory every tool each agent can call.
- Remove tools and functions that the use case does not need.
- Replace open-ended tools with narrow ones.
- Move permission checks into the downstream system.
- Run actions under the user's identity with minimal scopes.
- Add approval for deletion, sending, payment and permission changes.
- Log every tool call, and alert on unusual volume.
- Test with unsafe inputs in a staging environment, and fix the tool, not the prompt.
Quick check
Is excessive agency the same as prompt injection?
No. Prompt injection is one way to trigger a bad output. Excessive agency is the condition that lets that output cause harm. Fix the condition and many triggers lose their force.
Do rate limits stop it?
No. OWASP says they can limit damage, not prevent the risk. Narrow tools and approval steps prevent it.
Sources
Last reviewed: 18 October 2026.
