The #1 agentic AI risk — and the three controls that prevent LLM06 violations without eliminating agent autonomy
OWASP LLM06 is the vulnerability that amplifies every other LLM risk. System prompt instructions do not prevent it — capability-level controls do. Here are the three technical controls: minimum-capability tool scoping, confidence-based escalation thresholds, and human-in-the-loop enforcement for irreversible actions.
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.
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.
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.
OWASP LLM06 Excessive Agency describes a vulnerability class in which an AI agent is granted excessive functionality (access to tools it doesn't need), excessive permissions (overly broad scopes within those tools), or excessive autonomy (the ability to take high-impact actions without human approval). Any of these dimensions can independently create an unacceptable blast radius if the agent is compromised, manipulated, or simply makes an error.
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. Excessive autonomy is addressed by human-in-the-loop escalation thresholds.
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. 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.
In agentic AI security, blast radius refers to the scope of systems, data, and operations that could be affected if an agent is compromised, manipulated, or makes an error. An agent's blast radius is determined by the union of all tools it can access, the permissions within each tool, and the volume of actions it can take autonomously without human oversight. Reducing blast radius is the primary operational goal of OWASP LLM06 mitigations.
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, 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.
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 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. 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.
Human-in-the-loop (HITL) escalation in agentic AI refers to a configured mechanism that pauses an agent's autonomous execution and routes a pending action to a human approver before proceeding. OWASP LLM06 requires HITL for high-impact operations. Effective HITL implementations define explicit thresholds (financial, data sensitivity, regulatory scope), a designated approver with SLA expectations, a timeout behavior (reject vs. pause), and an audit record of the approval decision and the approver's identity.
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.
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, 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).
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.
Figure 1: OWASP LLM06 Excessive Agency — Agent Action Request Decision Flow. Every tool call passes through identity, scope, and threshold checks before execution. Failures are blocked and logged. Escalations route to human approval.
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.
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.
AgentTrust OS provides the three-layer control stack that directly addresses each dimension of OWASP LLM06 Excessive Agency — pre-production privilege review, real-time enforcement, and immutable audit.
Validates agent token, checks tool allowlist, applies escalation thresholds, and blocks out-of-scope calls before execution on every tool call.
Immutable log of every agent action, decision, and escalation event. Provides the forensic reconstruction capability required by SOC 2, ISO 27001, and emerging AI audit standards.
Validates that agent tool allowlists conform to least-privilege policy, flags excessive permissions before agents reach production, and certifies the agent's privilege posture.
Figure 2: AgentTrust OS governance pipeline for OWASP LLM06 Excessive Agency — pre-production certification, real-time runtime enforcement, and immutable audit logging.
AgentTrust OS implements OWASP LLM06 controls across pre-production, runtime, and audit — identity enforcement, least-privilege allowlisting, escalation thresholds, and immutable logging.
Start Free →