Agents and tools
Excessive agency in LLM apps: causes, tests and fixes
Excessive agency lets an LLM app take damaging actions on bad model output. Covers the three root causes, a tool review table, a test method and OWASP's fixes.
Short answer
Excessive agency is the OWASP risk where an LLM-based system can take damaging actions because it has too many functions, too many permissions or too much autonomy. It was LLM06:2025 and is LLM03:2026. Fix it by cutting tools, scoping credentials to the user, mediating each action in code and requiring approval for high-impact steps.
Excessive agency is a risk where an LLM-based system can take damaging actions because it was given too much power. OWASP lists it as LLM06:2025 in the 2025 edition and as LLM03:2026 in the 2026 edition. The fix is to limit what the system can do.
OWASP defines it as 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 cause can be a hallucination, a direct injection from a user, or an indirect injection from a document or tool result.
Which OWASP ID is excessive agency?#
Excessive agency is LLM06:2025 in the 2025 list and LLM03:2026 in the 2026 list. OWASP published the 2026 edition on 4 August 2026. In it, Excessive Agency moved from sixth place to third.
Many pages still cite the 2025 number, and both numbers are correct for their edition. Name the edition in your reports. The OWASP LLM Top 10 guide lists the full set.
The 2026 entry also ties the risk to the agentic list. In agent systems, it says, excessive agency can show up as ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse, and ASI08 Cascading Failures. See the OWASP agentic threats guide.
What are the three root causes?#
OWASP says the root cause is usually excessive functionality, excessive permissions or excessive autonomy, alone or together. Each has its own fix, so review them separately.
| Root cause | Plain meaning | Example from OWASP |
|---|---|---|
| Excessive functionality | The agent can call functions it does not need | A mail-summary tool that can also send and delete mail |
| Excessive permissions | The tool's identity can do more than the task needs | A read tool that connects with an account that also has UPDATE and DELETE |
| Excessive autonomy | High-impact actions run with no independent check | A delete tool that deletes with no confirmation |
A fourth pattern cuts across all three: the tool acts as a shared high-privilege identity instead of as the user. The agent can then reach the files of every user, though the person who asked can reach only their own.
What does a real case look like?#
Invariant Labs published a GitHub MCP disclosure on 26 May 2025. A malicious issue in a public repository steered a user's agent to read from private repositories and write the data into a public pull request. Details from the write-up:
- The setup needed an agent with access to both public and private repos.
- The user's tool confirmations were set to "Always Allow" in the demo.
- The authors state this is "not a flaw in the GitHub MCP server code itself" and that security measures must be applied at the system level.
- The demo used Claude Desktop with Claude 4 Opus. Invariant sells related security tooling, so read its recommendations with that in mind.
The case maps to all three causes. The agent could read private repos for a task about public ones (permissions) and open pull requests in public repos (functionality), and confirmations were off (autonomy). Fixing any one makes the chain harder. Fixing all three shrinks the damage.
How do you review an agent for excessive agency?#
Review each tool the agent can call, one row at a time, and ask what the worst use of that tool would be. Do this before you test prompts.
Tool review table
Fill one row per tool. Use your real tool names. Keep the table in your design record.
| Tool | Needed for which task? | Functions beyond that task | Credential used | Scope of credential | Worst case if called with bad arguments | Approval needed? | Rate limit |
|---|---|---|---|---|---|---|---|
search_docs |
Answer support questions | None | User's session token | Read, own tenant | Reads the user's own docs | No | 30/min |
send_email |
Send a drafted reply | Can send to any address | Shared mailer key | Send as company | Sends data to an outside address | Yes, every send | 5/hour |
fetch_url |
Read a help article | Any URL, any method | Service account | Full network egress | Calls internal hosts, sends data out | Allowlist, GET only | 10/min |
run_sql |
None found | Any query | Admin DB role | Read and write | Drops or reads any table | Remove tool | n/a |
Then score each row:
- If a row has no named task, remove the tool.
- If "functions beyond that task" is not "None", split the tool or wrap it.
- If the credential is shared, move to a per-user credential.
- If the worst case is irreversible or leaves your boundary, require approval or block it.
How do testers prove excessive agency?#
Testers make the agent attempt an action it should not be able to take, using only test accounts and test data. The finding is the observed action. The prompt that caused it is supporting detail.
A tester follows five steps:
- List the tools and their schemas from the app, its config or its traffic.
- Check each tool's identity and scope on the downstream system.
- Try to make the agent call a tool outside the user's task. Use a user message, a planted document and a tool result as separate triggers.
- Try the same call as a second, lower-privilege user to test whether the action respects the user's rights.
- Confirm the effect by reading the changed record from another session.
Controls run beside each attempt: a call with a non-existent target, a call as a user who lacks the right, and a call with approval denied. A control that holds goes in the report too.
Note
Test only systems you have written authorization to test. Use test-owned records for any write or delete.
What are the fixes?#
The fixes come from OWASP's own mitigation list, and the order matters: cut tools first, scope credentials next, then mediate and approve.
| Fix | What to do |
|---|---|
| Minimize tools | Offer only the tools the task needs. Remove trial tools. |
| Minimize functionality | A mail reader should not carry send or delete. |
| Avoid open-ended tools | Replace "run a shell command" or "fetch any URL" with narrow tools that have strict input schemas. |
| Minimize permissions | Give the tool a database role with only the access it needs. |
| Execute in the user's context | Call downstream systems with the user's own OAuth token and the least scope. Keep user context across agent-to-agent calls. |
| Require user approval | Gate high-impact actions in the tool or the downstream system. |
| Complete mediation | Check each request in code, outside the model, against policy. Let low-risk, reversible steps auto-approve and route irreversible ones to a human. |
| Monitor and rate limit | Log tool use. Add circuit breakers. OWASP says these limit damage but do not prevent the problem. |
OWASP notes that input and output sanitization is not a root control for excessive agency. Keep those controls for prompt injection and output handling, but do not rely on them here.
None of these steps removes the risk. They shrink the blast radius, so a model error or an injected instruction can do less. AI agent permissions covers permission design and human approval bypass covers approval design.
How does this fit into an assessment?#
An assessment of excessive agency maps each tool to a root cause, tests the boundary with test accounts, and reports the evidence and a fix for each gap. Excession Labs offers this as part of a scoped AI agent security assessment. We agree the scope in writing and test only with written authorization from the system owner.
Questions
Is excessive agency the same as prompt injection?
No. Prompt injection is one trigger. OWASP says excessive agency enables damaging actions on unexpected, ambiguous or manipulated model output, whatever the cause. A hallucination or a weak prompt can trigger it too.
What is the LLM06:2025 vs LLM03:2026 difference?
It is the same risk under two list editions. The 2025 edition numbers it LLM06:2025. The 2026 edition, published in August 2026, moved it to LLM03:2026. Cite the edition you use.
Does input and output filtering fix excessive agency?
OWASP says sanitizing model inputs and outputs is not a root control for excessive agency. Those controls belong to prompt injection and improper output handling. The root fix is fewer functions, fewer permissions and checked autonomy.
Are read-only agents safe?
Not automatically. A read-only agent can still disclose data across users if its credential sees more than the user should. It also may have a hidden write path through a general tool such as a URL fetcher.
Sources
- OWASP Top 10 for LLM Applications 2026: LLM03 Excessive Agency (OWASP GenAI Security Project, GitHub) (checked 9 November 2026)
- OWASP Top 10 for LLM Applications 2025 (PDF): LLM06:2025 Excessive Agency (checked 9 November 2026)
- OWASP GenAI Security Project: 2026 Top 10 for LLM Applications press release (2 September 2026) (checked 9 November 2026)
- OWASP Top 10 for Agentic Applications (OWASP GenAI blog, 9 December 2025) (checked 9 November 2026)
- Invariant Labs, GitHub MCP exploited: accessing private repositories via MCP (26 May 2025) (checked 9 November 2026)