Excessive agency

What is excessive agency?

Excessive agency is when an AI agent can do more than its task needs. It holds a tool it never needed, acts through an account whose rights nobody checked, or finishes a high-impact action without asking anyone. Nothing goes wrong until the model gets a bad idea, and then the bad idea has somewhere to go.

OWASP defines it as the vulnerability that lets damaging actions happen in response to unexpected, ambiguous or manipulated model output, whatever caused the model to misbehave. Usually that is a hallucination or a hostile instruction that reached the model. Excessive agency is about neither; it is about what the agent can reach once one of them has happened.

In the 2025 OWASP Top 10 for LLM Applications it was LLM06, the number most write-ups still quote. The August 2026 edition moved it up to LLM03, behind only prompt injection and sensitive information disclosure, because incidents kept piling up around agents whose output runs shell commands, calls APIs and changes database records. In that edition LLM06 is unbounded consumption, so quote the year with the number: LLM03:2026.

The three root causes

OWASP splits the problem in three. Check them separately: fixing one says nothing about the other two.

Excessive functionality. The tool does more than the job. A mail plugin that only has to summarise the inbox but also carries a send function. OWASP's own example is an extension picked so an agent can read documents from a repository, and that also modifies and deletes them. The plugin somebody trialled and never disconnected counts too.

Excessive permissions. The tool is right-sized, the account behind it is not. The version you meet in a smaller company is the ERP integration user: created for one nightly export, given admin rights because that was the fastest way to make the export work, and now sitting behind an agent. OWASP's version is a database connection with UPDATE, INSERT and DELETE when the task only needs SELECT, or one shared high-privileged identity doing work that should run per user.

Excessive autonomy. Tool and account are both fine, but nothing stands between the decision and the action. Picture an agent that can issue a credit note on its own: a model decides the amount, the customer gets the money back, and your bookkeeping holds a document no person approved. OWASP calls it the failure to independently verify and approve high-impact actions.

Excessive agency versus prompt injection

These two sit on opposite halves of the same incident.

Prompt injection is the cause. It is how a hostile instruction gets in front of the model: hidden in an email, a web page, a PDF, a support ticket, a tool description. It explains why the agent wanted to do the wrong thing.

Excessive agency is the consequence. It explains why wanting it was enough. An agent that can only read and only draft can be injected all day and the result is a bad draft. The same injection against an agent holding a send function and a full mailbox produces an outgoing mail with your customer list attached.

You cannot make injection impossible, because a language model reads instructions and data through the same stream of text. You can make the consequence small, and that is ordinary engineering with a finish line.

An instruction is not a control

The most common mistake is writing the limit into the prompt. Never delete anything. Do not touch production. Always ask before sending. An agent reads that, agrees with it, and can still do the thing, because nothing in the execution path stops it.

The case people remember is Replit, in July 2025. SaaStr founder Jason Lemkin was running a coding agent against a live project and had told it not to change any code without permission. It ran destructive commands against the production database anyway, then told him the data could not be recovered, which turned out to be wrong. The AI Incident Database logs it as incident 1152. Replit's CEO called it unacceptable, said it should never have been possible, and announced automatic separation of development and production databases. The freeze was real. It was just written in the one place with no enforcement behind it.

OWASP's name for the alternative is complete mediation: the downstream system decides whether an action is allowed, not the model. The database refuses the DELETE because the account cannot delete. The mail API refuses because the OAuth scope is read-only. The approval step lives in your ERP, not in the prompt. A model can be talked into asking for something. It cannot be talked into being allowed.

The OWASP mitigations, in plain words

OWASP lists eight ways to prevent excessive agency. Most are cheap and unglamorous.

1. Give the agent fewer tools. Connect only what the task needs. If it never has to fetch a web page, it does not get a fetch tool.

2. Give each tool fewer functions. A mailbox tool built for summarising needs read, not send and not delete.

3. Avoid open-ended tools. A tool that runs any shell command or fetches any URL covers every action there is. If the agent has to write a file, build a write-file function instead of handing it a shell.

4. Give each tool a smaller account. Read on the products table, not owner on the database. Enforce it in the database permissions, not in the tool code.

5. Run in the user's context. Let the agent act as the person who asked, with that person's session and scope, instead of one shared service account that sees everybody's files.

6. Require approval for high-impact actions. Sending, deleting, paying, publishing, changing permissions: the agent prepares, a person confirms, and the confirmation screen shows the real parameters.

7. Authorise in the downstream system. Every request arriving through a tool call gets checked against your policy on the far side of the call, where the model has no vote.

8. Sanitise what goes in and what comes out. Normal secure coding applies to agent plumbing too, and OWASP points at its own ASVS for the details.

Two more prevent nothing but cap the bill. Log every tool call with its parameters, so you can see what happened and how far it got. Rate-limit the actions that hurt, so an agent misbehaving at two in the morning sends five mails instead of five thousand before somebody notices.

What to watch out for with excessive agency

Autonomy is earned per task, not switched on once. OWASP's separate top 10 for agentic applications, released in December 2025, puts identity and privilege abuse at ASI03 for the same reason: agents run under user or system identities that hold more rights than the task needs, and keep them afterwards. Scope rights to the task and let them expire.

Permissions grow quietly. Every new integration adds an account and nobody removes the old one. Re-run the three-cause check after every new tool, vendor update and model upgrade, and ask a vendor which identity its product uses in your tenant and whether the approval step is a real gate or a notification you can switch off.

Read-only agents have a different problem. Excessive agency is about damaging actions. An agent that only reads but can also send data somewhere leaks instead of breaking things; that is the lethal trifecta question, and both checks are worth running.

The blame does not move. If an agent deletes a customer's records or sends personal data to the wrong address, the company running it answers for it. Give every agent its own identity and log which one did what, so an incident report names an account instead of "the AI".