Glossary entry

What is OWASP LLM06: Excessive Agency?

OWASP LLM06 is the Top-10 risk for LLM applications covering systems that have more functionality, more permissions, or more autonomy than the application's intended use needs. It is the structural condition that turns prompt injection or hallucination into an incident worth writing up.

  • Listed as LLM06 in the OWASP Top 10 for LLM Applications.
  • Covers three dimensions: excessive functionality (tools that are not needed), excessive permissions (tools with too much access), excessive autonomy (no human in the loop).
  • Without mitigation, agent failure modes such as jailbreaks, hallucinations, and indirect injection can escalate from inconvenience to incident.
  • Veto addresses those dimensions with scoped tools, fine-grained policy, and pre-action approval queues.

In plain English

If you give an agent a hammer when it only needs a screwdriver, eventually it can swing the hammer. OWASP LLM06 is the formal name for that mistake. The fix is not to make the agent better at deciding when to swing: it is to take the hammer away, or to put it behind a lock that only opens when a human turns the key.

Excessive agency shows up three ways. Excessive functionality: the agent has tools nobody needed (a customer-support agent with database write access). Excessive permissions: the tools it does need have too much scope (a refund tool that can refund any amount). Excessive autonomy: the agent acts on side-effecting decisions without a human in the loop. The risk grows multiplicatively. Cut any one and the others matter less.

How it works

OWASP's official guidance is specific. For functionality: remove tools that are not needed for the application's purpose. For permissions: grant each tool the narrowest scope it can operate with. For autonomy: require human approval for actions whose impact exceeds what you'd let a junior employee do without sign-off. Keep decision records for governed actions. Rate-limit.

In a Veto stack, these translate directly to policy. The tool list is curated. Each tool has a policy block. Review-required actions route to a human approval queue. Each governed decision is recorded with the request envelope. Decision records map LLM06 mitigations to evidence a compliance team can point at.

# YAML: LLM06 mitigations expressed as policy
- name: limit_db_writes_to_specific_tables
  match:
    tool: db.write
  rules:
    - if: args.table not in ["tickets", "notes"]
      then: deny
- name: high_impact_actions_require_approval
  match:
    tool: refund_order
  rules:
    - if: args.amount_cents > 50000
      then: require_approval

Operational consequence

LLM06 is the risk pattern behind many public incidents: excessive permissions plus excessive autonomy. Destructive database writes, shell execution, and poisoned tool definitions all share that shape. None of these incidents required exotic attacks; they required a moment of agent error to land on a tool that should not have been there.

Compliance regimes are converging on LLM06 as the actionable risk for AI. EU AI Act Article 14 mandates human oversight for high-risk systems. That is excessive-autonomy mitigation in regulatory language. ISO/IEC 42001 expects organizations to scope and document the capabilities of AI systems. Tackling LLM06 produces evidence those frameworks ask for.

Related terms

FAQ

What does OWASP mean by 'agency' here?

The combination of functionality the agent can invoke (its tools), permissions those tools are granted, and the degree of autonomy the agent has when deciding to use them. LLM06 covers all three.

How is LLM06 different from LLM01 prompt injection?

LLM01 is the attack: someone gets the model to follow instructions it should not. LLM06 is the structural condition that makes the attack consequential: the agent has too much capability, so the attack does too much damage. LLM01 is what happens; LLM06 is why it matters.

What are the official OWASP mitigations?

Limit the tools to the minimum set required. Limit each tool's permissions to the minimum. Require human approval for high-impact actions. Keep decision records for governed actions. Apply rate limits. The Veto runtime checks each tool call against policy and gates sensitive ones with a human approval queue: covering the first four directly.

Where does LLM06 show up in real incidents?

Most agent incidents map to LLM06. The agent has write, shell, browser, or data-export capability it does not need for the task, then a prompt or context drift turns capability into side effect. Reduce the agency, reduce the blast radius.

Mitigate LLM06 with policy and approvals.