AI assistants become much more useful when they can do more than answer questions.
Give one access to email and it can help manage a busy inbox. Connect it to documents and it can find information for you. Give it access to business systems and it may be able to prepare reports, update records or carry out routine tasks.
But every extra capability also increases what can go wrong.
The issue is commonly described as excessive agency: giving an AI system more abilities, permissions or autonomy than it actually needs. The harm appears when an unexpected, ambiguous or manipulated model output is allowed to turn into a real action.
Think about a new employee
If a new employee joined your company, you probably would not immediately give them permission to:
- delete every company file
- change payroll records
- approve invoices
- send messages as the CEO
You would normally give them the access needed for their role, then expand it when there is a reason.
AI agents deserve the same thinking.
This is simply the familiar security idea of least privilege: people, software and AI systems should have only the access required to perform their task.
Why agents change the equation
A normal chatbot mostly produces text.
An agent can potentially combine text generation with tools and permissions. It may be able to read private information, query databases, interact with websites, send messages or modify records.
That means a poor decision can have consequences beyond a bad answer.
Consider the instruction:
Find our overdue invoices and contact the relevant customers.
The task sounds simple, but the safest implementation may be much narrower than the most convenient one.
For this task, the agent may only need to read overdue invoices and customer contact details, prepare draft emails and ask a person to approve them. It probably does not need the ability to issue refunds, delete accounting records, export the full customer database or email every customer automatically.
That single example illustrates the three common causes identified by OWASP's LLM06:2025 Excessive Agency guidance.
Three ways an agent can have too much power
Too much functionality
The system has tools it does not need for the task.
In the invoice example, a connection that can issue refunds, delete records or export data gives the agent more ways to cause harm than a workflow that can only retrieve the necessary information and prepare a draft.
The safer approach is to expose only the functions the agent actually needs.
Too many permissions
The tool may be appropriate, but the credentials behind it are too powerful.
An agent that only needs to read overdue invoices should not use a full accounting administrator account if a narrower read-only role is available.
In practice, that granularity is not always offered. Some connectors inherit the permissions of the person who connected them, or offer broad read-write access rather than a task-specific role. Check what the integration actually allows before assuming it can be safely restricted.
Where possible, avoid running agents through an executive, shared administrator or other high-privilege login simply because it is easiest to set up. A dedicated identity with the minimum useful access creates a smaller blast radius if something goes wrong.
Too much autonomy
The system is allowed to perform consequential actions without enough oversight.
An agent that drafts ten customer emails is different from an agent that immediately sends ten customer emails.
The first creates something a person can review. The second makes the model's decision externally visible before anyone checks it.
For important actions, the safer default is often prepare first, approve second.
Why mistakes matter even without attackers
Excessive agency is not only an attack problem.
AI systems can misunderstand instructions, misread ambiguous data, use the wrong record or simply generate an incorrect answer. A harmless mistake becomes more serious when the system has broad access and permission to act.
The same security controls therefore help with both malicious manipulation and ordinary model error.
A system with narrow permissions may make a bad suggestion.
A system with broad permissions may turn the same bad suggestion into a deleted record, an external message or an unwanted financial action.
Connections widen the trust boundary
Every integration gives an AI another place it can read from, write to or act within.
That does not mean integrations should be avoided. It means they should be intentional.
Before enabling one, ask:
- Who is the agent logged in as? Is it inheriting a person's full account or using a narrower identity?
- What can it read and change? Is read-only or scoped access available, or does the connector require broader permissions?
- Can it act outside the organisation? Drafting is different from sending, publishing or paying.
- Can you see what it did? Useful logging and activity history make review possible after the fact.
More connected is not the same as better designed.
Human approval still matters
One useful control is to separate preparing an action from performing an action.
An agent might:
- identify the relevant records
- draft an action
- present it to a person
- execute only after approval
That creates a useful checkpoint before something consequential happens.
Human approval works best when it is reserved for genuinely important or externally visible actions. If every trivial step requires confirmation, people can become accustomed to clicking approve without reviewing what they are approving.
Good candidates for explicit confirmation include sending, paying, deleting, publishing, changing permissions or sharing information outside the organisation.
OpenAI's November 2025 prompt-injection guidance recommends limiting an agent's access to the data it actually needs and carefully reviewing consequential actions before confirmation. Its March 2026 article on designing agents to resist prompt injection makes the broader point that systems should constrain the impact of manipulation even if some attacks succeed.
These controls can make automation slightly less convenient. They also create opportunities to catch mistakes before those mistakes reach real systems.
The useful question is not “Can it?”
Modern AI systems can connect to an extraordinary range of tools and services.
That makes it tempting to enable every available capability.
A better question is:
Does this agent actually need this access to complete the task?
If the answer is no, removing that access can reduce risk without reducing the value of the task itself.
The goal is not to make AI agents powerless. It is to make their authority proportionate to the job they are being asked to do.
Key takeaways
- Excessive agency means an AI system can do more than its task requires, increasing the consequences of mistakes or manipulation.
- OWASP highlights excessive functionality, permissions and autonomy as common root causes.
- Least privilege applies to agents just as it does to people and software.
- Check the real permissions and identity behind a connector rather than assuming read-only or task-scoped access exists.
- Human confirmation is most useful for consequential actions, not every minor step.
- The practical question is not only what an AI can do, but what it genuinely needs to do.
A note on changing products
Agent permissions, connector designs and approval controls can change quickly. securedby.ai re-opened and reviewed the sources above on 14 September 2026. Recheck current product and standards documentation before making a high-stakes security decision.