Excessive agency is a system being able to do more than the feature it serves requires. The idea is old, since the principle of least privilege was written down in 1975 and the confused deputy, a program with authority acting on behalf of a caller who should not have it, was described in 1988, and an agent with tools is the confused deputy built at scale. OWASP gave the failure its current name in 2023, and it sits third on the 2026 list for LLM applications as the fastest riser on it, because products stopped producing text for people to read and started carrying out work on their behalf.
The sections below take the three forms, explain why the permissions set the blast radius, set out how the agency is designed down and end with a ten minute worksheet against a real tool list.
The three forms
Excessive functionality. A tool that can do more than the feature needs. A database tool that can write when the feature only ever reads, or a file tool handed a whole directory because that was the example in the documentation. Functionality nobody uses is still functionality an attacker can call.
Excessive permissions. Credentials broader than the task. The tool itself is scoped correctly and the token behind it reaches every tenant, or writes to tables the feature never touches. This is the commonest of the three, because permissions are usually inherited from whatever the team already had lying about and nobody designed them for the feature.
Excessive autonomy. A consequential action proceeding without anybody confirming it. Refunds issued, messages sent, records deleted, all because a chain of reasoning arrived there and nothing in the path required a person.
Why the permissions set the blast radius
The reason this category matters more than its old sixth place suggested is that it is the one control still standing when everything else has failed. Suppose the injection lands, the filter misses it and the guardrail is talked around. What happens next is decided entirely by what the system was permitted to do, and how good the model is has no bearing on it.
The incidents bear this out. In July 2025 a widely reported case had a coding agent delete a company's production database during a declared code freeze, then describe what it had done inaccurately. Every account of the incident focused on the model's behaviour, and the whole of the damage was set by the fact that the agent held a credential able to drop production tables at all.
That makes permission design the security work with the best return per hour. Teams reach for model quality first because it feels like progress, and reach for permissions last because it feels like paperwork, which is precisely the wrong way round.
It is also the one control a reviewer can actually verify. Nobody can audit whether a model will resist the next phrasing somebody invents, and anybody can read a tool definition alongside the policy attached to its credential and say out loud what the worst outcome is.
Designing the agency down
Five practices bring the three forms down, and each one is legible in a config file.
Scoped tools with narrow interfaces. One tool per job, taking the smallest set of arguments that job needs. A call shaped like refund_order(order_id) is a tool, and one shaped like run_sql(query) is permission to do anything.
Per action authorisation, with no standing token. A credential is requested scoped to this action, this resource and this moment, so that a compromised sequence cannot reuse it for the next thing it thinks of.
Read paths separated from write paths. Different tools, different credentials, ideally different services. Most agent features are mostly retrieval with one or two actions at the end, and the mostly part should carry no ability to change anything at all.
Confirmation for anything irreversible or costly. Money leaving, data being deleted, a message reaching a customer. A workable test is whether a new support agent would be allowed to do it unsupervised on their first day.
Full logging of tool calls. Every call, its arguments, what triggered it and what came back. Without that record an incident cannot be reconstructed, and the first question after any agent failure is what it actually did, which is a different question from what it said it did.
Practise this
The exercise needs one feature that is live or close to it, with its tool definitions open. Ten minutes, reading the definitions themselves and leaving the design document closed.
Fill in one row per tool, then answer the question underneath.
Feature: refund assistant
tool | what it reaches | reversible | confirmed | credential
---------------|-------------------------|------------|-----------|-------------------
search_orders | all orders, read only | n/a | n/a | read, all tenants
issue_refund | payments | no | no | write, all tenants
send_email | any customer address | no | no | write
update_ticket | the ticket in this chat | yes | no | write, one ticket
For every row where reversible is "no" and confirmed is "no", write one
sentence describing the worst thing that row does if a document the model
read told it to.
Look first at the rows where the credential column is wider than the reach column, because that is excessive permission stated plainly in the team's own handwriting. Then count the rows that are both irreversible and unconfirmed, which is the honest size of the blast radius. Most teams find at least one tool that exists only because it was convenient during development.
The worksheet teaches that the exposure is a property of a list the team can read and edit today, and the model whose behaviour can only be estimated has less to do with it than anyone assumed.