An organisation deploys an agent to check supplier invoices. To do its job it needs the invoicing system, the contracts, and the accounts payable mailbox. The fastest way to arrange that is to run it under the account of the person who used to do the work.
It works on day one. What also happens: the agent now has access to everything that person accumulated over eight years of employment.
Permissions are not a detail of an agent
An agent differs from a chatbot in that it acts. Acting means another system has to authorise it: the mail system, the document store, the ERP.
So authorisation is not a precondition sitting beside the agent, it is what the agent is. What it can do equals exactly what was granted. Everything else said about its behaviour and reliability rests on that.
Why "just run it as the user" is the default
Because it works and costs nothing. The integration exists, the account exists, and the user would be doing this work anyway.
Three problems arrive afterwards.
It inherits the mess. Every employee has accumulated access to things that no longer matter: old project sites, shared folders, links that never expired. While a human uses that access selectively, it stays invisible. An agent searches everywhere. See how AI tools reach files you never uploaded.
The audit log becomes useless. If the agent acts as the user, every system records that the user did it. During an incident you cannot establish whether the human or the automation acted, which is precisely the moment you want to know.
Revocation is not targeted. Removing the agent's access to one system means removing the employee's.
Why least privilege is harder here
With people, least privilege works reasonably: you know someone's role and which systems belong to it.
With an agent that runs into two obstacles.
You do not know the steps in advance. The entire reason to use an agent is that the model works out how to reach the goal. Which systems that requires emerges along the way. Grant narrowly up front and you get failures; grant broadly and you have the problem from the previous section.
The remit grows quietly. An agent that started with invoice checking is also sending payment reminders three months later. No request was filed, because the permissions were already there.
The honest conclusion: least privilege here is not a setting but a cycle. Start narrow, widen based on what actually fails, and revisit whether it is all still needed.
What does work
A dedicated account per agent. Not per agent type, per agent. Reach becomes explicit, revocation becomes independent, and the log shows that automation acted.
Permissions scoped to the task, not the person. Describe which systems the task needs and at what level (read, write, delete). That is a shorter list than a human's access profile.
A separate boundary on irreversible actions. Read access and action rights are two categories. Sending, deleting, publishing, paying and granting access belong behind human confirmation, however much the agent may otherwise see.
Short-lived tokens. Access that expires on its own rather than a key valid until somebody revokes it. With integrations through standalone servers this is a recurring weak point, see what is an MCP server.
A review when the remit expands. The moment someone says "it can also do X now" is the moment for a fresh look at permissions.
Why this is more urgent than it looks
There is a further reason to be strict here, unrelated to honest mistakes.
An agent reads content it does not trust: emails, web pages, documents. If instructions are hidden inside, it can follow them, and it will then act with exactly the permissions you granted. See what is prompt injection.
That makes the permissions question the most effective security control you have. Not because you distrust the model, but because the model can be talked into something and the permissions cannot.
