Excessive agency (OWASP LLM03:2026), explained for agent builders

01What is excessive agency in the OWASP LLM Top 10 2026?

OWASP's GenAI Security Project defines excessive agency as the vulnerability that lets damaging actions be performed when an LLM produces unexpected, ambiguous or manipulated output. It does not matter why the output was wrong. The 2026 entry lists hallucination, a poorly performing or misaligned model, and direct or indirect prompt injection, including injection arriving through compromised tools or peer agents. The weakness is not the bad output; it is that the system let the output act.

The entry names three root causes: excessive functionality, excessive permissions and excessive autonomy. In the 2025 list the same risk was LLM06; the 2026 edition, announced by the project on 1 September 2026, ranks it third, behind prompt injection and sensitive information disclosure. OWASP also distinguishes it from improper output handling, which is about failing to check what a model produces before passing it on.

For agentic systems, the entry points to OWASP's separate Top 10 for Agentic Applications, published in December 2025, where the same failure shows up as ASI02 Tool Misuse, ASI03 Identity and Privilege Abuse, and ASI08 Cascading Failures. If you build agents, read the two lists together: the LLM list names the weakness, and the agentic list names the ways it is exploited.

02What does excessive agency look like in a coding agent?

OWASP's six examples map closely onto coding agents. Excessive functionality: a tool that can write or delete when the task only needs to read, a tool server tried once and left configured, or an open-ended tool such as a shell that runs any command. Excessive permissions: a token with more rights than the tool needs, or a tool that acts for one user through a generic, highly privileged identity. Excessive autonomy: high-impact actions that go ahead without independent verification or a person's confirmation.

Invariant Labs showed how these combine in May 2025. An attacker filed an issue containing a prompt injection in a public GitHub repository. The victim asked an agent, connected through the GitHub MCP server with access to both public and private repositories, to look at open issues. The agent followed the issue's instructions, read data from a private repository and published it in a pull request on the public one. Invariant noted that the tools were fully trusted and that many users choose to always allow tool calls. The fix they proposed is the one OWASP lists: limit the agent to the repositories the task needs.

• Functionality: the agent could read and write across every repository the token covered.
• Permissions: one token covered public and private repositories.
• Autonomy: tool calls were approved once, then ran without review.

03How do OWASP's mitigations map to concrete agent controls?

The 2026 entry lists nine mitigations. Most are design decisions about tools, but four of them become infrastructure once the agent has a shell, because a shell is the open-ended tool OWASP advises avoiding. You cannot list every command an agent might type, so you shrink what any command can reach instead.

Here is the mapping we use. It is not OWASP's wording; it is one way to turn each item into something a machine enforces rather than something a prompt asks for.

• Minimise tools and their functionality: remove unused MCP servers, prefer read-only tools, and give the agent one workspace folder rather than your home directory.
• Avoid open-ended tools: where a shell is unavoidable, run it in a sealed machine whose file system and network are the limit.
• Minimise tool permissions: give the agent its own narrowly scoped token, and keep the real key outside the sandbox so it can only be spent through approved routes.
• Execute tools in the user's context: tie each action to an identity, so the agent cannot act with broader rights than the person who asked.
• Require user approval: hold high-impact actions such as merges, deploys and payments for a named person.
• Complete mediation: enforce the decision in code the agent cannot change, never in the model's judgement.
• Monitor, rate-limit and add circuit breakers: write every action to an audit log, and set spend and rate limits at the provider.

04Why must authorization sit outside the agent?

OWASP's complete-mediation item says authorization should not depend on the LLM deciding whether an action is allowed, and suggests graduated enforcement: audit, warn, block, escalate. The practical reading is about placement. A rule inside the agent's own environment, such as a configuration file in the workspace or a firewall the agent's user can flush, is a suggestion. A prompt injection that can edit files can edit the rule.

So put each check on the far side of a boundary. Network rules belong on the host, not in a container the agent controls. Approval prompts must not be answerable by the agent itself. Credentials should be added after a request leaves the sandbox, so the agent never holds them. The same logic applies to least privilege for agents in multi-agent systems: if three agents share one identity, no log can tell you which one acted, and no policy can treat them differently.

05What can monitoring and rate limits do, and what can they not?

OWASP is careful here: monitoring tool use and rate limiting do not prevent excessive agency. They limit how much damage happens before someone notices, and how fast. That still matters. An agent that loops on a destructive command, or a hijacked agent quietly copying data, does far less harm at ten calls a minute than at a thousand.

Monitoring is only useful if the record can be trusted afterwards. An audit log for agents should record who acted, human or agent, what was attempted, what was allowed or refused and why, and it should be tamper-evident, so an agent with write access to its own machine cannot erase its tracks. Treat these as the last layer, under the controls that reduce what the agent could do in the first place.