Excessive Agency in LLM Applications (OWASP LLM06)

What OWASP Means by Excessive Agency

OWASP’s Top 10 for LLM Applications, maintained by the OWASP GenAI Security Project, defines Excessive Agency (LLM06) as a distinct risk category describing LLM-based systems that perform damaging or unintended actions because they were built with more functionality, permissions, or autonomy than any specific task requires. This is not a generic AI safety concern about model behavior in the abstract. It is an architectural and access-control problem: the risk exists because of how an agentic system is designed and provisioned, not primarily because of how the underlying model reasons.

OWASP explicitly distinguishes Excessive Agency from prompt injection (LLM01). Prompt injection is frequently the triggering mechanism, but it only becomes dangerous when it can reach a system that already has excessive agency to exploit. A well-scoped agent with narrow tool access and gated actions limits the blast radius of a successful injection attempt, while an over-privileged agent turns the same injection into unauthorized data access, privilege escalation, or an irreversible action.

Architectural Patterns That Introduce This Risk

Excessive agency generally originates from a small set of recurring design choices in agentic LLM applications. Function-calling and tool schemas define the ceiling of what a model can request; when these schemas expose broad, multi-capability APIs rather than narrow, single-purpose functions, excessive functionality is built in from the start.

Plugin and tool chaining compounds this: agents that call multiple tools in sequence without a per-call authorization check tend to inherit the full permission set of the underlying service account, which widens the effective attack surface with every additional tool added to the chain. Shared or static API keys used across multiple agent workflows make it structurally difficult to scope permissions per task, which is a direct driver of excessive permissions.

Multi-step autonomous execution, where an agent plans, acts, and re-plans across several turns, increases the number of decision points where a manipulated intermediate output can trigger a tool invocation the task never actually required. Without checkpointing, that action chain can complete, including a transaction or a data modification, before any review occurs.

How Prompt Injection Interacts With Excessive Agency

A representative scenario illustrates the mechanics rather than describing a confirmed incident: an agent with a customer-support function is given a shared service account that also has write access to a billing system, because provisioning a separate scoped credential was skipped for convenience. A crafted input, injected through a document the agent is asked to summarize, instructs the model to call the billing function instead of the support function.

Because the agent’s permissions were never scoped to the support task specifically, and no approval checkpoint exists before billing actions execute, the injected instruction succeeds. The failure here is not that prompt injection occurred; injection attempts are common and should be assumed possible. The failure is that the system had no permission boundary or human checkpoint to contain the consequence once the injection succeeded.

This is the core reason OWASP treats Excessive Agency as a separate risk category with its own mitigation path, rather than a downstream symptom to be solved entirely through prompt-level defenses.

Governance and Runtime Enforcement

Addressing Excessive Agency effectively requires governance decisions in addition to engineering ones. Organizations should establish a mandatory least-privilege review before any new tool or function is granted to a production agent, with approval owned by a team separate from the one building the agent, to avoid self-approval of broad access.

Excessive agency review fits naturally into existing AI risk governance processes, and NIST’s AI Risk Management Framework identifies human oversight and accountability mechanisms as core functions for managing systems that take automated or semi-automated actions, which is directly applicable here even though NIST does not use the term Excessive Agency itself.

Because the risk is architectural, the controls that matter most operate at runtime rather than at the prompt layer: agent identity and permission scoping, tool-call approval workflows, and audit logging of every action taken. Trussed AI provides runtime governance for enterprise AI agents in this category, including agent identity, least-privilege permissioning, tool approval workflows, and audit logging, applied at the point where a model’s output becomes an actual system action rather than left to model-level instructions alone.