Excessive Agency explained: OWASP LLM06 and how to contain it

TL;DR:

• Excessive Agency (OWASP LLM06) is the risk that an agent can take damaging actions because it has too much functionality, permission, or autonomy.
• It splits into three sub-types: excessive functionality, excessive permissions, and excessive autonomy.
• The damage usually starts with manipulated output, often from a prompt injection, and is contained by least privilege plus a human gate.
• This article supports the OWASP LLM Top 10 hub; pair it with least-privilege for AI agents and prompt injection explained.

What is Excessive Agency?

Excessive Agency is the risk that an LLM-based system is granted so much functionality, permission, or autonomy that an unexpected or manipulated model output causes real harm. The vulnerability is not the bad output itself; it is the agent’s ability to act on that output without a meaningful limit. A chatbot that produces a wrong answer is a content problem. An agent that acts on a wrong answer by deleting a database is an agency problem.

This risk is catalogued as LLM06 in the OWASP LLM Top 10, maintained by the OWASP GenAI Security Project. Developers give agents agency on purpose, because calling tools and interfacing with other systems is what makes an agent useful. LLM06 is about granting that agency carefully, so a single faulty or hijacked output cannot translate into a damaging action.

What is OWASP LLM06?

OWASP defines LLM06 as the harm that arises when damaging actions are performed in response to unexpected, ambiguous, or manipulated output from an LLM, regardless of what caused the malfunction. The trigger could be a hallucination, an ambiguous instruction, or a deliberate attack such as prompt injection; LLM06 focuses on the consequence, not the cause.

OWASP attributes Excessive Agency to three contributing causes. Understanding them separately matters, because each has a distinct fix.

What is the difference between excessive functionality, permissions, and autonomy?

The three sub-types describe where the over-provisioning sits: in the tools an agent holds, in the access those tools have, or in the agent’s freedom to act alone. The mitigations differ, so naming the right sub-type points you at the right fix.

Sub-type	What it means	Mitigation that works well
Excessive functionality	The agent can call tools or functions it does not need for its task. A mail-reading tool that can also send and delete messages is a classic example.	Minimise the toolset to essential operations; remove unused or open-ended functions such as shell access or arbitrary URL fetching.
Excessive permissions	A tool holds more access rights on a downstream system than the task requires, such as a database connection with INSERT, UPDATE, and DELETE when only SELECT is needed.	Scope each tool to least privilege; run extensions in the user’s own context with OAuth and enforce authorisation in the downstream system.
Excessive autonomy	The agent performs high-impact or irreversible actions without independent verification, such as deleting documents without confirmation.	Require human-in-the-loop approval for significant actions; gate irreversible operations behind an explicit confirmation step.

Excessive functionality

Excessive functionality is having tools or capabilities beyond what the task needs. The common cause is convenience: a developer wires in a broad integration, such as a full email tool, when the agent only needs to read. Every extra capability widens the set of actions an attacker can provoke. The fix is to trim the toolset to the minimum and avoid open-ended extensions like shell commands or unrestricted fetching.

Excessive permissions

Excessive permissions is when a tool’s credentials grant more access than the task requires. A reporting agent that only reads should never hold write or delete rights on the database. Even a correctly scoped toolset is dangerous if the tools themselves are over-privileged. Scope each connection to least privilege, prefer per-user OAuth over a shared high-privilege service account, and enforce authorisation in the downstream system rather than trusting the agent.

Excessive autonomy

Excessive autonomy is acting on high-impact decisions without independent verification. An agent that can delete records, move money, or email customers on its own has no circuit breaker if its reasoning is wrong or hijacked. A human gate on irreversible actions is the single most reliable structural control. Reserve it for genuinely significant operations so the friction stays proportionate.

What does an Excessive Agency failure look like?

A realistic failure chains a manipulated output with over-broad agency. The harm comes from the action, not the text. Consider an email-triage agent built on a full email integration:

1. The agent reads an inbox to summarise it and ingests a message containing hidden instructions, a prompt injection.
2. Because of excessive functionality, the same tool that reads mail can also send and delete it.
3. Because of excessive permissions, the agent’s credentials can act on every mailbox, not just the user’s.
4. Because of excessive autonomy, no human approves the action, so the agent forwards sensitive mail to an attacker and deletes the evidence.

Remove any one of the three sub-types and the attack largely collapses. The scenario here is illustrative, not a measured incident.

How do you prevent Excessive Agency?

You prevent Excessive Agency by assuming an output will eventually be wrong or manipulated, then ensuring the agent cannot do serious harm when it is. OWASP’s recommended controls map directly onto the three sub-types:

1. Minimise functionality. Give the agent only the tools and functions it needs, and avoid open-ended extensions such as shell or arbitrary URL fetching.
2. Minimise permissions. Scope every tool to the least access required, run extensions in the user’s context with OAuth, and enforce authorisation in downstream systems.
3. Minimise autonomy. Require human approval for high-impact or irreversible actions; do not let the agent self-authorise significant operations.
4. Sanitise inputs and outputs, and monitor and rate-limit tool activity so abuse is detected and slowed.

The deepest fix is structural: an agent that can only read public data and cannot send, delete, or transact causes little harm even when something upstream fails. See least-privilege for AI agents for the tool-scoping detail.

How does Excessive Agency relate to prompt injection?

Prompt injection and Excessive Agency are a pair. Injection is the trigger; agency is the amplifier. A prompt injection (LLM01) supplies the malicious instruction, and excessive functionality, permissions, or autonomy decide how much damage that instruction can do. This is why limiting agency is the most durable defence against injection: you cannot reliably stop a model from being fooled, but you can ensure that a fooled model has nothing dangerous to reach for.

Where to go next

Use the OWASP LLM Top 10 hub to see how Excessive Agency (LLM06) connects to prompt injection (LLM01) and the rest of the list. For the tool-layer controls above, read least-privilege for AI agents and the AI agent hardening checklist. Browse more in the guides library.