L3.4.1 — Excessive agency: when tools are too broad

Type: Theory · Duration: ~5 min · Status: Mandatory Module: Module 3 — Prompt Injection & LLM Application Attacks Framework tags: OWASP LLM08 (Excessive Agency) · MITRE ATLAS AML.T0048

Learning objectives

1. Define "excessive agency" and identify its three sub-classes (functions, permissions, autonomy).
2. Recognize the principle-of-least-authority pattern as it applies to LLM tool definitions.

Core content

Definition

Excessive agency is the condition in which an LLM-based system has been granted more authority — in functions, permissions, or autonomy — than it needs to perform its intended task. The grant is independent of whether the system has been compromised. The vulnerability is the grant, not its exploitation.

When prompt injection succeeds against an agent with excessive agency, the attacker doesn't gain new authority; they inherit the agency already granted. The defense is to never grant the excess in the first place.

OWASP LLM08 names three sub-classes.

The three sub-classes

1. Excessive functions. The agent is exposed to tools/functions it doesn't need for its intended purpose. A customer-service chatbot with a send_email tool when it never needed to send email. A research agent with a delete_file tool when it only needed to read. - Test: enumerate the agent's tool list. For each, can you state the intended use case that requires this tool? If no, it's excess.

2. Excessive permissions. The agent has tools whose authority scope is broader than needed. A send_email tool that can email any address when it only needs to email the user's own. A database_query tool with SELECT/INSERT/UPDATE/DELETE when SELECT alone would suffice. - Test: for each tool, can you state the narrowest scope that satisfies the use case? If the current scope is broader, it's excess.

3. Excessive autonomy. The agent can complete impactful actions without human review when the action's impact warrants confirmation. A refund-issuing agent that processes refunds with no human approval. An email-drafting agent that auto-sends instead of presenting drafts. - Test: for each action, is the impact reversible? If not, or if the impact crosses a stakeholder-set threshold, autonomy is excess.

The principle of least authority (POLA) for LLM tools

Three rules, applied to every tool definition:

1. Narrow the tool surface. Only expose tools the use case demands. Audit annually; remove unused tools.
2. Narrow each tool's scope. Each tool's arguments should be the narrowest the use case permits. Parameter allow-lists, recipient restrictions, table-level filters.
3. Require confirmation for impact. Any action above a stakeholder-set threshold (dollar amount, external send, irreversible operation) requires explicit user confirmation before execution.

POLA is not a new idea — it's classical security wisdom (Saltzer & Schroeder 1975). The LLM-specific twist: the enforcer of "least authority" historically was deterministic code, easily testable. With agents, the user of the authority is probabilistic. Authorization unit tests don't catch all cases. POLA is the most reliable defense because it shrinks the attack surface regardless of which payload lands.

Where POLA tension lives

Product teams resist POLA because narrow tools feel limiting to the user. "Let the model email anyone — the user might want to email anyone!" The right move: ship POLA-by-default, then expand based on observed need + stakeholder buy-in for the expanded threat model. Default-open expands the threat model invisibly; default-closed makes expansion a deliberate, documented decision.

Real-world example

The Air Canada chatbot (Module 2 reference) is excessive autonomy — the chatbot's statements were treated as binding commitments by the company without human review. The technical-side mitigation would have been: any chatbot statement that creates a customer commitment routes through human approval before becoming binding. The chatbot has authority to answer; it should not have had autonomy to commit. This is excessive-autonomy with a $$ price tag.

Key terms

• Excessive functions — too many tools exposed.
• Excessive permissions — too broad authority per tool.
• Excessive autonomy — too few human checkpoints.
• POLA (Principle of Least Authority) — the foundational defense.

References

• OWASP LLM08 page.
• Saltzer & Schroeder, "The Protection of Information in Computer Systems" (1975) — the POLA origin.
• Simon Willison's writing on "tools and agents" for the LLM-specific framing.

Quiz items

1. Q: Name the three sub-classes of excessive agency. A: Excessive functions, excessive permissions, excessive autonomy.
2. Q: An LLM agent has a query_database tool that allows SELECT, INSERT, UPDATE, DELETE on every table. The use case only ever requires SELECT on three named tables. Which sub-class of excessive agency? A: Excessive permissions — scope is broader than needed.
3. Q: Why is "default-open then narrow" a worse engineering posture than "POLA by default then expand"? A: Default-open expands the threat model invisibly; default-closed makes expansion a deliberate documented decision.

