What Is OWASP LLM06 Excessive Agency and How Do You Prevent It?

Your AI agents may be the most over-privileged actors in your enterprise. Here's what OWASP LLM06 tells you to do about it — and how to implement it in production.

Consider what you know about your most trusted employee. They have access to the systems their role requires. Their badge expires when they leave. Someone approved their access, and someone else can revoke it. If they make a mistake, there's a record. Now consider your average enterprise AI agent. It was provisioned with a shared API key that never rotates. It has access to 40 or more tools — many of which were added during development and never removed. It runs continuously, 24 hours a day, with no badge-out mechanism. Nobody approved its current scope formally, and nobody knows exactly what it can do. This is OWASP LLM06 Excessive Agency.

The cost of inaction is not theoretical. When an agent operating with Excessive Agency is manipulated via prompt injection — a technique where malicious content in the environment overrides the agent's instructions — the result is a fully credentialed actor executing arbitrary actions at scale. The blast radius is determined not by the attacker's capability, but by the agent's provisioned access. An agent with write access to payment systems, CRM records, and email infrastructure is more dangerous when compromised than an insider threat, because it never sleeps and its activity volume doesn't trigger behavioral anomaly detection.

This post covers what OWASP LLM06 Excessive Agency is, why enterprises systematically over-provision agents, how to implement per-agent identity and least-privilege controls in production, and what escalation thresholds actually look like in regulated industry deployments. We conclude with the AgentTrust OS implementation pattern and an inline decision-flow diagram you can adapt for your governance review process.

What exactly does OWASP LLM06 Excessive Agency cover?

OWASP LLM06 Excessive Agency is the sixth entry in the OWASP Top 10 for Large Language Model Applications and specifically addresses the risk that arises when an LLM-based agent is granted more capability than it needs to perform its intended function. Unlike many security vulnerabilities that require an active exploit, Excessive Agency is a design-time failure — the over-provisioning happens during development and persists silently until it matters.

The three sub-dimensions of LLM06 are worth understanding separately because they have different mitigations. Excessive functionality is addressed by tool allowlisting — defining the minimal set of tools an agent needs for its specific task and stripping all others. Excessive permissions is addressed by scope restriction within each tool — an agent with read-only access to the HR database is far less dangerous than one with write access, even if both have "HR tool" access. Excessive autonomy is addressed by human-in-the-loop escalation thresholds — defining the class of actions the agent may take without confirmation and those that require human approval.

Why do enterprise agents end up over-provisioned by default?

There are four structural reasons that enterprise agents accumulate excessive permissions, and they all trace to the development lifecycle, not to malicious intent.

First, provisioning is easier than scoping. When a developer creates an agent prototype, they provision a service account or API key with broad access to unblock development velocity. Production deployment inherits the prototype's permissions because nobody explicitly reverts them. Second, tool sets are additive. Developers add tools as they identify capabilities the agent needs, but rarely remove tools when requirements change. An agent that started with five tools may have thirty by the time it reaches production. Third, shared credentials are operationally convenient. A shared API key used across multiple agent instances is simpler to manage than per-agent OAuth tokens — until an incident occurs. Fourth, escalation paths are awkward to implement without a framework. Defining exactly when an agent should pause and ask a human for approval requires product, compliance, and engineering alignment that rarely happens during initial deployment.

How does per-agent identity reduce OWASP LLM06 risk?

Per-agent identity is the foundational control for OWASP LLM06. Instead of all agents sharing a single service account or API key, each agent instance receives its own credential that is scoped to the specific task it is performing and expires when that task is complete. This has two security effects: it eliminates credential reuse across agents (so a compromised credential cannot be used to impersonate a different agent with different permissions), and it makes audit trails interpretable (every action in the log is attributed to a specific agent identity, not to an anonymous shared key).

Microsoft Entra Agent ID, released in 2025, provides exactly this pattern for Microsoft ecosystem deployments. Each agent is registered as an identity in Entra ID and receives OAuth 2.1 tokens scoped to specific API audiences and time-bounded to the session. AWS AgentCore Identity provides the equivalent on the AWS side — each AgentCore agent receives an IAM credential scoped to its Cedar Policy-defined permissions. Both implementations support short-lived tokens with automatic rotation, so there is no long-lived secret to compromise.

What escalation thresholds should enterprises configure?

Escalation thresholds are the operational mechanism for implementing OWASP LLM06's human-in-the-loop requirement. They define a boundary between actions the agent may take autonomously (within its provisioned permissions) and actions that require a human to explicitly approve. Thresholds can be based on financial value, data sensitivity, operational reversibility, or regulatory classification.

In financial services, a common starting pattern uses two tiers: transactions below $50 auto-execute, transactions between $50 and $5,000 require human approval within a defined window, and transactions above $5,000 require explicit sign-off before the agent can proceed. This is not a technical limitation — it is a governance policy expressed in the agent's configuration. The same logic applies to non-financial operations: deleting fewer than 100 records from a non-regulated table may be auto-approved, but deleting records from a PII-containing table always requires human confirmation.

The approver role matters. HITL is weakest when the approval goes to the same team that deployed the agent — they are likely to approve without sufficient scrutiny. Effective HITL escalation routes to a named individual in a different chain of command: a compliance officer, a senior engineer who did not develop the agent, or a risk manager. The approval action itself must be logged with the approver's identity and timestamp, creating an accountability record.

How does least-privilege tool allowlisting work in practice?

Least-privilege tool allowlisting means defining the precise set of tools an agent is permitted to invoke for a given task, and configuring the agent runtime to block any tool call outside that set. This is a departure from the common pattern of giving agents access to all available tools and trusting the model to select appropriate ones.

Implementation requires a tool inventory for each agent — a documented list of every tool the agent can invoke, the permission scope within each tool, and the business justification for that access. For an agent that processes customer refunds, the allowlist might include: read access to the order management system (to verify order details), write access to the refund processing API (restricted to amounts below $500), and read access to the customer record system (name and email only, not full profile). That is three tools with scoped permissions, rather than unrestricted access to all payment, CRM, and communication infrastructure.

The allowlist must be enforced at the runtime level, not just at the model level. Models can be instructed not to use certain tools, but a prompt injection attack may override that instruction. Runtime enforcement means the agent execution environment intercepts tool calls and rejects any call to a tool not on the allowlist, regardless of what the model requested.

What role does immutable audit logging play in OWASP LLM06 defense?

Immutable audit logging serves two functions in an OWASP LLM06 defense posture: it provides the forensic record needed for incident reconstruction, and it creates the accountability mechanism that makes human-in-the-loop escalation meaningful. An approval without a record of who approved it and when is just a delay mechanism, not a governance control.

An effective audit log for agentic AI captures the agent identity (not just the service account, but the specific agent instance and session), the tool called, the parameters passed to that tool, the result returned, the decision path taken (auto-execute, human escalation, or blocked), and — for escalated actions — the approver identity, approval timestamp, and any notes. This record must be append-only and stored in a system the agent itself cannot modify; otherwise a compromised agent could clean its own trail.

In regulated industries, audit logs for agentic AI actions are increasingly expected to meet the same standards as human transaction records. SOC 2 Type II requires evidence that access control policies are operational; an immutable log of agent decisions is the most direct evidence available. ISO 27001 Annex A.8.15 requires logging and monitoring of user activities, and AI agents are being treated as a category of "user" by many compliance frameworks.