Imagine your company sets up an AI assistant to read the admin team's inbox. You ask it to summarise emails and draft replies. To make it work, whoever configures it gives it the usual all-purpose mailbox permission: read, send and delete. Nobody argues, because it is the quickest option. The trouble starts the day the assistant does something nobody asked for, using every permission you gave it.

◢What is excessive agency in an AI agent?

An AI agent is an assistant that does more than answer: it reads files, queries a database, sends emails, creates tasks. Those abilities come from tools or extensions.

According to OWASP, excessive agency is the vulnerability that lets damaging actions happen in response to unexpected, ambiguous or manipulated output from the model. What matters is that the cause of the failure is irrelevant. It can be a hallucination, a weak model or a prompt injection attack. If the agent has the power to do harm, it does so as easily as it does its job.

◢The three causes: too many functions, too many permissions, too much autonomy

OWASP says the root is usually one of these, or several together.

Too many functions. The tool you give the agent can do more than it needs to. One OWASP example is a document-reading extension that can also edit and delete documents. Another is a trial tool that was left installed after it stopped being used and is still available to the agent.

Too many permissions. The tool has more access than necessary to the systems behind it. OWASP illustrates this with an extension that should only read data but connects to the database with an identity that can also write and delete. Or one that works for a single user but signs in with a privileged account that can reach everyone's files.

Too much autonomy. The agent carries out high-impact actions without anyone confirming them. OWASP's example is a tool that deletes user documents without asking.

◢What does it look like in an ordinary company?

Three hypothetical scenarios, not real cases.

In accounting, an assistant that reads invoices and files them. If it can also move or delete files in the shared folder, a misclassification stops being a text error and becomes documents that vanish.

In customer support, a chatbot that checks order status. If it logs into the CRM with an admin account to do that, a customer who manages to manipulate it could end up seeing other people's data.

In HR, an assistant that screens CVs. A CV can contain text hidden for the model, and if the assistant can reach more information than it needs, that door stays open.

OWASP's own example is the clearest: a personal assistant reads email through an extension that can also send. An attacker emails hidden instructions, the agent follows them, searches the inbox for sensitive information and forwards it to another address.

◢Is it the same as prompt injection?

No. Prompt injection is one way of tricking the model. Excessive agency determines how much damage that trick, or a plain mistake, can cause. A prompt injection against an assistant that can only read produces, at worst, a strange summary. Against one that can send, delete and pay, it produces an incident.

That is why, even though nobody can guarantee a model will never be fooled, you can decide what it is able to do when it is. That part of the problem is up to you.

◢What to do before connecting an agent to your systems

OWASP suggests several measures. These are the ones that translate best to a small or mid-sized company:

• ▹Offer only the tools that are strictly needed. If the agent can work without a function, do not give it that function.
• ▹Trim each tool to what is needed. Summarising email only takes read-only access to the mailbox.
• ▹Avoid open-ended tools. One that runs any command or opens any URL is far riskier than one that only saves a file to a specific folder.
• ▹Grant minimum permissions in the systems behind the agent, and enforce them there, in the database or the service, not in an instruction to the model.
• ▹Make the agent act as the user who is using it, with minimal permissions, rather than through a service account that can do everything.
• ▹Require human approval for anything with consequences: sending, deleting, paying, changing permissions.
• ▹Log what it does and rate-limit its actions. OWASP lists these as measures that do not prevent the problem but reduce the damage.

One underlying idea from OWASP sums it up: authorisation belongs in the downstream systems, not in trusting the model to decide whether an action is allowed. Asking the assistant nicely not to delete anything is not a security control.

◢What if we already have agents running?

Do a simple inventory. For each assistant, note three things: which tools it has, which account it uses to enter each system, and which actions it performs without anyone approving them. Something is almost always surplus, such as an account with more access than needed or a write permission nobody uses.

Then remove. Start with write and delete permissions and with any admin account. If the agent stops working without them, give back only what is missing.

If your team also uses AI tools on their own without IT knowing, the inventory should include them. You cannot trim the permissions of an agent you do not know exists.

◢One question for every new assistant

When I build an assistant for a company, the question I ask myself is what it would do that it should not if it made a mistake or were tricked. If the answer is uncomfortable, the design is not finished. And it is much easier to adjust permissions before launch than after a scare.

If you want your team to understand these risks without jargon and know what to ask for before giving an AI access to anything, it is one of the topics I cover in my cybersecurity and AI training for companies.