AI agent permissions — what it may do and how to limit it

An AI agent has no permissions of its own. It runs on the permissions of some account — and which account that is decides more than the choice of model or vendor.

In the companies we talk to, the question surfaces after the rollout, the first time the agent shows someone data from outside their remit. Nobody asks earlier, because configuring things so they work is faster.

Below: what to set before an agent touches production.

Whose account the agent runs on#

Three variants seen in practice, most common first.

The account of whoever configured it. Usually the owner's, which sees everything. While that person is the only user there is no problem. It starts the day the agent answers the whole team, since everyone asking then borrows the owner's access.

A technical account made for the integration. Looks tidier, often worse. It is nearly always given administrator rights — the shortest path to making everything work first time — and nobody narrows them later, because the account has no owner who would notice.

The account of whoever is asking. The agent sees exactly what that person sees, no more. For most uses this is the right arrangement, and the first question for a vendor: does the agent act with the user's permissions or its own?

Least privilege in practice#

The principle is familiar: the agent gets only what the task requires. The difficulty is applying it upwards from nothing rather than downwards from everything.

Name the task, not the department. Not "access to the CRM", but "read the jobs of the customer the question is about". The first takes five seconds to tick; the second demands thought, and is worth something.

Look at fields, not just objects. An agent building a rota needs people's availability, not their pay rates. Systems granting permissions only at module level force an all-or-nothing choice — a genuine criterion when comparing tools.

Put a review date in the calendar. A permission granted for the trial stays forever, because nobody is tasked with removing it. Without an IT department, the only fix is a date in the granting manager's calendar.

Read and write are two different permissions#

Most tools glue them together: "the agent has access to the jobs module". Separating them is the cheapest change with the largest effect.

An agent that only reads carries one risk: showing something to someone who should not see it. An agent that writes leaves a mark in data the whole company works on. Two classes of problem, one control.

The most commonly confused point: "do not change anything" in an agent's instructions is not a permission. An instruction is a request to a model that will usually honour it. A permission is a wall it cannot cross even when it concludes that it should. If a vendor answers a question about read-only mode by describing a system prompt, they do not have one.

For writes, narrow again. An agent that changes a job's status needs no right to delete records or alter prices — three permissions under one "edit" toggle in many systems.

The third category: irreversible actions#

Read and write is not a complete split: some writes land beyond the reach of undo.

A sent email sits with the recipient. A completed payment sits with the bank. A deletion with no bin is a deletion. A change in an external system with no log leaves no history. A write inside your own system can be reversed if there is a change log; these four sit outside that protection.

The consequence: these permissions belong on their own switches, not in a bundle. "Mailbox handling" as one permission means an agent that reads the inbox can also send from it. Entirely different decisions, taken separately.

On a first agent, leave the category off altogether. Not because the agent will certainly err, but because the cost is asymmetric: two hundred correct messages do not offset one sent to the wrong customer.

The audit trail — who actually made that change#

If the agent runs on the owner's account, the log will show the owner did everything. After a month you cannot tell human changes from machine ones, which closes off any correction.

Two things every entry must carry:

The agent as its own actor. Not "Kate Miller", but "agent launched by Kate Miller" — two pieces of information in one line.

What triggered the run. Whose question, or which event, caused the action. The one thing that distinguishes an agent's log from a person's, and the only way to reconstruct a sequence of steps afterwards.

One use rarely considered: the log is the best source for narrowing permissions. After two weeks you can see which data the agent never touched, and everything it did not use can be taken away — evidence rather than guesswork.

What to check before switching it on in production#

Six questions. "I don't know" to any of them means "not yet".

1. Whose permissions the agent runs on — and whether that answer is "the administrator's".
2. Whether read-only is a setting or a sentence in the instructions.
3. Whether irreversible actions — sending, deleting, payments — switch off individually.
4. Whether the change log shows the agent as its own actor.
5. Whether search respects the permissions of the person asking.
6. What happens when whoever configured it leaves — does the agent stop, or carry on with the access of someone who is gone.

Then one test covering all six at once. Ask the person with the narrowest access in the company to ask the agent something outside their remit. If they get an answer, the configuration needs work, whatever the settings screen says.

Summary#

An agent has no permissions of its own, only borrowed ones, so the first question is always: borrowed from whom. Read, write and irreversible actions deserve three separate decisions — and a read-only mode enforced by instructions is not a read-only mode. A log in which the agent appears as its own actor is what lets you judge afterwards whether the access you granted was right.

The wider context — how an agent differs from a chat and where it fails — is in the guide on AI agents for business.