What it means
Excessive agency means a model-using application has more ability to act than its task needs. A tool may expose unnecessary functions, use an identity with broad permissions, or execute a consequential proposal without independent approval. Unexpected output can trigger the harm even without a malicious prompt. Keep the tool functions and credentials narrow, check every action outside the model, and bind any required approval to the exact action and arguments. OWASP’s Version 2026 lists this as LLM03:2026; its 2025 identifier was LLM06.
The idea at a glance / AI & agents
A drafting task should not carry payment authority.
Compare the same unintended payment proposal under broad and narrowly scoped tools.
A freight clerk asks for a draft about I211: Supplier A, USD 100. A selected unexpected output proposes paying Supplier B instead. Compare two synthetic applications with the same task and proposal: one exposes a broad payment tool with no approval check; the other permits only this invoice read and draft. No prompt injection is required for excessive agency.
READ THE PICTURE
Same proposal, different authority
The broad tool queues the unintended USD 100 payment. The scoped tool refuses it while keeping the legitimate draft available.
Keep in mindThe selected output is predetermined, not a live model result. Trusted identities and independently stored grants/approvals are assumed. The local exercise creates only synthetic payment queue and balance records; it contacts no bank, sends no email and transfers no real funds. Queue acceptance and a held balance do not establish settlement. Narrowing this one task does not prove every agent workflow safe.
Read the complete example
- Same proposal, different authority. The broad tool queues the unintended USD 100 payment. The scoped tool refuses it while keeping the legitimate draft available. I211 names Supplier A and USD 100. The clerk requested a draft, not payment. A predetermined proposal selects Supplier B with the same amount. The broad identity can call payment for any invoice, and its service omits independent approval, so POST records P211, marks I211 queued and holds USD 100 from the USD 1,000 synthetic balance. Fresh GETs retrieve those records; bank settlement remains unknown. In the scoped application, the assistant can read only I211 and save only its D211 draft. Its payment call returns 403, fresh GETs retain USD 1,000 and no P211, and the allowed draft still saves. A separate payment executor would additionally require an unexpired trusted approval binding executor, invoice, payee, amount and currency. A post-story counterfactual verifies that exact approval can permit the intended Supplier A call while altered amount, payee, invoice or expired approval cannot. Model confidence and client claims do not create those records. Functionality, permissions and autonomy are separate controls, not assurances supplied by a prompt.
The selected output is predetermined, not a live model result. Trusted identities and independently stored grants/approvals are assumed. The local exercise creates only synthetic payment queue and balance records; it contacts no bank, sends no email and transfers no real funds. Queue acceptance and a held balance do not establish settlement. Narrowing this one task does not prove every agent workflow safe.
Diagram references: OWASP 2026: LLM03 Excessive Agency
AN ILLUSTRATIVE SCENARIO
A draft request with payment powers
The clerk asks for a draft for Supplier A’s I211, USD 100. A selected unexpected proposal names Supplier B instead. A broad tool with company-wide payment authority queues that call without approval. A scoped tool refuses it and still saves the intended draft. Fresh application reads show the different queue and balance results. The local comparison moves no real money, and queue acceptance does not prove settlement.
Put it to work
- List every tool the application can call, the functions inside each tool, and the credential each call presents. Write the blast radius as whose mail, records, or money that credential can change.
- Drop functions the task does not need, replace open-ended tools with specific ones, and check every call in policy code.
- Require a named person to approve high-impact or hard-to-reverse actions after seeing the exact arguments, and log the tool call separately from the model’s draft.
How to check your work
In a synthetic exercise, submit the same unintended proposal to both tool configurations. Check the effective downstream grants and independently read the resulting records, then confirm ordinary drafting still works. For a separate executor, verify that only an unexpired trusted approval binding executor, invoice, payee, amount and currency can permit payment; altered arguments and client approval claims must fail.
Connect the ideas
- Prompt injection
An attack that inserts instructions into model input so the model follows attacker text instead of the developer’s policy.
- Least privilege
Granting each identity only the actions, objects, and time window required for the current job.
- Authorization
The decision about whether a person, device, workload, or anonymous requester may perform a particular action on a resource.