OWASP LLM06 excessive agency, explained with an email assistant

Excessive agency, LLM06 in the OWASP Top 10 for LLM Applications 2025, is the weakness that lets an LLM based system take damaging actions because its output was unexpected, ambiguous or manipulated. The cause is rarely the model alone. It is too many tools, too many permissions or too little human approval.

What does OWASP say it is?

OWASP's page explains that developers give LLM systems agency: the ability to call functions or interact with other systems through extensions, which vendors may call tools, skills or plugins. In agent designs, the model may choose which extension to invoke.

The risk appears when output goes wrong, "regardless of what is causing the LLM to malfunction." OWASP names two common triggers: hallucination or confabulation, and direct or indirect prompt injection, including from a compromised extension or a compromised peer agent.

That framing is useful. You do not have to predict why the model misbehaves. You limit what a misbehaving model can do.

What are the three root causes?

Excessive functionality. The extension offers capabilities the app does not need, such as write or delete functions when only reading is required. OWASP also lists abandoned extensions still available to the agent.

Excessive permissions. The extension holds more rights downstream than necessary, for example a database identity with write access when only reads are needed, or a generic high privilege account instead of the individual user's identity.

Excessive autonomy. Nothing independently verifies or approves a high impact action, such as deleting documents without user confirmation.

What is the example scenario?

OWASP describes a personal assistant app that reads a user's email to summarize incoming messages. The chosen plugin can also send email, and the app is open to indirect prompt injection. A malicious email tricks the model into searching the inbox for sensitive data and forwarding it to an attacker.

A note on honesty: this is OWASP's illustrative scenario, not a named public incident, and we are not citing a specific real company here. Its value is that each fix maps to one root cause.

• Excessive functionality: use a plugin that only provides mail reading.
• Excessive permissions: authenticate with OAuth and a read only scope.
• Excessive autonomy: require the user to review and send every drafted email.

OWASP adds rate limiting on the send interface, which limits the damage if an attack succeeds.

How is this different from insecure output handling?

OWASP separates the two. Insecure output handling is about insufficient scrutiny of what the model produces. Excessive agency is about what the system is allowed to do with it. You can have either one without the other, and you need to check for both.

What prevention list does OWASP give?

OWASP's prevention and mitigation list, in short:

1. Minimize the extensions the model can call.
2. Minimize what each extension can do. Read, not send or delete.
3. Avoid open ended extensions such as shell execution or arbitrary URL fetching.
4. Minimize permissions on downstream systems, enforced there.
5. Run extensions in the user's context, with that user's authorization.
6. Require user approval for high impact actions.
7. Use complete mediation: enforce authorization downstream, not in the model.
8. Sanitize inputs and outputs, and use SAST and DAST or IAST in development pipelines.

OWASP is clear that these do not prevent excessive agency on their own. Logging and monitoring extension and downstream activity, plus rate limits, help you detect and slow harmful actions.

Where does Safeguard fit?

If your agents touch code and dependencies, tool scope matters. Safeguard's MCP server at mcp.safeguard.sh gives agents access to security data, and tenant admins can switch off client types they do not want. Reachability analysis helps an agent separate real risk from noise. You can run Full AI, Zero AI or bring your own model. Scope and approval design still sits with you.

What to do

1. Inventory every tool your agent can call, and delete the ones it does not use.
2. For each tool, write down the downstream permission it holds. Cut it to the minimum.
3. Replace shared service accounts with the requesting user's identity where you can.
4. List the actions that cannot be undone, and put a human approval in front of each.
5. Enforce policy in the downstream system, then test by asking the agent to break it.
6. Turn on logs and rate limits for send, write and delete operations.

Quick check

Sources

• OWASP LLM06:2025 Excessive Agency
• OWASP LLM01 Prompt Injection
• OWASP Top 10 for LLM Applications project

Last reviewed: 18 October 2026.