OWASP LLM06 Excessive Agency Guide

When an LLM application is wired to tools, the worst thing a manipulated or confused model can do is whatever those tools and their credentials allow. LLM06:2025 Excessive Agency is the OWASP Top 10 for LLM Applications entry for that design flaw: damaging actions performed in response to unexpected, ambiguous or manipulated model output. This guide stays with LLM application design, the extensions, permissions and approval steps a development team controls, and leaves autonomous multi-agent behaviour to the agentic pages. It is written for architects, developers and IAM teams building assistants, copilots and tool-calling features, and for the reviewers who approve them.

Key takeaways

Three root causes, three fixes. OWASP traces Excessive Agency to excessive functionality, excessive permissions and excessive autonomy; each needs its own control, and fixing one does not cover the others.
The cause of the bad output is irrelevant. OWASP covers hallucination, direct and indirect prompt injection and compromised extensions alike, so the design must be safe even when the model is wrong.
Authorise outside the model. OWASP's complete mediation principle says downstream systems decide what is allowed; a system prompt saying "only read" is not access control.
The credential is the blast radius. In the PocketOS and Replit incidents the decisive factor was a token or connection with production delete rights, not the model.
Approvals must be specific and authenticated. A human approval bound to the exact action and parameters stops damage; a generic "allow tools" switch does not.

What it is and who it applies to

OWASP describes agency as the ability to "call functions or interface with other systems via extensions (sometimes referred to as tools, skills or plugins by different vendors)", with the choice of extension sometimes delegated to the model. Excessive Agency is "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM, regardless of what is causing the LLM to malfunction". The 2023 edition split this between LLM08 Excessive Agency and LLM07 Insecure Plugin Design; the 2025 entry covers both concerns.

It applies to any LLM application with at least one tool that changes state or reaches data: email and calendar assistants, CRM and service-desk copilots, text-to-action features in SaaS products, coding assistants with terminal or deployment access, and MCP clients connected to third-party servers. OWASP is explicit that LLM06 differs from output handling: LLM05 asks whether output is safe for the next component, LLM06 asks what the system is able to do with it. See the OWASP LLM Top 10 LLM05 Improper Output Handling Guide.

Relationship to the agentic list: the OWASP Top 10 for Agentic Applications (published 9 December 2025) treats the same ground from the agent's side. ASI02 Tool Misuse and Exploitation covers agents misusing tools they are legitimately allowed to call, and ASI03 Identity and Privilege Abuse covers delegation chains and inherited privilege across agents. If your system plans multi-step tasks, delegates to other agents or keeps memory, read the OWASP Agentic Top 10 ASI02 Guide and the OWASP Agentic Top 10 ASI03 Guide alongside this one.

Structure and key requirements

OWASP gives six examples grouped under the three root causes, and eight preventive strategies plus two damage limiters. Mapping them together gives a design review template.

Root cause	OWASP example	Preventive strategy	Test that proves it
Excessive functionality	A document-reading extension that can also modify and delete	1. Minimise extensions; 2. Minimise extension functionality	The tool manifest exposes only the verbs the use case needs
Excessive functionality	A plugin trialled in development and left available	1. Minimise extensions	Production tool list matches the approved list; unknown tools denied
Excessive functionality	A "run one shell command" extension that runs any command	3. Avoid open-ended extensions	No generic shell, SQL or fetch-URL tool in production
Excessive permissions	A read extension connecting with SELECT, UPDATE, INSERT and DELETE	4. Minimise extension permissions	Attempted writes through the tool are refused by the database
Excessive permissions	A per-user extension using a generic high-privileged identity	5. Execute extensions in user's context	User A cannot reach user B's data through the tool
Excessive autonomy	Deletions performed without user confirmation	6. Require user approval	High-impact calls block until an authenticated approval arrives
All three	Model decides whether an action is allowed	7. Complete mediation; 8. Sanitise inputs and outputs	Every downstream request is authorised by policy, regardless of prompt

The two damage limiters are logging and monitoring of extension and downstream activity, and rate limiting so fewer undesirable actions can happen before monitoring catches them. OWASP states plainly that these "will not prevent Excessive Agency".

The OWASP worked example is useful in design reviews: a mailbox summariser whose chosen plugin can also send mail, hit by an injected email that tells it to forward sensitive messages. OWASP's three fixes are a read-only extension, an OAuth session with a read-only scope, and a user who reviews and presses send on every drafted message. Embrace The Red demonstrated the same shape against ChatGPT plugins in May 2023, when a web page drove the Zapier plugin to summarise the user's email and a browsing plugin sent it out; Zapier responded by requiring authenticated confirmation.

