An AI agent that can read a repository is useful. Grant the same agent permission to merge code, modify infrastructure, rotate credentials, and trigger deployments, and the risk changes quickly.
The problem is not simply that the model might make a mistake. The larger concern is what the system allows that mistake to turn into.
What Is Excessive Agency?
Excessive agency occurs when an AI-enabled system has more functionality, permissions, or autonomy than necessary for its intended task. A model output that would otherwise be a poor suggestion can become a real security incident once the agent can act on external systems.
OWASP identifies three common root causes: excessive functionality, excessive permissions, and excessive autonomy. Harmful actions can result from hallucinations, poorly constructed prompts, direct prompt injection, or indirect prompt injection via external content or connected systems.
Consider a coding agent tasked with investigating a failing deployment. Reading logs and repository files is reasonable. Allowing the same agent to modify production configuration and immediately redeploy gives a single reasoning error a much larger blast radius.
Where the Risk Comes From
Most excessive agency AI problems stem from system design rather than from the model alone. An agent receives a set of tools, identities, API scopes, and execution rules. Those choices determine what happens after the model decides to act.
A few patterns appear repeatedly:
- Too many tools: A read-oriented agent also receives delete, send, deploy, or administrative functions.
- Broad credentials: An agent uses a service account with permissions far beyond the current task.
- Unrestricted execution: High-impact operations run immediately without independent approval or policy checks.
- Open-ended tools: Generic shell execution or unrestricted API access exposes far more capability than a narrow task requires.
OWASP specifically recommends minimizing available extensions, their functionality, and their downstream permissions rather than relying on the model to consistently select the safe action.
Autonomy Changes the Failure Mode
Traditional applications typically follow explicitly coded paths. Agents are different. They can interpret a goal, select tools, evaluate intermediate results, and decide what to do next. That creates an AI agent autonomy risk even when individual tools behave correctly.
Suppose an operations agent receives an alert that disk utilization is high. The agent identifies old application data and decides that deleting it is the fastest fix. The deletion API works exactly as designed. Authentication succeeds. Authorization succeeds. The failure is that the agent was allowed to make a destructive operational decision without a separate control to determine whether deletion was appropriate.
This distinction is easy to miss during security reviews because teams often focus on whether an agent can perform an action. They also need to ask whether the agent should be allowed to decide when that action occurs.
Match Controls to Impact
Not every agent action requires human approval. Requiring confirmation for every log query or repository read would render most automation pointless. Approval should increase with reversibility, scope, and business impact.
The useful boundary often lies between preparing an action and committing it. An agent can draft an email without sending it, prepare an infrastructure change without applying it, or generate a database migration without executing it.
Building AI Agent Guardrails
Good AI agent guardrails should be implemented outside the model whenever possible. A prompt that says “do not delete production data” is not an authorization boundary.
The execution layer should enforce the actual limits. Use narrowly scoped identities. Expose task-specific tools rather than unrestricted shells. Validate every privileged request against authorization policy, including requests produced during multi-step agent workflows.
High-impact operations should also be observable. Logging tool calls, arguments, identities, approval decisions, and downstream results makes unexpected behavior easier to investigate. Rate limits can reduce damage when an agent repeats a bad action, but monitoring and throttling do not replace preventive controls.
The safest design assumption is simple: the model will occasionally misinterpret context. The system architecture should determine how costly that misunderstanding can be.
Conclusion
Agents become risky when reasoning errors are directly tied to powerful actions. Reducing excessive agency does not require removing autonomy entirely. It requires giving agents only the tools, permissions, and decision authority needed for the current job, while keeping high-impact actions behind controls that do not depend on the model making the correct judgment every time.
FAQs
1. Why is excessive agency a top risk in agentic AI?
Agentic systems can do more than produce text. They may call APIs, modify records, execute code, or trigger workflows with limited supervision. A hallucination or manipulated instruction can therefore cause an actual system change rather than just an incorrect response. OWASP lists excessive agency among its major risks for LLM applications.
2. How do teams decide which agent actions need approval?
Consider the potential impact and how easily the action can be reversed. Reading logs usually requires less control than deploying code, deleting data, sending external communication, or changing access permissions. Actions affecting production, sensitive information, money, or security boundaries generally deserve stronger independent checks.
3. Can excessive agency exist even with correctly scoped permissions?
Yes. An agent may have exactly the permissions required for a tool yet still have too much autonomy in deciding when to use it. For example, a deployment agent might legitimately have deployment permission while still requiring approval before releasing a change to production. Permission scope and decision authority are separate controls.