OWASP LLM06 excessive agency means an LLM system has more functions, permissions or autonomy than its job needs. It maps cleanly to least privilege in NIST SP 800-53 AC-6, to human oversight in EU AI Act Article 14 for high-risk systems, and to the Govern and Manage work in the NIST AI RMF.
This is a mapping for planning. It is not a legal conclusion, and no framework below certifies a product.
What does OWASP mean by excessive agency?
OWASP describes systems where an LLM can call functions or connect to other systems through extensions, tools or plugins. In agent designs the model can pick which tool to call and loop on its own earlier output. If the model hallucinates or is manipulated by prompt injection, direct or indirect, it can take damaging actions.
It names three root causes:
- Excessive functionality. The agent can reach tools it does not need, such as a read-only document tool that also deletes, or a retired plugin still enabled.
- Excessive permissions. The tool's identity on downstream systems has more rights than necessary, or runs as a generic high-privilege account.
- Excessive autonomy. High-impact actions happen without independent verification or user approval.
OWASP's example is an email assistant whose plugin can also send. A hidden instruction in an incoming message makes the model forward sensitive mail. The fixes are a read-only plugin, a read-only OAuth scope and a human who reviews and sends every draft.
How does it map to least privilege?
Root causes one and two are least privilege problems. NIST SP 800-53 Rev. 5 control AC-6 reads "Employ the principle of least privilege, allowing only authorized accesses for users", and its guidance extends to processes acting on a user's behalf, which describes an agent well. The enhancements include reviewing user privileges and logging the use of privileged functions.
Practical translation: give each tool its own identity, scope it to the one table or mailbox it needs, review those scopes on a schedule, and log calls.
OWASP adds a point that auditors like: complete mediation. Enforce authorization in the downstream system for every request, instead of trusting the LLM to decide whether an action is allowed.
How does it map to human oversight?
Root cause three is the oversight gap. Article 14 of the EU AI Act applies to high-risk AI systems. It expects the people overseeing a system to be able to understand its limits, stay aware of automation bias, interpret output, decide not to use or to override it, and interrupt it through a stop button or similar procedure.
Whether your system is high-risk depends on its use under the Act, so check that first. The page we fetched says Annex III high-risk obligations apply from 2 December 2027 and Annex I systems from 2 August 2028. Treat those dates as the page's statement and confirm them with counsel, since they have moved before.
Even for systems outside the Act, the same expectations make a good design target: an approval step for destructive or external actions, and a kill switch.
How does it map to AI risk frameworks?
The NIST AI Risk Management Framework is organized around four functions, Govern, Map, Measure and Manage, and NIST published a Generative AI Profile, AI 600-1, in July 2024. We did not read the function level text, so here is the loose fit, not a clause mapping:
- Govern: a policy on which actions an agent may take and who approves new tools.
- Map: an inventory of agents, their tools and the systems each tool touches.
- Measure: tests that try to make the agent exceed scope, and logs that show attempts.
- Manage: removal of unneeded tools, rate limits and incident procedures.
Log monitoring and rate limiting, in OWASP's words, do not prevent the problem but limit damage and speed detection.
Where do code controls come in?
OWASP recommends secure coding for tools, including strong input sanitization, with SAST and DAST in pipelines. Safeguard offers SAST and DAST scanners, and an MCP server whose tool calls are unlimited on every plan. If you expose tools to agents, that is exactly where to apply scope limits and approvals.
What to do
- List every tool each agent can call. Delete the ones it does not need.
- Replace open-ended tools such as shell or URL fetch with narrow ones.
- Give each tool a separate identity with the lowest scope, and run user actions in the user's context.
- Require human approval for deletes, payments, external sends and permission changes.
- Enforce authorization in the downstream system, not in the prompt.
- Log tool calls and rate limit them.
- Write down the mapping above in your risk register and review it each quarter.
Quick check
Is a prompt instruction enough to limit an agent?
No. OWASP says to enforce authorization in downstream systems and limit tool permissions, since a manipulated model can ignore instructions.
Which framework control is closest to LLM06?
NIST SP 800-53 AC-6 least privilege for permissions, and EU AI Act Article 14 human oversight for autonomy, where the Act applies.
Sources
- OWASP LLM06:2025 Excessive Agency
- NIST SP 800-53 AC-6 (csf.tools reference)
- EU AI Act Article 14, Human Oversight
- NIST AI Risk Management Framework
Last reviewed: 18 October 2026.