Identity and NHI requirements

Excessive permissions is an identity problem. Every extension authenticates to something, and the credential it uses decides the worst case. MITRE ATLAS now lists three mitigations that state this directly: AML.M0026 Privileged AI Agent Permissions Configuration, AML.M0027 Single-User AI Agent Permissions Configuration and AML.M0028 AI Agent Tools Permissions Configuration.

Pattern	When to use	Risk
Delegated user token (OAuth, narrow scopes)	Actions on a user's own mail, files, tickets or repositories	Lowest; the model can do no more than the user and only within the scope granted
Token exchange to a downscoped, short-lived token	Backend tools acting for a user across services	Low if audience and scope are narrowed per call; see the OAuth Token Exchange and Delegation Guide
Dedicated service identity per tool	Shared reference data, such as a product catalogue	Medium; must be read-only and scoped to named tables or endpoints
Shared application identity for all tools	Avoid	High; one injection reaches every system the app can reach
Account-wide or admin API token	Never for model-driven calls	Critical; this is the PocketOS failure

No credentials within the model's reach: tokens belong in a vault, injected by the tool runtime at call time. In the PocketOS database deletion a coding agent found an account-scoped Railway token in an unrelated file, which Railway said gave access to everything in the account, and used it to delete a production volume and its backups. See the Credential Vaulting for AI Agents Guide.
Separate production from development identities: in the Replit database deletion a code freeze existed only as a chat instruction while the agent held write access to production; Replit's fix was automatic separation of development and production databases.
Inventory each tool identity as an NHI: owner, scopes, rotation and the LLM feature that uses it. See the OWASP NHI Top 10 NHI5 Overprivileged NHI Guide.

Implementation steps

Catalogue tools and verbs: list every extension, MCP server and function the model can call, every operation each exposes, and the identity and scopes it runs with. Mark anything unused, inherited from a trial or open-ended.
Cut functionality: remove unused tools, split broad tools into narrow ones (read_inbox rather than mail_api), and replace shell, raw SQL and generic HTTP tools with purpose-built functions. Configure the runtime to deny unknown tools.
Cut permissions: move per-user actions to delegated OAuth with minimum scopes, make shared tools read-only, and replace any account-wide token. Enforce restrictions in the downstream system (database grants, API scopes, row-level security), not in tool descriptions.
Classify actions by risk: tier each operation low, medium, high or critical. The OWASP AI Agent Security Cheat Sheet recommends treating unmapped tools as high risk and letting only explicitly low-risk tools skip review.
Add approvals for high-impact actions: show the user the exact action, target and parameters; bind the approval to them; make it single use and short lived; and require re-approval if anything changes. Use step-up authentication for payments, permission changes and bulk deletion. See the Human-in-the-Loop for AI Agents Guide.
Enforce complete mediation: put a policy enforcement point between the model and tools that checks each call against the user's entitlements, the tool schema and rate limits. Treat MCP tool annotations such as a read-only hint as untrusted unless the server is trusted, as the MCP specification requires.
Make destructive actions reversible: prefer soft delete, staging areas and drafts. Railway moved its API to 48-hour soft deletes after the PocketOS incident.
Pilot and roll back safely: release new tools to an internal ring in suggest-only mode (the model proposes, a human executes), then to a pilot group with approvals, then generally. Keep a feature flag per tool so one tool can be withdrawn without taking down the application.

Choosing how much autonomy to allow

Action type	Small team, few users	Large organisation, regulated data
Read own data	Autonomous with delegated scope	Autonomous with delegated scope and logging
Draft content	Autonomous; user sends	Autonomous; user sends
Send, post or share externally	Approval per action	Approval per action plus rate limit and DLP check
Modify or delete records	Approval per action; soft delete	Approval with step-up; soft delete; second approver for bulk
Payments, permission or infrastructure changes	Do not expose to the model	Only through a separate workflow with its own authorisation

The cost of approvals is friction; the usual mistake is approving everything, which trains users to click through. Keep approvals for actions that are irreversible, external or high value, and make everything below that line safe by permissions instead. See the AI Agent Action Approvals and Spending Limits Guide.

Evidence and assessment

The overview guide's test is simple and worth repeating: for each tool, attempt an out-of-scope action and confirm the downstream system refuses it, not the prompt. Assessors should also see:

