Excessive Agency in AI Agents:When Your AI Has Too Much Power
What Is Excessive Agency in an AI System?
Agency, in the context of AI agents, means the ability to take actions in the real world: calling APIs, reading and writing files, sending messages, executing code, and making changes to external systems. Excessive agency means the agent has been given more of this ability than its task requires.
A human analogy: a new employee who needs to read customer records for support purposes does not need to delete records, create new admin accounts, or transfer funds. Giving them those permissions would be a security risk regardless of how trustworthy they are. Giving an AI agent those same permissions, when its task only requires reading, is excessive agency. The agent may be entirely well-behaved, but the permissions exist and can be exploited.
What Are the Three Dimensions of Excessive Agency?
OWASP identifies three distinct ways that excessive agency can appear in an AI system. All three need to be assessed and addressed.
| Dimension | The Problem | Example of Excess | Correct Scope |
|---|---|---|---|
| Excessive functionality | The agent has access to tools or functions it does not need for its task. | A summarisation agent that also has access to the email send tool. | A summarisation agent that can only read documents and return text. |
| Excessive permissions | The agent's tools have broader permissions than the task requires. | An agent with read-write database access when the task only requires reading. | Read-only database access scoped to the specific tables the task uses. |
| Excessive autonomy | The agent takes irreversible or high-impact actions without human confirmation. | An agent that sends emails, deletes records, or calls payment APIs without approval. | Irreversible actions require a human confirmation step before execution. |
Why Is Excessive Agency So Dangerous When Combined With Prompt Injection?
Excessive agency and prompt injection are the most dangerous combination in agentic AI security. Understanding why helps explain why limiting permissions is the most effective single security control available.
An agent with minimal permissions can be successfully attacked through prompt injection, but the attacker is limited to what the agent can actually do. If the agent can only read a specific table in a specific database, the attacker is limited to reading that table. The blast radius of the attack is contained by the agent's permissions.
An agent with excessive permissions, injected through the same vector, causes far greater harm. The attacker does not need to find a separate vulnerability for each capability they want to exploit. Every permission the agent holds becomes available to the attacker after a single successful injection. This is why reducing the agent's permissions is effective even before prompt injection defences are applied: you cannot always prevent injection, but you can control how much damage a successful injection causes.
What Is the Principle of Least Privilege for AI Agents?
The principle of least privilege states that any system, user, or process should have exactly the permissions it needs to do its job, and no more. For AI agents, this principle applies at three levels: what tools the agent has, what those tools are permitted to do, and what actions the agent can take without human approval.
Applying least privilege to an AI agent is a different challenge from applying it to a traditional service account. A service account's permissions are defined once and rarely change. An agent's task may vary, and different tasks may require different tools. The practical solution is to scope the agent's permissions to the current task, not to the maximum task it might ever need to perform.
| Tool Type | Least Privilege Approach | What to Avoid |
|---|---|---|
| File system | Read-only access to a specific directory relevant to the task. | Full filesystem access or write access when reading is sufficient. |
| Database | Read access scoped to the specific tables the task requires. | Write access or access to tables outside the task's scope. |
| Read access to the inbox for summarisation tasks. | Send access unless the task explicitly and necessarily requires sending emails. | |
| Web search | Fetch permission for a defined set of trusted domains when possible. | Unrestricted web browsing, which allows retrieval from attacker-controlled sites. |
| Code execution | Sandboxed execution with no network access and limited filesystem scope. | Unrestricted shell access or execution with the agent's own credentials. |
| External APIs | Scoped API keys that allow only the specific operations the task requires. | Full API keys that allow all operations including account deletion or billing changes. |
Which Agent Actions Should Require Human Approval?
Not all agent actions carry the same risk. The key question to ask for each action is reversibility: can this be undone in under five minutes if it turns out the agent was wrong or was manipulated? The harder an action is to reverse, the more it warrants human oversight before execution.
| Action Category | Risk Level | Recommendation |
|---|---|---|
| Read-only data access (internal systems) | Low | No approval required. Log all accesses. |
| Read-only web retrieval (trusted domains) | Low | No approval required. Log URLs fetched. |
| Writing to internal documents or databases | Medium | Require confirmation for writes affecting more than a limited scope. |
| Sending messages (email, Slack, SMS) | High | Always require human review before sending. Show a draft for approval. |
| API calls that change external state | High | Require human confirmation. Describe the exact change being made. |
| Financial transactions or payments | Critical | Never execute without explicit human authorisation and a full audit trail. |
| Deleting data, files, or accounts | Critical | Always require explicit human confirmation with a preview of what will be deleted. |
| Creating user accounts or changing permissions | Critical | Require human approval with a full description of the permission change. |
How Do You Audit Your Agent's Current Permission Scope?
Auditing an agent's permissions requires looking at both the tool definitions and the actual API keys or credentials the tools use. The tool definition may be labelled read-only, but if the underlying credential has write access, the agent effectively has write access. These two must be checked independently.
- 1List every tool the agent has access to. For each one, ask: does the current task genuinely require this tool?
- 2Check the actual permissions of each tool's underlying credential, not just the tool definition label.
- 3Identify every action the agent can take without human confirmation. Ask: what is the worst-case impact if this action is triggered by a successful injection?
- 4Classify each tool action by reversibility. If it cannot be undone in under 5 minutes, require human approval.
- 5Check whether the agent's credentials are scoped to specific resources (a specific S3 bucket, a specific database table) or are account-wide.
- 6Verify that all tool calls are logged with full inputs, outputs, and timestamps for post-incident investigation.
- 7Test what happens when you prompt the agent to use a tool it should not have. If it succeeds, that tool's access needs to be removed or restricted.
- 8Check whether any tool gives the agent indirect access to credentials or secrets, such as reading environment configuration files.