Permissions and approvals for AI agents: avoiding excessive agency

By Wladimir Neuberger · Updated 27 Oct 2026

The short answer

An AI agent should have only the functions, permissions and autonomy its task strictly requires. OWASP calls the opposite “Excessive Agency” (LLM06:2025). What works: few, narrowly scoped tools, access in the user’s context, human approval for consequential actions, plus logging and rate limiting of actions.

What “Excessive Agency” means

Developers often give systems built on language models agency: they can call functions or interact with other systems through extensions. Vendors call these extensions tools, skills or plug-ins. In agent systems even the choice of extension can be left to the model, which makes repeated calls based on earlier outputs.

Excessive Agency (LLM06:2025 in the OWASP list of the ten biggest risks for applications built on language models) describes the vulnerability that enables damaging actions in response to unexpected, ambiguous or manipulated model outputs, regardless of what caused the malfunction. OWASP names as triggers, among others, made-up content (hallucination) and direct or indirect prompt injection, including through a compromised extension or a compromised peer agent. The consequences can affect confidentiality, integrity and availability, depending on which systems the agent can reach.

Three root causes

OWASP traces Excessive Agency back to three roots. Knowing them helps you find quickly where your own environment needs work.

Excessive functionality: extensions include capabilities the application does not need, such as a document-reading tool that can also modify and delete, or a trial tool that is no longer needed but remains available to the agent.
Excessive permissions: extensions hold more access on downstream systems than required, for example a read-only tool connecting with a database identity that can also update, insert and delete, or a generic high-privilege account that can reach all users’ files.
Excessive autonomy: the system performs consequential actions without independent verification or approval, for example deleting a user’s documents without asking.

OWASP’s example scenario: a personal assistant with mailbox access is meant only to summarise incoming email but can also send. An indirect prompt injection hidden in an email could direct it to search the inbox for sensitive data and forward it. OWASP suggests limiting the tool to reading, using a read-only OAuth scope and having the user send every drafted email manually.

Limit functions and permissions

The following five measures follow OWASP’s recommendations for LLM06:2025. They work because they do not depend on the model’s behaviour.

Minimise extensions: offer only what the agent strictly needs. If the system has no use for web access, it gets no URL-fetching tool.
Minimise functionality: a tool for summarising email reads mail; it does not delete or send it.
Avoid open-ended tools: granular tools are safer than general ones such as shell or URL access. A dedicated file-writing tool is safer than a shell used to write files.
Minimise permissions: a recommendation agent that reads a products table may neither modify data nor see other tables. This is enforced through the rights of the database identity, not through the prompt.
Run in the user’s context: each user’s authorisation and scope is tracked so that actions run with that user’s minimal rights, for example through OAuth with the narrowest possible scope.

Approvals and autonomy

Permissions answer what an agent can do. Approvals answer what it may do on its own. OWASP recommends involving a human for consequential actions, either in the downstream system or in the extension itself; a tool that posts to social media should ask the user for approval first. Just as important is complete mediation: authorisation is enforced in the downstream system rather than leaving it to the model to decide whether an action is allowed. Every request from an extension is validated against the security policy.

As a guide to when approvals are needed, the “Agents Rule of Two” that Meta proposed in October 2025 is useful. According to it, an agent should satisfy no more than two of three properties in a session: processing untrusted input, accessing sensitive systems or private data, and changing state or communicating externally. If a task needs all three, the agent should not run autonomously but under supervision, for example with human approval. The NCSC likewise advises preferring deterministic, non-model safeguards that constrain actions rather than relying only on filtering inputs.

Our recommendation: actions that cannot be undone require approval — deleting, paying, sending to external parties and changing access.
Our recommendation: the approval shows the reviewer exactly what will happen, such as recipient, amount or affected records, and not just “confirm action”.
Our recommendation: the approval is enforced in the application. An instruction in the prompt to ask first does not replace it.

What matters is where the boundary is enforced: in the target system and the application, not in the model’s decision.

Log, throttle, switch off

OWASP explicitly lists two measures that do not prevent Excessive Agency but limit the damage. We add the third as a recommendation.

Logging and monitoring: record the activity of extensions and downstream systems so that undesirable actions are detected and can be responded to. The NCSC names, among other things, tool and API calls and failed calls, which can indicate probing.
Rate limiting: undesirable actions are slowed so that there is time to detect them before significant harm occurs. In OWASP’s email example this can reduce the damage via the sending interface.
Kill switch (our recommendation): you need a documented way to stop an agent immediately and revoke its credentials. Test it before you need it.

Where to start

We build AI agents ourselves, for example CITT, a voice agent connected to calendar and CRM. The following order is our recommendation for any agent project, not a statement from a source.

List every tool and credential of each agent and ask for each tool: does the task really need this?
Reset access to the minimum: read-only where reading is enough, with its own identity per agent and, where possible, in the context of the respective user.
Decide which actions require approval and enforce that approval in the application.
Set up logging, rate limiting and a kill switch, and walk through the procedure once.

Frequently asked questions

What is Excessive Agency?

A vulnerability from the OWASP 2025 list (LLM06): a system with a language model has more functions, permissions or autonomy than necessary and can therefore perform damaging actions in response to unexpected or manipulated model outputs.

Which actions should require human approval?

OWASP recommends approvals for consequential actions. Our recommendation: anything that cannot be undone, such as deleting, paying, sending to external parties and changing access.

Is it enough to forbid the agent in the prompt from doing something?

No. OWASP recommends enforcing authorisation in the downstream system rather than leaving it to the model to decide whether an action is permitted. Prohibitions in a prompt can be bypassed through errors or manipulation.

How are permissions related to prompt injection?

As things stand, prompt injection cannot be reliably prevented. Limited permissions and approvals therefore determine how large the damage can become when an attack succeeds.

Sources

This assessment rests on the publications listed. Check the original source before making decisions.

Keep reading

Want to know where you stand?

A Basic Scan shows where your systems can be attacked from the outside — fixed price, with a report. Or get warned about new flaws for free.

View the security packages Subscribe to alerts Get in touch