Design evidence: the tool catalogue with verbs, identities, scopes and risk tiers; approval policy per tier; data flow diagrams showing where authorisation is enforced.
Test evidence: red-team results using indirect prompt injection through every untrusted input (emails, documents, web pages, tool results) aimed at each high-risk tool; cross-user access tests; SAST and DAST in the pipeline, as OWASP strategy 8 suggests.
Runtime evidence: logs of every tool call with user, tool, parameters, risk class, authorisation outcome, approval ID and policy version, the fields the OWASP AI Agent Security Cheat Sheet lists for high-risk actions.

Metric	Target
Tools with a documented owner, identity, scope and risk tier	100 percent
Tool identities with write or delete rights not justified by a use case	Zero
High and critical actions executed without a bound approval	Zero
Denied tool calls per 1,000 sessions	Baselined; spikes investigated as possible injection
Approval rejection rate	Tracked; near zero suggests rubber-stamping, high suggests poor tool design
Open-ended tools (shell, raw SQL, generic fetch) in production	Zero, or each with a documented exception

Mapping to other frameworks

Framework	Reference	Relevance to LLM06
NIST SP 800-53 Rev. 5	AC-6 Least Privilege; AC-6(10) Prohibit Non-privileged Users from Executing Privileged Functions	Excessive permissions; model-driven calls must not reach privileged functions
NIST SP 800-53 Rev. 5	CM-7 Least Functionality	Excessive functionality: remove unused and open-ended tools
NIST SP 800-53 Rev. 5	AC-3 Access Enforcement; AC-5 Separation of Duties; IA-9 Service Identification and Authentication	Complete mediation, approver separation, authenticated tool identities
NIST SP 800-53 Rev. 5	AU-12 Audit Record Generation; SI-4 System Monitoring	OWASP's damage limiters
NIST CSF 2.0	PR.AA-05	Permissions managed and enforced with least privilege and separation of duties
OWASP ASVS 5.0	V8.2.1, V8.2.2	Function-level and data-specific access restricted to consumers with explicit permissions
MITRE ATLAS	AML.T0053 AI Agent Tool Invocation; AML.T0086 Exfiltration via AI Agent Tool Invocation; AML.T0101 Data Destruction via AI Agent Tool Invocation	Attacker use of tools the application exposes
MITRE ATLAS	AML.M0026, AML.M0027, AML.M0028	Permission configuration for privileged, single-user and shared-tool agents
OWASP Agentic Top 10	ASI02 Tool Misuse and Exploitation; ASI03 Identity and Privilege Abuse	Agentic counterparts for multi-step and delegated systems
ISO/IEC 27001:2022 Annex A	A.5.15 Access control; A.8.2 Privileged access rights	Policy basis for tool permissions and privileged tool identities

Common pitfalls

Policy in the prompt: "never delete anything" in the system prompt, with a delete-capable token behind the tool. Replit's freeze instruction is the textbook case.
One fat integration: adopting a third-party plugin or MCP server for one read operation and exposing all of its write operations too, OWASP's first example.
Service identity instead of the user: a per-user feature backed by an application account that can see every user's data, which turns any injection into cross-tenant access.
Unauthenticated or generic approvals: a confirmation the model can click itself, or a session-wide "allow all tools", which Embrace The Red warned about in 2023.
Trusting data channels: treating CRM records, tickets or web forms as safe input to a tool-using model. ForcedLeak began with text submitted through a public web form.
Relying on monitoring alone: logging tool calls without limiting them; OWASP is clear that logging and rate limits reduce damage but do not prevent it. Wider errors are listed in our Top 10 LLM Deployment Mistakes.

Practitioner checklist

Keep a catalogue of every tool, its operations, its identity, its scopes and its risk tier.
Remove unused, trial and open-ended tools; deny unknown tools by default.
Split broad integrations into narrow, single-purpose functions.
Use delegated user tokens with minimum OAuth scopes for per-user actions.
Make shared tool identities read-only and scoped to named resources; ban account-wide tokens.
Keep credentials in a vault, injected at call time, never readable by the model.
Enforce authorisation in downstream systems and a policy layer, not in prompts or tool descriptions.
Require bound, single-use, authenticated approvals for high-impact actions, with step-up for critical ones.
Prefer reversible actions (drafts, soft delete) and rate-limit state-changing tools.
Red-team each high-risk tool through indirect injection and log every call with its authorisation outcome.

OWASP LLM Top 10 LLM06 Excessive Agency Guide: Limiting What LLM Apps Can Do