Governing Excessive Agency in Enterprise AI Agents

What Excessive Agency means in practice

Excessive Agency describes a class of failure that has nothing to do with a model producing a wrong answer and everything to do with an agent being allowed to act on that answer. It occurs when an LLM-based agent -- through hallucination, a manipulated prompt, or simple misconfiguration -- takes an action that a properly scoped system should never have permitted in the first place: deleting records it was only supposed to read, sending an email to an unintended recipient, executing a financial transfer, or modifying infrastructure it was never meant to touch.

OWASP's guidance for large language model applications names this a top-tier risk precisely because agentic architectures and tool-calling plugins have expanded what an LLM can do far faster than most organizations' access controls have caught up.

The root cause is almost always one of three overlapping problems: the agent has functionality it does not need, the agent has permissions broader than its functionality requires, or the agent has autonomy to act without any checkpoint regardless of the impact of the action. Any one of these alone is a latent risk. In combination, they turn a single bad output -- a hallucinated instruction, an injected prompt, a misread parameter -- into an action with real consequences to data integrity, financial exposure, or regulatory standing.

Root Cause	Description
Excessive Functionality	An agent has access to tools or API endpoints beyond what its assigned tasks require. Any one of those unused endpoints is reachable attack surface.
Excessive Permissions	An agent's credentials grant broader read/write access than any of its tasks actually use. A compromised or misdirected agent can act on that access at any time.
Excessive Autonomy	An agent can execute high-impact actions without a human checkpoint at any stage. There is no opportunity to catch a bad decision before it takes effect.

It is worth being precise about why this differs from traditional application security. In a conventional application, the code path an attacker can reach is fixed at build time and reviewed accordingly. In an agentic system, the effective "code path" is decided at runtime by the model's interpretation of the current prompt and context. That means the same agent can take a very different action tomorrow than it took today, even with no code change. Static, point-in-time access reviews are not sufficient for a system whose behavior is determined dynamically.

---

Why this risk is growing faster than governance programs

Enterprise adoption of agentic AI has moved from pilots to production quickly, and the pace of that shift has outrun the pace at which security and governance teams can review each new tool integration.

Organizations applying uniform, one-size-fits-all governance to every agent regardless of its actual autonomy level tend to fail in one of two directions. They either over-restrict simple, low-risk agents in a way that slows delivery and pushes teams toward unsanctioned "shadow" agent development, or they under-restrict genuinely autonomous agents in a way that lets a single compromised or misdirected agent take irreversible action.

The practical implication is that governance programs need a risk-tiering model for agents, not just a single policy. More logging, tighter scoping, and mandatory human approval checkpoints should scale with the consequentiality of the actions an agent can take -- not be applied uniformly across all agents regardless of their actual risk profile.

---

Controls that reduce Excessive Agency

The following controls address the three root causes directly. They are most effective when applied in combination and enforced at the integration layer rather than through prompt instructions alone, since prompt-level restrictions can be bypassed through prompt injection or ignored under unusual inputs.

• Enumerate every tool, API, and plugin an agent can call, and remove any not required for its current tasks.
• Scope credentials to the minimum data and systems each specific task needs, rather than granting broad standing access.
• Require explicit human approval before an agent executes high-impact actions such as financial transactions, data deletion, or external communications.
• Enforce authorization checks in the integration layer between the agent and the system it calls, not only in the agent's own prompt or instructions.
• Apply input and output containment so an agent's function calls are validated against expected parameters before execution.
• Log every tool call with the requesting agent's identity, the parameters used, and the outcome, so anomalous behavior can be reviewed after the fact.

---

Implementation guidance

Start with a functionality audit, not a permissions audit

Before deciding how much access an agent should have, determine what it actually needs to do its job. Most agents are configured with far more tool access than their real task set requires, simply because it was easier to grant a broad toolkit during development. Removing unused functionality closes off attack surface that no permission review would otherwise catch.

Separate advisory actions from consequential ones

An agent that drafts a response for a human to send carries a fundamentally different risk profile than one that sends the response itself. This distinction should be made explicit early in the design of any agent workflow, and your governance controls should reflect it. Advisory agents and consequential agents warrant different review processes and different approval thresholds.

Enforce scope and approval requirements at the integration layer

Restrictions embedded in a system prompt are not a reliable control boundary. Prompt injection attacks and unusual inputs can bypass them. A runtime authorization layer that independently validates each action against policy provides a control that does not depend on the model behaving as instructed. Scope enforcement belongs in the layer between the agent and the systems it calls.

Revisit classifications on a recurring schedule

An agent's task scope tends to expand over time as teams add new capabilities incrementally. Each addition should trigger a fresh review of whether its permissions and approval requirements still match its actual autonomy level. Governance that was calibrated correctly at launch can become inadequate within months if the agent's functionality grows without corresponding review.