OWASP LLM06 Excessive Agency: what it means and how to audit your agent for it

The short answer

OWASP’s LLM06:2025, Excessive Agency, is “the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM.”¹ The cause of the bad output doesn’t matter: a hallucination, a prompt injection or a plain misunderstanding all count. What matters is that the system let the bad output turn into a damaging action.

OWASP traces it to three causes: excessive functionality (tools the agent doesn’t need), excessive permissions (tools holding more access than the task needs) and excessive autonomy (high-impact actions with no independent check).¹ The fix is to cut each one, which is easier to do with a list in front of you.

The three causes

OWASP’s examples make each cause concrete:¹

Note what’s absent: none of these is about the model being clever or malicious. They’re about what the system around the model permits.

The eight mitigations

OWASP lists these, in this order:¹

1. Minimise extensions. Offer only the tools the agent needs.
2. Minimise extension functionality. Each tool implements only the functions it requires.
3. Avoid open-ended extensions. Prefer a dedicated tool, such as a file writer, over general shell access.
4. Minimise extension permissions. Downstream access at the level needed, enforced by the identity’s permissions.
5. Execute in the user’s context. Act as the specific user with minimum privileges, such as scoped OAuth.
6. Require user approval for high-impact actions.
7. Complete mediation. Enforce authorisation in the downstream systems, not by relying on the LLM to decide.
8. Sanitise LLM inputs and outputs, with secure coding practice and testing.

OWASP adds that logging, monitoring and rate limiting don’t prevent Excessive Agency, but limit the damage.¹

Number 7 is the one teams skip most. “The model knows not to drop tables” is relying on the LLM. A database role that can’t drop tables is mediation.

A worked audit

Here’s a common coding-agent setup, as an .mcp.json plus habits, and how it scores against the eight. It’s a composite, not one real team.

Code Data in JSON, the format software uses to pass records and settings.

{
  "mcpServers": {
    "postgres": { "command": "npx", "args": ["-y", "some-postgres-mcp", "postgres://app_owner:...@prod-db/app"] },
    "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me"] },
    "github": { "command": "npx", "args": ["-y", "some-github-mcp"], "env": { "GITHUB_TOKEN": "ghp_... (all repos)" } },
    "old-search": { "command": "npx", "args": ["-y", "some-search-mcp"] }
  }
}

Habits: the developer clicked “always allow” on SQL queries in week one; the agent also has a shell tool.

Five clear fails out of eight. Each fix is small:

• Delete old-search.
• Root the filesystem server at the project’s src, or mount it read-only.
• Connect Postgres as a read-only role on a branch, not app_owner on production. Our post on what rds_superuser and neon_superuser hand an agent shows how to check a role.
• Use a fine-grained token for the one repository.
• Turn “always allow” off for anything that writes, and require human-in-the-loop approval for it.
• Run the shell in a sandbox, or remove it for this task.

The blast radius of the same agent drops from “production database, every repo, your home directory” to “one branch, one repo, one folder.”

OWASP’s email example

OWASP’s attack scenario is a personal assistant with mailbox access whose extension can also send. A crafted incoming email uses indirect prompt injection to make the agent search the inbox for sensitive information and forward it to the attacker. OWASP’s fixes: an extension that only reads, a read-only OAuth scope, and the user manually sending every drafted email; rate-limiting the send interface reduces the damage.¹

That’s one fix per cause: functionality (no send), permissions (read-only scope), autonomy (a person sends). It’s also the lethal trifecta broken at the outbound leg.

What LLM06 doesn’t ask for

• A smarter model. None of the eight mitigations is “use a better model.”
• Perfect prompt-injection filtering. Mitigation 8 is about secure handling of inputs and outputs, not about catching every malicious instruction.
• Logging instead of controls. OWASP is explicit that logs limit damage and don’t prevent it.¹

To run an audit like the one above on your own machine, paste your MCP config into the check page or run npx deedglass scan (how the grade works), which lists write paths and the first thing to fix; to try rules on tool calls in your browser, open the playground.

Questions people ask

What is LLM06 in the OWASP Top 10 for LLM Applications?

LLM06:2025 is Excessive Agency: damaging actions performed in response to unexpected, ambiguous or manipulated LLM output.¹

What are the causes of Excessive Agency?

Excessive functionality, excessive permissions and excessive autonomy.¹

Does logging fix Excessive Agency?

No. OWASP says logging, monitoring and rate limiting don’t prevent it, though they can limit the damage.¹

Written with AI assistance and checked against our claims register.