Lately, a topic many security practitioners are discussing is Excessive Agency. From Black Hat and DEF CON to local ISC2 audiences, one question keeps coming up: What happens when an AI agent has more ability to act than its job actually requires?
That is the problem the Open Worldwide Application Security Project (OWASP) calls Excessive Agency. An agent may have access to more data than it needs, more tools than it needs, or more freedom to act without oversight than the task justifies. Any one of those can turn a bad model decision, a compromised workflow, or a prompt injection into something much more consequential.
Excessive Agency is not a brand-new risk. OWASP first introduced it in the 2023-24 LLM Top 10 as LLM08. It moved to sixth in 2025 (LLM06), and in the 2026 GenAI LLM Top 10 it climbed again to third (LLM03). The ranking has risen alongside the capability itself. AI systems are no longer limited to generating an answer. Increasingly, agents can call tools, interact with APIs, run commands, and take actions in other systems.
Reducing that risk requires more than one familiar security principle. Least privilege still matters because it limits what an agent can reach. But agents introduce another question: Once that access is legitimate, how much autonomy should the software have to use it?
That is where least agency comes in.
Least privilege and least agency are complements, not synonyms. The first constrains reach; the second applies the same minimum-necessary logic to autonomy. Together, they address different causes of the broader Excessive Agency problem.
What is Excessive Agency?
OWASP defines Excessive Agency as the damage that becomes possible when an agent acts on the output of a malfunctioning or manipulated model because it was granted more capability than its task required. The trigger can be almost anything: a hallucination, an ambiguous instruction, a poorly written prompt, or an intentional prompt injection. The common thread is that the agent was in a position to do harm in the first place.
This breaks the problem into three root causes, each representing a different way capability can exceed the task:
- Excessive functionality: The agent can invoke tools or actions its task never needed. A plugin added to read documents also happens to be able to modify or delete them. A tool that was trialed and abandoned is still reachable.
- Excessive permissions: The identity the agent runs under can reach data or systems beyond the task. A component that only needs to read connects with a database account that can also update, insert, and delete.
- Excessive autonomy: The agent can take high-impact actions with no human checkpoint, so a single bad decision executes without anyone in the loop.
OWASP then illustrates the problem with a familiar example. An email assistant intended to summarize incoming messages is given functionality that also allows it to send mail. Once untrusted email content can influence the model, that unnecessary capability can turn a summarizer into an agent acting on an attacker's behalf.
It is easy to see how that happens in practice. To read mail, you grant the assistant a mail integration. The off-the-shelf connector does not come in a read-only flavor, so it arrives with send included.
Nobody wanted a summarizer that can send mail, but that is what the integration package delivered, and trimming it is extra work a shipping team tends to skip. The risk emerges from ordinary, reasonable implementation decisions rather than obviously careless ones.
Dangers of Excessive Agency
The property that makes an agent useful, the ability to act on its own, is the same property that sets the blast radius when it is wrong, manipulated, or compromised. Traditional software runs predefined logic. An agent is nondeterministic. It interprets a goal, chooses tools, and takes multi-step actions, which means an attacker who can influence the input can influence the actions.
This is also why input filtering alone does not solve it. You can invest heavily in detecting malicious prompts and still be left with the question that matters after the agent is already running: what access and ability to act does it retain when it is manipulated, compromised, or simply wrong? Reducing the blast radius before something goes wrong is more reliable than trying to catch every bad input.
What is least agency?
OWASP's Agentic Security Initiative uses the term least agency to describe the discipline of avoiding unnecessary autonomy, particularly where agentic behavior adds no value. In practice, that means constraining what an agent can invoke, under what conditions, and which actions can occur without oversight.
Anthropic's Zero Trust for AI Agents guide, published in May 2026, explicitly incorporates least agency into its security framework and draws the same practical distinction this post does: Access alone does not define the safe operating boundary for an autonomous agent.
The guide describes least agency in terms of what each agent tool can do, how often, and where, with concrete examples such as a database tool limited to read-only queries, an email summarizer with no send or delete rights, and an API restricted to minimal operations. OWASP gives us the taxonomy and the definition. A frontier-model vendor independently operationalizing the same principle in enterprise agent security shows this is where the field is going, not a distinction any single vendor invented.
Now keep the same capability but change the premise. Earlier, send was a functionality the summarizer never needed. This time, suppose an agent whose job genuinely does require it.
The cleanest way to feel the difference is a single scope. An agent granted email-send permission is authorized to send your meeting notes. With that exact same permission, it can also email every contact in your address book a different message.
Least privilege looks at that and says both are fine, because the agent holds email-send. Least agency takes a different approach: The second action takes a level of autonomy the task never intended, so it should require different handling.
Least agency vs. least privilege
Least privilege and least agency are complementary controls, not substitutes. One constrains access. The other constrains the freedom to act within it.
The easiest way to keep them straight is to think of two control axes. Least privilege constrains reach: what data, systems, APIs, and resources the agent can access. Least agency constrains unnecessary autonomy: how freely the agent can act, invoke capabilities, or take consequential actions without checking back.
Excessive Agency is the broader failure state that emerges when functionality, permissions, or autonomy exceed what the task requires.
Least privilege most directly addresses the excessive permissions root cause. By itself, it does not guarantee a minimal toolset or an appropriate level of autonomy, which is why it remains necessary but is no longer sufficient for agents. Least agency fills that gap by constraining how freely an agent can act with the access it legitimately holds.
Excessive agency vs. a constrained agent under attack
Take that email example one step further. We recently built and demonstrated the following scenario using ThreatLocker to enforce the boundaries around the agent.
Instead of a summarizer with one unnecessary capability, imagine an email triage assistant that also processes attachments and has several ways to act beyond its intended job. One attachment carries a hidden instruction that tries to make the agent read a file outside its working directory, launch an unapproved helper to package that data, and send the package to an external endpoint.
Here is how that plays out against an over-agentic agent and against one constrained by both least privilege and least agency.
There are two things worth calling out. First, the out-of-scope read is stopped by least privilege, not least agency. The unapproved-tool step and the egress step are where agency and reach constraints do the work. No single control solves Excessive Agency, which is exactly the point. Second, the constrained agent lost only capabilities its task never used. It is just as useful as the over-agentic one, and far harder to turn against its operator.
How least agency complements Zero Trust principles
Zero Trust, as NIST frames it, is about removing implicit trust, protecting resources, and authenticating and authorizing subjects and devices before they reach anything. Least agency complements that by applying the same skepticism about implicit trust to autonomous action. The access decision is only half of it. Once an agent is trusted and authorized, the question of how much it should be allowed to do on its own is still open.
Treat the access-versus-autonomy split as a conceptual extension of Zero Trust rather than a formal NIST tenet. It fits naturally alongside the model. Least privilege has always lived inside Zero Trust thinking, and least agency pushes that same logic from what an agent can reach into what it can do without checking back.
In that expanded triage scenario, the boundaries can live outside the model itself. Data Storage Access Control can keep the agent from reaching customer records outside its approved working directory scope. Ringfencing can prevent the trusted agent from launching a "helper" application that is not required for the approved task. Zero Trust Endpoint Firewall can constrain egress, stopping the resulting package from reaching an unapproved destination. The model can still make the wrong decision. The boundary lives outside the model, where that decision can be prevented from becoming an action the environment never intended to allow.
How to reduce excessive agency without impacting productivity
The controls map onto the three root causes, and most of them are things a mature security program already runs.
- Minimize functionality. Limit the tools and extensions the agent can call to the ones its task needs. If the summarizer never needs to send, it should not be able to.
- Scope permissions. Apply least privilege per agent and per action, not all-or-nothing logins. A read task gets a read-only identity.
- Constrain autonomy. Require human approval for high-impact actions, and limit the sequences and conditions under which the agent acts on its own. You don’t let users approve their own access requests; when autonomous AI is functionally a user with broad system permissions, you don’t let it call shots.
- Enforce boundaries outside the model. The same controls can be applied outside the agent itself. As the email example showed, environmental controls can restrict the data an agent can reach, the applications it can invoke, and the destinations it can communicate with, even when the model itself chooses an unsafe action. This is the layer that holds when the model's own judgment does not.
The productivity question comes up every time, and the honest answer is precise: Scoping to the job removes capabilities the task never needed, which shrinks attack surface without taking away the capabilities the workflow requires.
It is worth being clear that attackers also abuse capabilities the task legitimately does need, which is the whole reason least agency exists. The capabilities the agent must keep still need boundaries around how, when, and where they can be used. Match scope to purpose, add those boundaries, and the agent keeps everything its work requires while the “does this slow us down” objection dissolves.
None of this is about making agents less capable. It is about aligning capability to the task. Reach constrained by least privilege, and unnecessary autonomy constrained by least agency.
An agent scoped that way still does everything its job requires but gives anyone who manipulates it far less to work with.
FAQs
Is excessive agency the same as excessive privilege?
No. Excessive privilege is one of three root causes of excessive agency. The others are excessive functionality and excessive autonomy.
Is least agency the same as least privilege?
No. Least privilege limits the permissions and resources an AI agent can access. Least agency governs how much freedom it has to act with those legitimate permissions. The two principles work together, but they solve different parts of the problem.
Should AI agents be trusted with admin rights?
Almost never. Approach it through least privilege, which scopes the access, and least agency, which requires oversight for high-impact actions.
Does limiting AI agency reduce productivity?
Not necessarily. When controls are scoped to the task, they preserve the intended workflow while removing capabilities the agent does not need.
