What is excessive agency?
Excessive agency is the structural condition in which an AI agent has more capability than its authority warrants. The agent can do more, write more, send more, spend more than the situation requires. When something goes wrong: a jailbreak, a hallucinated tool call, a poisoned MCP description: the blast radius is set by how much agency was granted, not by how much the attack needed.
Key facts
- Formalized as OWASP LLM06 in the Top 10 for LLM Applications.
- Teams running production agents carry some excessive agency. The question is how much.
- Without controls, ordinary agent errors become production incidents: destructive writes, supply-chain tool compromise, and data exposure often share the same missing boundary.
- Veto reduces agency three ways: scoped tools, per-argument policy, and pre-action approval queues.
In plain English
Capability is what an agent can do: the tools you wired up. Authority is what it should do: the actions you'd happily defend in a postmortem. Excessive agency is the gap between the two. A support agent that has write access to the billing table has the capability to issue refunds of any size. The authority to issue refunds of any size belongs to a senior engineer during business hours.
The gap matters because agents do not know they have it. They can use whatever tool appears most useful matches the request they think they have, with whatever arguments they generate. If the tool set includes a sharp edge and the prompt sends them toward it, they can use the sharp edge. Closing excessive agency means taking the sharp edges off, or putting them behind a person.
How it works
Reduction happens in three layers. First, prune the tool list. If a tool is not strictly required for the agent's purpose, do not wire it up. Second, narrow each remaining tool. A refund tool that can refund up to $50,000 should be capped at $500 for an autonomous agent and require approval above that. Third, install a pre-action approval queue for the high-impact tools you cannot or will not cap.
Veto can express those constraints as policy. The tool set is whatever your codebase exposes; the argument constraints live in YAML; the approval queue is a hosted review path plus a configured approval channel. Each governed decision is recorded with the rule that fired, so when an auditor asks "show me the agent's actual authority", the policy file is the answer.
# YAML: shrinking an agent's effective agency
- name: refund_caps_and_approvals
match:
tool: refund_order
rules:
- if: args.amount_cents <= 50000
then: allow
- if: args.amount_cents > 50000
then: require_approval
- name: no_destructive_sql
match:
tool: run_sql
rules:
- if: args.query =~ /drop|truncate|delete from/i
then: denyOperational consequence
The textbook failure mode is an agent with write access to production during a freeze. Whether the precipitating cause is hallucination, prompt misinterpretation, or context drift does not change the structural lesson: if the agent has the capability to destroy production, the policy boundary has to stop that capability before execution. The fix is not at the model layer. It is at the authority boundary.
Compliance regimes have caught up. EU AI Act Article 14 requires human oversight for high-risk systems. NIST AI RMF's MANAGE function expects controls that bound the consequences of AI errors. Both are excessive-agency mitigations in regulator-speak. Closing the gap is how you produce the evidence those frameworks want.
Related terms
FAQ
Is excessive agency the same as over-permissioning?⌄
Over-permissioning is the most common form. Excessive agency is broader: it includes too many tools, too many permissions per tool, and too much autonomy to act without approval. Trim any of the three and the agent becomes safer.
How is this different from least privilege?⌄
Least privilege is the principle. Excessive agency is the failure mode that happens when you do not follow it. Closing excessive agency is least privilege applied to an LLM-based system, where the agent's capabilities are defined by the tools you wire up.
Where does this typically come from?⌄
Two places. First, MVP scope: teams wire up more tools than the agent needs and fail to prune. Second, framework defaults: some agent frameworks make broad tool sets the default. Both create excessive agency by accident.
What is the cleanest fix?⌄
Add a policy decision point at the tool boundary and start by denying the actions you cannot afford an agent to take in any situation. That alone removes the worst cases. From there, narrow each tool's allowed arguments and add approval gates for high-impact actions.
Bring your agent's capability back to its authority.