An AI agent becomes a very different security problem when it can do things instead of only answering questions. Reading a document is one capability. Editing a database, sending an email, deleting a file or approving a transaction is another.
The important question is not simply whether an agent is intelligent enough to perform a task. It is whether the system has given the agent more power than that task requires.
This is the problem known as excessive agency. OWASP describes it as a situation where an LLM-based system can perform damaging actions because it has excessive functionality, excessive permissions or excessive autonomy. The problem can become visible when a model makes an unexpected decision, is manipulated through prompt injection, or simply makes a mistake. OWASP’s guidance on excessive agency provides the underlying security model.
What does excessive agency actually mean?
Imagine an internal AI assistant whose job is to help employees find information in a document repository. The agent needs to search and read documents. During development, however, the selected connector also gives it permission to upload, edit and delete files.
The assistant may work perfectly for months without deleting anything. The security problem still exists because the system has created a larger capability boundary than the business task requires.
Excessive agency can be understood through three questions:
- What can the agent call? This is functionality.
- What can those tools access or change? This is permission.
- How freely can the agent decide to act? This is autonomy.
A system can have a problem in any one of these areas, or in all three.
Excessive functionality: the agent has tools it does not need
The first mistake is giving an agent unnecessary tools.
Suppose a support agent only needs to look up an order and prepare a response. Giving it a tool that can also cancel orders creates an avoidable security boundary. Even if the model has been instructed never to cancel an order, the capability is still available.
Removing unnecessary tools is often more reliable than adding more instructions to the prompt. A model instruction says what the model should do. Tool availability determines what the surrounding system allows it to attempt.
A useful design question is therefore:
If this tool disappeared tomorrow, would the agent still be able to complete its intended task?
If the answer is yes, the tool deserves review before being exposed to the agent.
Excessive permissions: the right tool has the wrong authority
Sometimes an agent genuinely needs a tool, but the credential behind that tool is too powerful.
Consider an agent that needs to read a customer’s support ticket. It probably does not need database administrator privileges. It may not even need access to every customer’s tickets. The required permission might be limited to a particular application, tenant, operation and data set.
This is the familiar principle of least privilege applied to an AI-enabled application.
The goal is not to make the agent incapable. The goal is to make the consequences of a compromised, manipulated or mistaken agent smaller.
For example, a reporting agent might be allowed to:
- read approved sales data;
- calculate summaries;
- create a draft report;
- save the draft in one designated location.
It might not need permission to:
- delete source records;
- change prices;
- modify user accounts;
- send external messages;
- access unrelated departments.
This distinction is especially important when a single agent is connected to many business systems.
Excessive autonomy: the agent decides too much by itself
Even a carefully scoped tool can become risky if the agent is allowed to execute high-impact actions without appropriate checks.
A useful distinction is between planning and execution. An agent can be very good at preparing a proposed action while the final action is still controlled by deterministic software or a human approval step.
For example, an AI assistant might prepare a refund recommendation. The application can then verify the order, amount, policy and customer eligibility before the refund API is called.
That design does not require the model to be perfectly reliable. It places the security decision outside the model.
OWASP’s AI Agent Security guidance similarly identifies excessive autonomy and high-impact action abuse as risks that need independent controls.
Prompt injection makes excessive agency more dangerous
Prompt injection is one reason excessive agency deserves attention even when the agent appears well behaved.
An agent can consume content from emails, web pages, documents, tickets or other external sources. Some of that content may contain instructions that were not intended to control the agent. If the model treats those instructions as part of its task, it may choose a tool action that the developer did not expect.
If the agent has only a read-only search capability, the result may be limited. If the same agent has permission to delete files, change access rights or send external messages, the potential impact is much larger.
This leads to a practical security principle:
Assume the model can be manipulated, then make the tool boundary safe anyway.
That is stronger than relying on a system prompt to say “never delete anything”.
A safer agent architecture
A practical architecture can separate model reasoning from security enforcement:
- The user authenticates to the application.
- The application creates a task and defines its allowed scope.
- The agent receives only the tools required for that task.
- The model proposes an action.
- A policy layer checks the identity, resource, action and context.
- High-impact operations require stronger approval or additional validation.
- The protected service enforces the final authorization decision.
- The action and its security context are logged.
The model can still make decisions about how to complete a task. It simply does not become the component that grants itself authority.
This pattern also complements the identity and authorization model discussed in the earlier article AI Agent Identity and Authentication.
Reduce the blast radius, not just the probability of failure
Security design often focuses on preventing an unwanted action. With autonomous systems, it is also useful to ask what happens if prevention fails.
Suppose an agent is tricked into making an API call. If its credential is limited to one customer record and one operation, the incident may remain contained. If it has organization-wide administrative access, the same model failure can become a major security event.
This is the idea of blast-radius reduction.
Useful boundaries include:
- short-lived credentials;
- per-task authorization;
- read-only access where possible;
- separate credentials for separate tools;
- tenant and resource isolation;
- explicit approval for irreversible actions;
- rate and transaction limits;
- network restrictions around sensitive services;
- logging and rapid revocation.
These controls are valuable because they do not depend entirely on the model behaving correctly.
Do not confuse hidden tools with secure tools
A common prototype pattern is to hide dangerous tools from the user interface while leaving them available to the agent internally. This does not create a strong security boundary.
If the model can invoke a capability, the system should treat that capability as part of the agent’s effective attack surface.
Likewise, renaming a function from delete_file to manage_file does not make the underlying authority safer. The permission boundary should be enforced by the service receiving the request.
Test the agent as a security boundary
Security testing should include both expected and manipulated workflows.
For each tool, ask:
- Can a normal user trigger it through an unexpected task?
- Can untrusted content influence when it is called?
- What happens if the model requests an action outside the task scope?
- Does the backend independently enforce authorization?
- Can the agent access another tenant’s data?
- Can a read operation become a write operation through parameters?
- Are irreversible actions protected by additional controls?
- Can the credential be revoked quickly?
Testing should be performed only against systems the tester owns or is authorized to assess. The objective is to discover whether the security boundary survives an unreliable or manipulated model.
A practical checklist for developers
Before giving an AI agent access to a real system, review:
- Tools: Is every tool necessary?
- Permissions: Is every permission necessary for the task?
- Autonomy: Which actions can happen without human or deterministic approval?
- Credentials: Are access tokens scoped and short-lived where practical?
- Backend enforcement: Does the target service enforce authorization independently?
- Data boundaries: Can the agent cross tenants, users or departments unnecessarily?
- Impact controls: Are high-impact actions limited by amount, frequency or destination?
- Logging: Can investigators reconstruct what the agent attempted and why?
- Revocation: Can access be removed quickly?
- Failure mode: What is the worst reasonable outcome if the model is fully manipulated?
The main lesson
Giving an AI agent more power does not automatically make it more useful. In many systems, unnecessary authority simply increases the consequences of a model mistake or successful prompt injection.
The safer approach is to design the agent around the smallest useful set of tools, permissions and autonomy. Let the model plan and reason, but keep identity, authorization and high-impact enforcement outside the model.
The goal is not to make autonomous systems harmless by assumption. It is to make their authority deliberate, bounded and observable.