Excessive Agency
Damaging actions performed in response to unexpected, ambiguous, or manipulated model output — rooted in excessive functionality, excessive permissions, or excessive autonomy. In 2026 it climbs to third, the most consequential move on the list.
What it is
An LLM system is usually granted some agency: the ability to call functions or interface with other systems through tools (variously called extensions, plugins, or skills) to act on a prompt. The model often chooses which tool to invoke dynamically, and agent systems chain calls, feeding earlier output into later ones.
Excessive Agency is the vulnerability that lets damaging actions happen in response to unexpected, ambiguous, or manipulated model output — regardless of what caused the model to malfunction. Triggers include hallucination from a poorly-performing model and direct or indirect prompt injection from a malicious user, a compromised tool, or a peer agent.
The root cause is typically one or more of excessive functionality (tools that do more than the task needs), excessive permissions (downstream access beyond what is required), and excessive autonomy (high-impact actions taken without independent verification). Impact spans confidentiality, integrity, and availability, depending on which systems the app can reach.
Excessive Agency differs from Improper Output Handling (insufficient scrutiny of outputs). Sanitising inputs and outputs is not a root control here — that is covered by LLM01 Prompt Injection for inputs and LLM10 Improper Output Handling for outputs.
Common examples
- Excessive functionality: an agent needs to read documents from a repository, but the chosen third-party tool also modifies and deletes them.
- Excessive functionality: a tool trialled during development is dropped in favour of a better one, but remains available to the agent.
- Excessive functionality: an open-ended tool (“run a shell command”) fails to prevent commands beyond the one it was meant to run.
- Excessive permissions: a read-only tool connects to a database with an identity that also holds UPDATE, INSERT, and DELETE rights.
- Excessive permissions: a per-user tool accesses downstream systems with a generic high-privileged identity, reaching every user's files.
- Excessive autonomy: a tool deletes a user's documents with no confirmation step.
Prevention & mitigation
- Minimise tools. Offer the agent only the minimum set of tools it needs — if it never needs to fetch a URL, do not expose that tool.
- Minimise tool functionality. Limit each tool to the minimum functions required; a mailbox-summarising tool should read mail, not send or delete it.
- Avoid open-ended tools. Prefer granular tools with a strict input schema over “run any shell command”; validate parameters before use.
- Minimise tool permissions. Grant downstream access at least privilege — a product-recommendation tool needs read access to one table, nothing more.
- Execute in the user's context. Preserve the original user's authorisation and scope across chained tool or agent calls, rather than relying on a service identity.
- Require user approval. Put a human in the loop for high-impact actions — the tool that posts to social media should require the user to approve each post.
- Enforce complete mediation. Validate every downstream request against policy in deterministic code or an independent policy decision point, not by asking the LLM whether an action is allowed.
- Graduate enforcement. Auto-approve low-consequence, reversible actions (a refund as store credit) while routing irreversible ones (an external payout) to human review.
- Monitor and rate-limit. Log tool and downstream activity, and use circuit breakers that halt or escalate when invocation or cumulative-value thresholds are exceeded.
Example attack scenarios
- A personal-assistant app reads a mailbox to summarise email, but the chosen tool can also send mail; an indirect injection in an incoming message tricks the agent into forwarding sensitive data to the attacker. Read-only scope, a mail-reading-only tool, or manual send approval would each have prevented it.
- An agent with database write permissions it never needed executes an attacker-influenced deletion because the identity it used held more than SELECT.
- A high-autonomy scheduling agent cancels or books actions with real-world consequences without any confirmation step, amplifying a single confabulation into a business incident.
References
- OWASP Top 10 for LLM Applications 2026 — LLM03:2026 Excessive Agency: genai.owasp.org
- OWASP Top 10 for Agentic Applications (ASI) — 2026: ASI02 Tool Misuse, ASI03 Identity & Privilege Abuse, ASI08 Cascading Failures
- The principle of complete mediation (Saltzer & Schroeder)
- NIST AI 100-2 E2025 — deterministic mediation as a procurement baseline
How Neural Industries helps. We inventory every tool, permission, and autonomous action path in your agentic system, model the blast radius, and help you enforce least privilege and complete mediation before an attacker finds the gap.
Request an assessment →