What is excessive agency?

What does OWASP mean by excessive agency?

OWASP defines excessive agency as the vulnerability that lets damaging actions be performed in response to unexpected, ambiguous, or manipulated outputs from an LLM. The moment a model can call tools, query APIs, or write to downstream systems, its mistakes stop being wrong text and start being wrong actions. The risk sits at LLM06 in the OWASP Top 10 for LLM Applications 2025, and it is the entry that most directly concerns agentic AI security teams, because agency is the defining property of an agent.

OWASP breaks the root cause into three forms of excess. All three describe a gap between what the agent can do and what its task actually needs, which is why the risk maps so cleanly onto least privilege thinking from identity security.

• Excessive functionality: the agent has tools or plugins beyond what its job requires, such as a document summarizer that can also send email
• Excessive permissions: the agent's credentials carry broader scopes on downstream systems than necessary, such as write access where read would do
• Excessive autonomy: the agent executes high-impact actions without independent verification or human approval

Why is excessive agency an identity problem?

An agent's agency is delivered through its identity. Every tool call lands on a downstream system as an authenticated request from a non-human identity: an OAuth grant, an API key, a service account, or a purpose-built AI agent identity. The model itself has no power; the credentials attached to it do. Excessive permissions, the second of OWASP's three root causes, is literally an entitlement problem on that identity.

This is where excessive agency intersects with long-standing service account security failures. Teams routinely wire agents up with credentials borrowed from other workloads, standing admin scopes, or broad OAuth app grants because it is faster than scoping access properly. Each shortcut widens the gap between needed and granted access, and that gap is exactly what an attacker who hijacks the agent's reasoning gets to spend.

How does excessive agency get exploited?

The most common trigger is prompt injection: an attacker plants instructions in content the agent will process, such as an email, a web page, or a support ticket, and the model follows them. Excessive agency determines the blast radius. An agent with read-only access to one mailbox leaks one mailbox; an agent with tenant-wide scopes exfiltrates the tenant. The injected agent acting on an attacker's behalf with its own legitimate permissions is a textbook confused deputy problem.

Exploitation does not require an attacker at all. Ambiguous instructions, hallucinated tool arguments, or a poorly specified goal can make an over-permissioned agent delete records, mass-email customers, or modify infrastructure on its own. SailPoint's 2025 survey of IT professionals found that 80% of companies had seen AI agents take unintended actions, including accessing unauthorized systems and sharing restricted data, and 23% had seen agents tricked into revealing credentials. Multi-agent systems raise the stakes further, because delegation chains let one over-privileged agent extend its excess to every agent it invokes.

How do you prevent excessive agency?

OWASP's mitigations are least privilege applied to agents. Minimize the extensions an agent can call, limit each extension to the narrowest useful function, avoid open-ended tools like shell execution, and scope the agent's credentials to the minimum necessary on every downstream system. Where actions are high-impact, require human approval, and enforce authorization in the downstream system itself rather than trusting the model to police its own behavior. For agents that reach tools through Model Context Protocol servers, the same discipline applies to MCP security: each connected server is functionality the agent can be talked into using.

Identity teams can go further than per-agent tool hygiene. Replacing standing credentials with just-in-time access means an agent holds dangerous scopes only for the minutes a task needs them, and zero standing privileges removes the always-on entitlements that make a hijacked agent catastrophic. Running agents inside the end user's own security context, another OWASP recommendation, keeps the agent from becoming a shared high-privilege proxy for many users at once.

• Inventory every agent and the tools, scopes, and credentials it holds
• Scope credentials per agent and per task; never share credentials across agents
• Insert human-in-the-loop approval for destructive or irreversible actions
• Enforce authorization downstream so a manipulated model cannot self-authorize
• Log every tool call with the agent identity that made it, and alert on out-of-pattern actions

Excessive agency vs prompt injection vs sprawl

These risks are related but distinct, and conflating them leads to incomplete fixes. Prompt injection is the manipulation technique; excessive agency is the condition that makes the manipulation damaging. You can reduce injection with input filtering and never fix the blast radius, or you can constrain agency so that even a successful injection accomplishes little. OWASP treats them as separate Top 10 entries for exactly this reason.

AI agent sprawl is the fleet-level version of the same failure: not one agent with too much power, but too many agents nobody inventoried, each carrying its own excess. Sprawl makes excessive agency unmeasurable, because you cannot compare granted access to needed access for agents you do not know exist. AI governance programs typically start with inventory for this reason.

Frequently asked questions

Related terms