Video script (~600 words, ~4.5 min)

[SLIDE 1 — Title]

Excessive agency. When tools are too broad. Five minutes. By the end you'll know the three sub-classes and how POLA applies to LLM tool design.

[SLIDE 2 — Definition]

Excessive agency is the condition in which an LLM-based system has been granted more authority — in functions, permissions, or autonomy — than it needs to perform its intended task. The grant is independent of whether the system has been compromised. The vulnerability is the grant. Not its exploitation.

When prompt injection succeeds against an agent with excessive agency, the attacker doesn't gain new authority. They inherit the agency already granted. The defense is to never grant the excess in the first place.

[SLIDE 3 — Three sub-classes]

OWASP LLM08 names three sub-classes. One: excessive functions. The agent is exposed to tools it doesn't need. A customer-service chatbot with a send-email tool when it never needed to send email. A research agent with a delete-file tool when it only needed to read. Two: excessive permissions. The agent has tools whose scope is broader than needed. A send-email tool that can email any address when it only needs to email the user's own. A database-query tool with SELECT, INSERT, UPDATE, DELETE when SELECT alone would suffice. Three: excessive autonomy. The agent can complete impactful actions without human review when the action's impact warrants confirmation. A refund-issuing agent that processes refunds with no human approval. An email-drafting agent that auto-sends instead of presenting drafts.

[SLIDE 4 — POLA applied to LLM tools]

Principle of least authority — POLA — applied to LLM tools. Three rules for every tool definition. One: narrow the tool surface. Only expose tools the use case demands. Audit annually. Remove unused. Two: narrow each tool's scope. Each tool's arguments should be the narrowest the use case permits. Parameter allow-lists. Recipient restrictions. Table-level filters. Three: require confirmation for impact. Any action above a stakeholder-set threshold — dollar amount, external send, irreversible operation — requires explicit user confirmation before execution.

[SLIDE 5 — Why POLA is special for LLMs]

Why POLA is the right framing for LLMs. POLA is classical — Saltzer and Schroeder, 1975. The LLM-specific twist: the enforcer of "least authority" historically was deterministic code. Easily testable. With agents, the user of the authority is probabilistic. Authorization unit tests don't catch all cases. POLA is the most reliable defense because it shrinks the attack surface regardless of which payload lands.

[SLIDE 6 — Where POLA tension lives]

Where POLA tension lives. Product teams resist POLA because narrow tools feel limiting to the user. "Let the model email anyone — the user might want to email anyone." The right move: ship POLA by default, then expand based on observed need plus stakeholder buy-in for the expanded threat model. Default-open expands the threat model invisibly. Default-closed makes expansion a deliberate documented decision.

[SLIDE 7 — Air Canada as excessive autonomy]

Air Canada is excessive autonomy with a price tag. The chatbot's statements were treated as binding commitments without human review. Technical mitigation: any chatbot statement that creates a customer commitment routes through human approval before becoming binding. The chatbot has authority to answer. It should not have had autonomy to commit.

[SLIDE 8 — Up next]

Next lesson: agent escape patterns and tool-call defenses. Concrete attack techniques and concrete defenses. See you there.

Slide outline

1. Title — "Excessive agency: when tools are too broad".
2. Definition — agent diagram with too-broad tool surface highlighted in red.
3. Three sub-classes — three cards: Functions · Permissions · Autonomy, with concrete bad/good examples for each.
4. POLA three rules — numbered list with brief examples.
5. Why POLA for LLMs — historical (Saltzer & Schroeder) timeline + modern adaptation.
6. Tension — pull-quote: "Default-open expands the threat model invisibly; default-closed makes expansion deliberate."
7. Air Canada — incident card with "excessive autonomy" tag.
8. Up next — "L3.4.2 — Agent escape patterns and defenses, ~5 min."

Production notes

• Recording: ~4.5 min. Cap 5.
• Slide 3 is the most-referenced; concrete bad/good examples make the difference between abstract and operational.