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 set that up is to run it under the account of the person who used to do the work.
It works from day one. It also means the agent now has access to everything that person accumulated over eight years of employment.
For an agent, permissions are not a detail
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 alongside the agent; it is what the agent is. What it can do is exactly what it has been 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 follow.
It inherits the mess. Every employee has accumulated access to things that no longer matter: old project sites, shared folders, links that never expired. As long as a person only uses some of that access, 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 when you want to know.
Revocation cannot be 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 well: you know someone's role and which systems belong to it.
With an agent, it runs into two obstacles.
You do not know the steps in advance. The whole point of using an agent is that the model works out how to reach the goal. Which systems that requires only becomes clear 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. Three months on, an agent that started out checking invoices is also sending payment reminders. Nobody filed a request, 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 keep checking whether it is all still needed.
What does work
A dedicated account per agent. Not one per agent type: one per agent. Its reach becomes explicit, you can revoke it on its own and the log shows that the 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 around irreversible actions. Read access and the right to act are two different things. Sending, deleting, publishing, paying and granting access should require 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. This is a recurring weak point in integrations that run through standalone servers; see what an MCP server is.
A review when the remit expands. The moment someone says "it can also do X now" is the moment to look at the permissions again.
Why this is more urgent than it looks
There is a further reason to be strict here, unrelated to honest mistakes.
An agent reads untrusted content: emails, web pages, documents. If instructions are hidden in it, the agent may follow them, and it will do so with exactly the permissions you granted. See what prompt injection is.
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 things and the permissions cannot.
