Reading "Excessive Agency" carefully

OWASP's Top 10 for LLM Applications shipped in 2023 and went through a revision in 2025. One entry that gets cited a lot — and misread almost as often — is LLM06: Excessive Agency (spec).

The label "excessive agency" makes it sound like a philosophical problem about AI autonomy. It isn't. Read the spec and the diagnosis is concrete and engineering-shaped. Three things, in order, are the actual problem.

1. Excessive functionality

The agent has access to tools it doesn't need. The canonical example in the spec is a coding agent given a third-party extension that includes the ability to delete files when the use case is "read files." Most agent runtimes inherit whatever the underlying API surface offers. If the SDK gives you db.query and db.execute, the agent gets both — even if your prompt template only invokes the first.

This isn't a model problem. It's a tool-binding problem. The fix is the boring one: at agent-construction time, narrow the toolset to exactly what the task needs. If your runtime makes this hard, that's a runtime bug.

2. Excessive permissions

The tool itself has more backend privilege than the agent's task requires. A "read documents from Drive" tool that's wired up with a drive.readwrite scope. A database client whose connection string has DDL rights. The agent never asks to write — until it does.

This is the most consequential of the three because it determines what happens when something else fails. If the model hallucinates a destructive call, or the tool description is prompt-injected, or a peer agent in a multi-agent system goes off-script, the permission floor of the credential is what's left between the bad call and the bad outcome.

3. Excessive autonomy

The agent acts without a confirmation step on actions that have side effects you can't undo. Send-email tools. Issue-creation tools. Transfer-money tools. The spec's recommendation here is human-in-the-loop for high-impact actions — and to make the loop opt-out, not opt-in.

A common pattern: the agent stages the action in a queue, an operator reviews it, the action ships only on approval. This adds latency. The argument for accepting that latency is the inverse of "move fast and break things": when "the thing" is your customer database, you slow down.

Why this taxonomy is useful

These three categories don't overlap. Each maps to a different mitigation:

• Functionality → narrow tool surface at composition time.
• Permissions → narrow credentials at the boundary the tool calls through.
• Autonomy → gate side-effectful actions on operator review.

When teams discuss "agent safety," they often blur all three. The fix-list looks different depending on which one is biting you.

What the spec doesn't tell you

The spec is good at naming the problem. It's intentionally light on prescription. A few things worth knowing on top of it:

• The OAuth ecosystem has a partial answer to the permissions problem: short-lived, scoped, exchanged tokens via RFC 8693. It's only a partial answer because OAuth was designed for users granting apps access, not for agents being granted bounded delegation by users.
• The MCP authorization spec (2025-06-18) takes a position on how MCP servers should advertise auth requirements. It's a useful read for anyone shipping MCP integrations.
• The "human-in-the-loop" prescription is a workflow problem disguised as a security problem. Tools like Slack, PagerDuty, and your existing approval queues have more thinking on this than the security literature does.

The Top 10 is a starting point. The taxonomy is what makes it durable: separate the three failure modes and fix them on their own terms.