Excessive Agency (LLM06): limit what an AI agent can do

What is Excessive Agency (LLM06:2025)?

It is the vulnerability that enables damaging actions in response to unexpected, ambiguous or manipulated model output, whatever causes the malfunction. OWASP lists hallucination and prompt injection among the common triggers.

The key point: the flaw lies in granting the model the power to act without guardrails rather than in the model getting something wrong. A model will occasionally be wrong, and an attacker will always be able to try manipulating it. What determines severity is what the agent can do when that happens.

OWASP identifies three root causes, which we follow through the rest of the article.

How do you reduce the agent's functionality?

Remove any tool the use case does not require, then reduce the functions of each tool you keep. OWASP asks you to minimize the extensions the agent can call and the functions each one implements.

A simple method, in three passes:

1. Inventory. List every tool, every exposed function and every connected MCP server. Tools added "just to try" are the most common.
2. Justification. For each one, write the business task that depends on it. No justification, no tool.
3. Splitting. Replace a general-purpose tool with several narrow ones: "read an invoice" and "create a credit note draft" beat "access the ERP".

Above all, avoid open-ended extensions: shell command execution, arbitrary URL access, free-form SQL. OWASP recommends granular tools instead. A tool that accepts any URL turns every injection into a possible exfiltration; a tool that accepts any SQL query turns the agent into a database client for the attacker. For MCP servers, see our MCP security page.

How do you reduce downstream permissions?

Give each tool the minimum rights on the system it reaches, and make the agent act with the rights of the user who called it. OWASP recommends executing actions in the user's context, with least-privilege scopes.

Typical cases to fix:

• One powerful service account: every request goes through an administrator account. A user with no special rights then obtains, through the agent, what they could not get alone.
• Overly broad OAuth token: the email triage agent holds full mailbox access when read-only would do. We detail this case in our article on agents connected to Gmail and Outlook.
• Read-write database for an analytics agent: a read-only account limited to the necessary views removes a whole class of incidents.
• Unrestricted network access: an agent that needs two APIs has no reason to reach the whole Internet.

How do you bound the agent's autonomy?

Put human approval in front of every high-impact action, and have the downstream system check rights rather than the model. OWASP insists on the second point: authorization is enforced in downstream systems, with complete mediation of each request.

To define what needs approval, ask three questions:

• Is the action irreversible (send, payment, deletion)?
• Does it touch a third party (customer, supplier, partner)?
• Does it involve sensitive data (health, finance, credentials)?

If the answer to any is yes, a human approves. Design the approval screen carefully: it must show the real action (recipient, amount, exact content) rather than a paraphrase generated by the model, otherwise the attacker can work on the paraphrase.

Also avoid approval fatigue. If the user has to confirm thirty actions an hour, they will click without reading. A few well-placed approvals beat many ignored ones.

What does a well-bounded agent look like?

Take a support agent that answers customers. Risky version: it reads all tickets, has write access to the customer database, can issue refunds and send emails. Bounded version: it reads only the current ticket and the relevant customer record, writes a draft, and proposes a refund that a human agent approves in an interface showing the exact amount.

In the second version, a successful injection in a ticket produces at worst a poor draft that a person will review. The difference lies in neither the model nor the prompt, but in what the architecture allows.

Which damage-limiting measures should you add?

Add logging, monitoring and rate limiting: they do not prevent the flaw, but they reduce what a hijack can cause. This is the distinction OWASP draws between prevention and damage limitation.

• Log every tool call with its parameters, the user and the content that triggered it.
• Rate limit: actions per minute and per hour, amount cap, recipient cap.
• Alert on deviations: first use of a tool, new recipient, unusual volume.
• Plan the stop: a kill switch and fast token revocation.

How do you test for Excessive Agency?

Test by looking for what the agent can do beyond its role, through the direct route (a user asks) and the indirect route (booby-trapped content asks). The goal is to prove or disprove that the limits hold outside the model.

A minimal test plan:

Play each test several times and check the API logs, not only the model's reply. Our prompt injection page details the indirect variant, the most productive in testing.

Document every finding with the exact sequence that produced it: the input, the tool called, the parameters and the effect. A finding you cannot replay is hard to fix and impossible to verify after the fix. Once the limits are in place, replay the same scenarios to confirm that each one now fails at the code level.

How do you have your limits validated by a third party?

Have the agent attacked by someone who did not define its limits: they will test the assumptions the team takes for granted. This is the core of an AI agent penetration test.

The Agent Red Team Express (1,900 EUR, 5 days) maps an agent's tools, permissions and autonomy points, then tries to exceed them with realistic scenarios. For a wider scope, the custom engagement is quoted on request, with a free 30-minute discovery call to frame the need.