Give a model the means to act and it stops being a text generator. Anything it can call, whether the vendor labels it a tool, an extension, a plugin or a skill, is a lever attached to a real system. Which lever gets pulled is frequently the model’s own decision, taken from the prompt in front of it or from what it produced a moment ago, and agentic systems repeat that decision many times, each round shaped by the output of the last.
The vulnerability is what those levers do when the output driving them is wrong. The cause of the wrongness does not matter, and that is the entire point of this category. A hallucination on a badly phrased but entirely innocent prompt reaches the same tool, with the same permissions, as a deliberate injection. Defences aimed at keeping the model correct are therefore beside the point here. What matters is the blast radius when it is not.
Common triggers named by the source are:
- hallucination, which needs no attacker at all: a clumsily worded question, or simply a weak poorly performing or misaligned model;
- direct or indirect prompt injection, from a malicious user, from an earlier invocation of a malicious or compromised tool, or, in multi-agent and collaborative systems, from a malicious or compromised peer agent.
Because a benign trigger is enough, treating this as a subcategory of injection defence is a mistake. A model that hallucinates a delete call against a production table causes the same incident as one that was instructed to.
Three root causes
The source reduces the entry to three root causes, and they map cleanly onto three different teams’ work. Nearly every finding in a real agent review lands in one of them.
| Root cause | The question it answers | Where it is fixed |
|---|---|---|
| Excessive functionality | What can the tool do at all? | Tool surface and schema design |
| Excessive permissions | What is the tool’s identity allowed to do downstream? | IAM, database grants, OAuth scopes |
| Excessive autonomy | What can happen without a human, or without a policy check? | Workflow and approval design |
Impacts run across the full confidentiality, integrity, and availability spectrum, and depend entirely on which systems the application can reach. Within agentic systems, Excessive Agency manifests as ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse, and ASI08 Cascading Failures in the OWASP Top 10 for Agentic Applications.
What this entry is not. Improper Output Handling is a different problem: it asks whether output is examined closely enough before something consumes it. Sanitising model inputs and outputs is not a root control here: inputs are covered by LLM01:2026 Prompt Injection and outputs by LLM10:2026 Improper Output Handling. If your remediation plan for an agency finding is a better filter, you have not addressed the finding.
How it arises
Excessive functionality
The agent has access to tools containing functions that the intended operation does not need. The canonical case: a developer needs the agent to read documents from a repository, and the off-the-shelf third-party tool they select also exposes modify and delete. Nobody chose to grant deletion; it came bundled.
A second, quieter case is abandoned surface. A tool trialled during development and dropped in favour of a better alternative remains registered and callable by the agent. It is not in the design document, it is not in the tests, and it is still in the tool list the model sees.
The third is open-ended tools that do not constrain their own input. A tool intended to run one specific shell command that fails to prevent other shell commands from executing has, in practice, granted shell access.
Excessive permissions
Two distinct failures.
The first is a tool holding permissions on downstream systems beyond what the application needs:
a read-only feature connecting to the database with an identity that has UPDATE, INSERT, and
DELETE alongside SELECT. The application never issues those statements. The credential permits
them, so a manipulated or confused agent can.
The second is identity collapse. A tool meant to act for one person reaches the system behind it as a single powerful account shared by everybody. A document-reading tool that connects with credentials able to open every user’s files is the ordinary shape of this. Authorisation then depends entirely on the model correctly limiting itself to the right user’s documents, which is not an authorisation control.
Excessive autonomy
Nothing outside the model checks an action before it happens, however consequential it is. Deletion is the clearest case: a tool that removes documents and asks nobody first. “Independently” is doing work in that sentence: verification performed by the same model that chose the action is not independent.
Mitigations
The source separates controls that prevent Excessive Agency from controls that only limit the damage. Keep the distinction, because the second group is often deployed in place of the first.
Controls that prevent it
1. Minimise tools. Strip the agent’s toolset to exactly what the task requires and nothing more. A URL-fetching capability that no workflow uses is not dormant; it is reachable. Audit registered tools periodically and remove anything experimental or retired.
2. Minimise tool functionality. Each tool should expose only the operations the application actually exercises. An email-summary tool needs read access to messages; if the underlying API also exposes delete and send, wrap it in a facade that hides those operations. Accepting a vendor’s full-surface SDK because wrapping it takes effort is the usual way this control fails.
3. Avoid open-ended tools. A “run shell command” tool turns every shell binary into an available action. If the goal is writing output to a file, build a tool that writes to one defined path with validated content, not one that can execute arbitrary commands. Every tool should define a strict input schema and reject anything outside it before execution.
4. Minimise tool permissions. The identity a tool uses to reach a downstream system should
carry only the privileges that tool’s operations require. A product-recommendation agent needs
SELECT on the catalogue table, not a connection string with write access to the order table
next to it. Enforce this through the downstream system’s own access controls, such as database
roles or API scopes, never through prompt instructions that tell the model what not to do.
5. Execute tools in the user’s context. Every downstream call should run under the identity of the person who initiated it, not a shared service account. If the tool reads a repository, the user should have authenticated through OAuth with a scope limited to that operation. In delegated or multi-agent workflows, preserve the original user context and authorisation scope across chained tool and agent calls rather than relying on the permissions of the calling agent or service identity. This is the control most commonly lost the moment a second agent is introduced.
6. Require user approval. Put a person in front of consequential actions. The check can live in
the downstream system, in the tool, or somewhere else entirely outside the application; what matters
is where it sits relative to the action. Something that publishes on a user’s behalf needs its
approval step inside the post operation itself, not earlier in the conversation, because anything
before the model runs can be argued past by the model.
7. Complete mediation. Authorisation decisions belong in deterministic code, not in a model’s output. Every call to a downstream system should pass through a policy enforcement point that evaluates it against defined rules: either in the tool itself, in a dedicated pre-execution the tool and the downstream system, or by the downstream system itself. Policy at that point can also handle the case where a nominally permitted action is contextually unsafe.
The source recommends a graduated enforcement policy (audit, warn, block, escalate) so that low-consequence or easily reversible actions auto-approve while high-consequence or irreversible ones route to human review. Their example: a customer-service chatbot can auto-process a refund as store credit, because store credit is recoverable, while an irreversible external payout goes to human approval. Reversibility, not monetary value, is the axis that matters.
Controls that only limit the damage
These will not prevent Excessive Agency. Deploy them, but do not count them as the control.
8. Monitor tool use. Log and monitor the activity of tools and downstream systems to identify undesirable actions, and respond. This is the diagnostic: if you cannot reconstruct which tool call was made with which arguments under which identity, you cannot investigate an agent incident at all.
9. Rate limiting. Establish thresholds around tool invocation and implement circuit breakers that halt, rate-limit, or escalate for human review when thresholds are exceeded. Simple thresholds count invocations; context-aware thresholds track the cumulative value of an input parameter: total refund amount across a session, for example, and not per-call amount.
Attack scenario: the hijacked email assistant
The source gives one worked scenario, and it is worth following in full because it shows all three root causes producing a single incident.
An assistant summarises somebody’s email. Summarising needs nothing but read access, yet the integration the developer reached for also sends mail, and that capability was never removed. The same assistant is exposed to indirect prompt injection. So an attacker writes to the mailbox, the instructions inside that message are read as though the user had typed them, and the assistant searches the inbox for anything sensitive and posts it back out to an address of the attacker’s choosing.
Any one of three independent fixes would have prevented it:
| Root cause | Fix |
|---|---|
| Excessive functionality | Use a tool that implements mail reading only |
| Excessive permissions | Authenticate to the mail service via an OAuth session with read-only scope |
| Excessive autonomy | Require the user to review and press send on every message the tool drafts |
Alternatively, the damage could be reduced - not prevented - by rate limiting the mail-sending interface.
Note what is absent from that list: a better prompt-injection filter. The injection is the trigger; the send capability, the write-scoped token, and the unattended send are the vulnerability.
Related entries
- Prompt Injection (LLM01:2026) - the most common trigger, and the entry that owns input-side controls. Excessive Agency is what gives an injection consequences outside the chat window.
- Sensitive Information Disclosure (LLM02:2026) - identity collapse and over-broad retrieval scope are how an agent reaches data it should not.
- Supply Chain (LLM04:2026) - a compromised tool package is one of the named triggers; agentic supply-chain risk, including MCP servers and tool registries, sits under ASI04.
- LLM10:2026 Improper Output Handling - the adjacent entry this one is frequently confused with.
- More entries: AI Security.