Risks
Excessive agency in AI agents
Excessive agency is OWASP LLM03:2026, formerly LLM06:2025: an LLM system can take damaging actions because it has too much functionality, too many permissions or too much autonomy. It is the reason a prompt injection turns into a refund or a deletion. We test it by enumerating every tool and pushing each to its limits.
- OWASP LLM03:2026
- AML.T0053
Formerly LLM06:2025
What is excessive agency?
OWASP's LLM06:2025 Excessive Agency entry describes it as the vulnerability that enables damaging actions in response to unexpected, ambiguous or manipulated model outputs. It names three root causes: excessive functionality, excessive permissions and excessive autonomy. Note that the 2026 edition of the list renumbers this entry to LLM03:2026 Excessive Agency.
The useful framing is that excessive agency is not an attack. It is the blast radius. Prompt injection, a confused model or a hallucinated argument all become harmless if the agent simply cannot do the damaging thing.
How does it show up in agent actions?
- Excessive functionality. A summarizer that can also send. A ticket triage agent that can also close accounts. A generic "run SQL" or "fetch URL" tool where a narrow one would do.
- Excessive permissions. The tool authenticates with an admin key or a shared service account, so it can touch every tenant even when the user can see one.
- Excessive autonomy. High-impact calls run without a confirmation step, so nothing stands between the model's decision and the side effect.
MCP servers are a frequent source. A server is installed for one capability and quietly exposes twenty, and the model can see all of them. MITRE ATLAS models the attacker's side of this as AML.T0053, AI Agent Tool Invocation: using access to an agent to invoke the tools it has.
Illustrative trace
Illustrative example, not a real customer finding.
What do we test for excessive agency?
We start with an inventory: every tool, every argument the model controls, every credential behind it. Then we try to reach each one from the lowest-privileged position we are given, mapped to the classes of an agent security test:
| Root cause | Test | Class |
|---|---|---|
| Functionality | Call tools the task never needs, and open-ended tools with crafted arguments. | Unsafe actions |
| Permissions | Reach other users, tenants or admin operations through the agent's credentials. | Privilege escalation |
| Autonomy | Fire money, delete and send actions with no human confirmation. | Unsafe actions |
| All three | Move data out through any write-capable tool. | Data exfiltration |
How do you mitigate excessive agency?
OWASP's prevention list is concrete: minimize extensions, minimize extension functionality, avoid open-ended extensions, minimize extension permissions, execute extensions in the user's context, require user approval for high-impact actions, apply complete mediation in downstream systems rather than relying on the model, and sanitize LLM inputs and outputs. Logging and rate limiting reduce damage when something slips through.
Our report lists each tool with what it can do today and what the task needs, so the fix is a diff rather than a philosophy.
Which frameworks and integrations are affected?
Tool scope is set in your code, whatever the framework. See the tool and handoff primitives in OpenAI Agents SDK apps and the permission advice in LangChain's own security policy on our LangChain page. For a concrete least-privilege example, Stripe recommends restricted API keys for agents: see Stripe-connected agents.
Agent Action Pentest: $2,500 fixed. Written report within 72 hours of access, or a full refund.
See the offer or email yaz@plaw.io
Questions
Is excessive agency LLM06 or LLM03?
It is LLM03 in the 2026 edition published by OWASP on 2026-08-03, up from LLM06 in the 2025 list. The entry name is unchanged.
Is excessive agency a bug or a design choice?
Usually a design choice that was reasonable at the time. That is why we report it as specific tools and scopes, so you can decide what to remove.
Will you delete real data while testing?
We test in the staging environment or test account you provide, within the scope agreed at intake.
Related pages
- 01Prompt injection in AI agentsInstructions in user input or ingested content override what the agent was told to do.
- 05MCP tool poisoning and MCP server risksMalicious tool definitions or over-scoped MCP servers steer what the agent calls.
- OWASP Top 10 for LLM Applications 2026, mapped to agent testsAll ten 2026 entries mapped to what an agent pentest covers, with a 2025 to 2026 crosswalk.
- AI red teaming vs an agent action pentestBroad AI red teaming compared with a fixed-scope test of agent actions.
- Security testing for LangChain and LangGraph agentsTools, permissions and human-in-the-loop interrupts in LangChain and LangGraph.
- Security testing for AI agents with Stripe accessRefunds, payouts and restricted API keys for agents that touch Stripe.
- Security testing for AI agents in SlackChannel history, message posting and link unfurling for agents installed in Slack.
- Security testing for AI agents with GitHub accessToken type, repository permissions and write paths for agents that touch GitHub.
- Security testing for AI agents with Gmail accessRead, send, modify and filter scopes for agents that work in a Gmail mailbox.
Sources
Last reviewed: