Excessive Agency in LLMs: What It Is and How to Prevent It

An AI agent that can read your product database, file a support ticket, and issue a refund without waiting for approval might be doing exactly what you built it to do, so you need to see which decision failed. The trouble starts when the same agent turns out to hold DELETE rights on that database, or when a stranger’s product review tells it to close someone else’s account.

This guide covers the root causes of excessive agency, the controls that prevent it, and the production detection guidance needed to identify unsafe agent behavior.

What Is Excessive Agency?

Agency is the ability a developer grants a large language model (LLM) to call functions or interface with other systems via extensions (tools, skills, or plugins, depending on the vendor). Calling an application programming interface (API), writing a file, executing a shell command, or sending a message all count (text generation alone does not).

Excessive agency is a vulnerability allowing damaging actions in response to unexpected, ambiguous, or manipulated LLM outputs, regardless of what causes the LLM to malfunction. The Open Worldwide Application Security Project (OWASP) designation has moved twice in the OWASP Top 10 for LLMs: LLM08 excessive agency in the 2023/24 edition, LLM06:2025 in the 2025 edition, and LLM03 in the 2026 edition, with a publication date of August 3, 2026.

The Three Root Causes of Excessive Agency

Excessive functionality, excessive permissions, and excessive autonomy are root cause analysis categories. Each condition comes from how the agent was configured and deployed, and each widens an attack surface the agent already carries.

Excessive Functionality: Tools the Task Never Needed

Your agent may hold tools with functions its task doesn’t require. If you need document read access, you may choose a third-party tool that also modifies and deletes files. At the database layer, a SELECT tool may use an identity with unnecessary UPDATE, INSERT, and DELETE permissions. This links excessive functionality to excessive downstream access.

Excessive Permissions: What the Agent Can Do vs. What It Should

Your downstream access permissions can overreach even when functionality does not. A read-only tool may use an identity that carries SELECT, UPDATE, INSERT, and DELETE. Tools that retrieve customer information can likewise use broadly privileged identities instead of user-scoped, least-privilege accounts.

Excessive Autonomy: Irreversible Actions with No Approval Gate

Excessive autonomy, the third condition, permits execution without oversight. Irreversibility turns it into real damage. For example, a tool that deletes a user’s documents without confirmation. Deploying cloud resources, sending external communications, publishing content, and updating customer records can turn one flawed instruction into an action that is difficult or impossible to undo.

How Excessive Agency Manifests (Real Attack Scenarios)

Prompt injection converts these conditions into incidents. In direct prompt injection, the attacker’s instructions arrive in the user turn; with indirect injection, they arrive inside retrieved content such as a web page, document, or GitHub issue. Indirect injection is harder to catch because the malicious instructions reach the model through retrieved content the agent trusts, without the attacker ever interacting with your application directly.

• Direct injection into a destructive backend call: An attacker persuades an LLM with raw Structured Query Language (SQL) access to execute a destructive database operation. This turns manipulated output into damage.
• Financial plugin abuse: A customer service LLM issues refunds while the system prompt, rather than the API, specifies the limit. Direct prompt injection can convince the model to exceed it because the downstream system lacks external authorization enforcement.
• Indirect injection into data exfiltration: EchoLeak, Common Vulnerabilities and Exposures (CVE) entry CVE-2025-32711, hid instructions in an email as white-on-white text. Microsoft 365 Copilot parsed them, pulled sensitive data from the user’s context, embedded it in a uniform resource locator (URL), and used image rendering to fetch the URL automatically.
• Over-broad read scope: A tool reading the current user’s documents connects through a privileged repository account that can see every user’s files.

Each attack needed a capability the task never justified and a path for attacker text to reach the model. The lethal trifecta combines access to private data, exposure to untrusted content, and the ability to communicate externally. An agent with all three presents a high-risk combination regardless of how carefully its prompt is written.

The Impact of Excessive Agency

The damage can expose or alter data and disrupt system availability. Because agents act under delegated identities, it extends to compliance violations and reputational damage.

Automated tool-calling loops can repeat operations before human intervention. This makes agent incidents faster than conventional compromises.

That speed requires your security team to maintain security information and event management (SIEM) visibility through Cloud SIEM, govern the agent inventory with AI Discovery, and use detailed log management for prompts, tool calls, authorization decisions, and outcomes.

How to Prevent Excessive Agency (Mitigation Strategies)

Configure preventive controls before deployment. The mitigations for LLM06:2025 Excessive Agency (previously cited) map onto the three root causes and include controls that downstream systems enforce outside the prompt. Downstream controls determine what the model may do.

Apply the Principle of Least Privilege

An agent using a product database for purchase recommendations needs read access to a products table and nothing else. Your database permissions should enforce that limit on the connecting identity rather than relying on prompt instructions.

A tool reading a user’s code repository should authenticate that user through Open Authorization (OAuth) with the minimum required scope.

Limit Tool Scope

Your design should favor granular tools over open-ended options such as “run a shell command” or “fetch a URL.” If the app needs to write a file, a purpose-built tool is safer than handing the agent a shell.

A shell tool can turn one injected instruction into arbitrary command execution. External authorization is therefore essential.

Enforce Permissions Outside the Model

Complete mediation means a policy engine independently validates every request a tool makes to a downstream system against security policy. The systems the agent calls must enforce access controls independently of the model’s self-policing.

Prompt-only enforcement can fail when injected text changes model behavior.

Require Human Approval for High-Stakes Actions

Human-in-the-loop approval should precede high-impact actions. The approval policy should become stricter as the action’s potential impact and irreversibility increase.

The downstream system or tool should enforce the gate so an injected instruction cannot skip it. Without a gate, a call caused by LLM hallucinations executes like a legitimate one.

Validate Prompts and Outputs Before Execution

Documents, emails, API responses, and retrieved web content are untrusted input that needs validation before it influences goal selection or a tool call. Model output needs the same check, since injection becomes execution when the model builds a tool call from an unvalidated string.

A refund limit written into the system prompt is a suggestion the model can ignore under injection, and only the downstream API can enforce it as an actual control.

Apply Zero Trust Principles to AI Agents

A backend service has static code paths an auditor can read. An LLM decides an agent’s workflow at runtime through a tool-calling loop that receives untrusted input.

A policy engine should validate every tool invocation before execution and block unauthorized attempts. Your system should preserve agent and user context so downstream systems can enforce the right scope.

Rate limiting caps how quickly a compromised agent can issue tool calls, giving your detection pipeline time to flag the abuse before the loop expands. Least privilege, scoped tools, and rate limits are configured in advance, and runtime telemetry is what confirms they hold once the agent is live.

Detecting Excessive Agency in Production

Production detection shows whether preventive controls constrain the agent as intended. Runtime traces must connect model decisions, tool calls, authorization outcomes, and business effects across the session. Alerts can identify unsafe sequences before repeated operations expand the damage.

Why Default Logging Misses Agent Behavior

You configure permissions, tool scopes, and approval gates before deployment. Runtime systems then detect unsafe behavior. Runtime instrumentation should go beyond proxy-level instrumentation and LLM observability tools to include OpenTelemetry for AI, business logic, and the context behind a destructive call.

A documented PocketOS incident involved a coding agent deleting a production Railway volume after encountering a credential mismatch and finding an API token in an unrelated file.

What Runtime Traces Must Capture

Agentic AI observability needs the full execution graph because input and output pairs omit tool execution context. Runtime traces should capture the following:

• Span hierarchy: GenAI semantic conventions organize an agent run under an invoke_agent span, with separate chat children for LLM calls and execute_tool children for tool invocations.
• Tool call attributes: These spans carry attributes such as gen_ai.tool.call.arguments, which record the parameters passed to each tool invocation.
• Prompt and message content: You must turn on opt-in content recording before the instrumentation captures system prompts, input messages, and output messages.
• Session-level grouping: Risky behavior appears across action sequences, not in one API call, so AI agent monitoring groups spans at the session level.

Together, these four capture points turn a scattered set of LLM calls and tool invocations into a coherent session record that your alerting policy can evaluate against expected agent behavior.

Signals Worth Alerting On

Your alerting policy should cover tool calls outside declared scope, repeated API operations, abnormal data access, rapid execution loops, and token cost spikes.

Runtime rate limits should stop agent loops from consuming resources unchecked until an external control intervenes.

The GenAI attribute registry defines the standard fields your instrumentation emits for token counts and tool-call metadata, which your alerting policy can read directly. For regulated workloads, European Union (EU) AI Act Article 12 obliges providers of high-risk systems to retain automatic event logs across the agent’s lifecycle.

AI observability platforms capture agent context, multi-turn sessions, and tool activity that traditional application performance monitoring tools may omit. Coralogix AI Center traces multi-turn sessions in Session Explorer, blocks unsafe outputs in real time with AI Guardrails, and scores prompts and responses against quality and security evaluators including prompt injection and data leakage. This session-level view connects an unsafe model decision to its tool call and downstream effect.

Excessive Agency and Prompt Injection (How the Attack Chain Forms)

Prompt injection can exploit an agent’s permissions and autonomy and increase the damage it can cause. Direct or indirect input can manipulate an agent, so permissions and approvals must limit what a successful injection can do. These injection methods commonly trigger excessive agency.

Defense in depth reduces reliance on any single control and supports a practical GenAI security posture. One three-layer database defense starts with a prompt instruction against modifications. Output validation then rejects modification requests before they reach the database. Role-based access control denies access if one arrives.

These layers reduce the chance that one failed safeguard turns manipulated input into a destructive action.

Prevention and Detection Across the Agent Lifecycle

Prevention and detection sit at different points in the agent lifecycle, and the engineering team building the agent owns both. Before deployment, that team sets least-privilege identities, scopes each tool to a single purpose, and gates irreversible actions behind human approval.

After deployment, runtime instrumentation shows what the agent actually does with the capabilities it was granted. A scoped agent without telemetry hides its mistakes from the on-call engineer investigating an incident, and a traced agent with DELETE rights still executes those deletions.

Configuration limits the blast radius while instrumentation reveals when the agent tests or crosses those limits.

Frequently Asked Questions About Excessive Agency

Is ChatGPT an agent or an LLM?

In its base form it’s an LLM producing text. Once you connect it to tools such as web browsing, code execution, or plugins, it gains agency and comes into scope for excessive agency risk; the vulnerability appears when functionality, permissions, or autonomy exceed the task. The threshold is the ability to call functions or interface with other systems.

What is the difference between excessive agency and overreliance?

The two separate risks concern different failure modes. Excessive agency (LLM06:2025) concerns what the AI system does autonomously through its tools and permissions. The LLM misinformation risk covers false or misleading output that appears credible, and overreliance is the human failure to verify it. The system acts in one case; the human trusts uncritically in the other.

Can excessive agency occur without prompt injection?

Yes. The three root causes are structural rather than attack-dependent, and benign hallucination triggers include poorly engineered prompts or a poorly performing model, with no attacker involved. Granting too many tools or too broad a database identity creates the exposure on its own.

How does excessive agency relate to the principle of least privilege?

Apply least privilege to each agent’s tools and permissions. Excessive agency arises when agent design does not apply it. Guidance on agentic application risks recommends per-tool least-privilege profiles covering scopes, maximum rate, and egress allowlists. You should express these profiles as identity and access management (IAM) or authorization policy stanzas and attach them to each tool; do not rely on ad hoc conventions.

You can start a free 14-day Coralogix trial to trace your agent sessions end to end and test AI Guardrails against unsafe outputs.