Excessive agency
Functionality, permissions, autonomy, plus the audit question set for every tool.
The previous module ended with an agent that ran amok in a mailbox with no attacker on the record. That is the subject here. Not how the model gets fooled, but what it is holding when it does.
The definition does the work
Read the last clause twice. It is the reason this entry covers more ground than any other in the standard.
Excessive Agency is the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM, regardless of what is causing the LLM to malfunction.
The entry is written over outputs. Why the output was wrong is out of scope, so a hallucination, an injected instruction and a plain bug all arrive at the same place. OWASP lists the triggers and then stops caring which one fired.
This is good news for a tester. It means the interesting question can be asked without an exploit in hand: if this agent emitted the worst plausible tool call right now, what would happen?
Three root causes
OWASP names them flatly: excessive functionality, excessive permissions, excessive autonomy. Each one is a question about the system that can be answered from a config file.
| Root cause | The question | OWASP's own example |
|---|---|---|
| Functionality | What can the tool do beyond the task? | A tool chosen to read documents from a repository also includes the ability to modify and delete them. |
| Permissions | What may the identity it connects with do? | A tool intended to read data connects with an identity holding UPDATE, INSERT and DELETE as well as SELECT. |
| Autonomy | Who decides a high-impact action happens? | A tool that deletes a user's documents performs deletions without any confirmation from the user. |
Turn the dials
This is OWASP's own worked scenario. An assistant summarises mail, a crafted message tells it to forward the inbox to an attacker, and the standard lists three separate ways to have avoided it. Try each.
The hijacked email assistant
LLM03:2026 Scenario #1A personal assistant summarises incoming mail. One incoming message is crafted to make it scan the inbox for sensitive information and forward that to an attacker address. Turn the dials and watch which ones matter.
Read, send, delete, manage folders. The tool the team already had.
A generic high-privileged identity with access to every user's mailbox. OWASP's excessive-permissions example, verbatim in shape.
The agent sends without confirmation from anyone.
Incident
The assistant scans the mailbox and forwards what it finds to the attacker. Every dial is set to something a real team shipped for a real reason, and no single one of them is a mistake on its own.
Notice what none of the three do. They do not detect the attack, inspect the message, or ask whether the model was fooled. The injected mail lands every time. It stops mattering because the capability it needs is gone.
The sentence that splits the field
OWASP lists nine mitigations for this entry. Between the seventh and the eighth it changes register, and the line it draws is the one this course has been drawing since module 1.7.
The following options will not prevent Excessive Agency but can limit the level of damage caused.
The two options below that line are monitoring and rate limiting. Both are worth having. Neither is a boundary, and the standard says so in advance rather than leaving it to be discovered during an incident.
The same distinction shows up in the scenario you just ran. Three eliminations “could avoid” the outcome. Rate limiting “could reduce” the damage. When a vendor calls a control mitigation, that verb is the thing to check.
The audit, for every tool
Six questions, one pass, no model required. Run them per tool and the answers usually take an afternoon to gather and a long time to defend.
| # | Ask | A bad answer sounds like |
|---|---|---|
| 1 | What is the smallest set of tools this task needs? | "It has the standard toolkit." |
| 2 | Which functions does each tool expose beyond that set? | "We use the vendor's client, so all of them." |
| 3 | Is any tool open-ended, such as run a shell command or fetch a URL? | "Only the shell one, and it's prompted to be careful." |
| 4 | What identity does each tool connect with, and what may that identity do? | "A service account. It's easier than per-user tokens." |
| 5 | Is the action executed in the calling user's context and scope? | "The agent checks the user first." |
| 6 | Which actions are irreversible, and what approves those? | "The user sees a summary before we run the plan." |
Question 5 is the one that catches the most systems, and question 6 is the one people think they have already answered. Module 1.5 covers why approving a plan is not approving an action, and module 3.5 runs question 4 as an actual test.
Bounds blast radius· survives adaptive attack
Sources
- T1OWASP Top 10 for LLM Applications 2026 · LLM03:2026 Excessive Agency. The definition and its 'regardless of what is causing the LLM to malfunction' clause, the three root causes, the six risk examples, the nine mitigations and the prevent-versus-limit-damage split, Scenario #1 and its three eliminations, the sanitization scope note, and the ASI02/ASI03/ASI08 mapping
- ·The six-question audit ordering and the 'bad answer' column are this course's framing