Excessive agency is a system being able to do more than the feature it serves requires. It sits third on the 2026 OWASP list for LLM applications and is the fastest riser on it, because products stopped producing text for people to read and started carrying out work on their behalf.
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 rather than designed 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.
Blast radius is not a property of the model
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 not at all by how good the model is.
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 it down
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 rather than a standing token. Request a credential 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 rather than what it said it did.
Practise this
You need one feature that is live or close to it, with its tool definitions open in front of you. Ten minutes, and read the definitions themselves rather than the design document.
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 your own handwriting. Then count the rows that are both irreversible and unconfirmed, which is the honest size of your blast radius. Most teams find at least one tool that exists only because it was convenient during development.
The worksheet teaches that your exposure is a property of a list you can read and edit today, rather than of a model whose behaviour you can only estimate.