An AI agent should act under its own scoped identity by default, not as the employee who asked it to do something. Delegation, where the agent borrows the user’s permissions, looks tidier because nothing new needs to be provisioned. But it means the agent can do everything that person can do, including things they would never do from a chat prompt.
The choice sounds like a plumbing detail. It decides what the agent can reach, whose name appears in the logs, and what happens when someone gets the agent to do something unexpected.
Delegation gives the agent a senior person’s reach and none of their judgment
When an agent acts on behalf of a user, it typically carries that user’s token. If the user is a finance director, the agent can read every ledger, approve payments up to their limit, and export the vendor list. The user asked it to summarise a supplier invoice. The permissions say it can do far more.
Senior people hold broad access because they have judgment about when to use it. A finance director has the ability to change bank details on a vendor record, and would never do it because a line in an email told them to. An agent reading that same email has the ability without the hesitation. Prompt injection, a misread instruction, or a plain model error all execute with full authority.
The audit trail suffers too. Every action appears under the director’s name. When someone later asks whether a person or the agent made a change, the record cannot say. The same problem shows up with shared logins, and delegation reproduces it with a more respectable face.
There is also a lifecycle problem. If the agent’s access is the user’s access, it changes when their role changes and disappears when they leave. Nobody decided that on purpose, and what happens when an agent’s creator leaves becomes an accident rather than a design.
An agent should hold only what its job needs, and the requester should not widen it
The narrower model gives the agent its own identity, scoped to the task it was deployed for. An invoice-summarising agent can read invoices. It cannot edit vendor records, because nobody gave that identity the permission, regardless of who is asking. This is the Identity principle in practice: credentials that describe the agent’s job, not borrowed from whoever happens to be at the keyboard.
The requester still matters, but as an input to policy rather than as a source of authority. The agent’s own identity defines the ceiling. The user’s role can narrow what the agent does for them, for example by limiting results to the accounts that user is allowed to see. It should never raise the ceiling.
In the deployments we build, every action is written against the agent’s identity, the policy that allowed it, and the person who requested it, at the moment it happens. That gives you three separate facts instead of one blurred one. You can answer “who asked, what did the agent do, and why was it permitted” without reconstructing it from guesses. It also makes the agent easier to revoke, because turning off one identity does not lock a human out of their own work.
The same logic applies to how many identities an agent holds. A scoped identity per system is usually better than one broad one, which we cover in one identity or one per system.
Delegation is still the right answer when the action is the person’s own
Delegation is not always wrong. Some tasks are personal: drafting and sending an email from your own mailbox, scheduling on your calendar, reading documents only you have been granted. The agent is an extension of one person doing something that person is entitled to do, and the record should say so.
In those cases a narrow delegation works well. The agent borrows a limited slice of the user’s access, for a defined task and a short time, with the delegation recorded as such. Where the downstream system enforces per-user permissions, such as a document store that filters by who is asking, delegation can be the only way to respect those rules without rebuilding them.
The test is whether the action belongs to the person or to the process. If a person would normally do it themselves, delegation can fit. If the agent is doing a job that exists independently of who asked, it needs its own identity.
Where this still gets hard
Agent-owned identities create work. Someone has to define the scope, review it as the job changes, and decide who owns the policy behind it, a question we explore in who should own the policy your AI agent enforces. Scope drift is real: an identity that starts narrow collects permissions every time a request fails, until it quietly resembles an admin account.
There is a tension on the other side too. Make the agent identity too tight and users find it useless, then route around it with delegated tokens or pasted credentials. Passing the requester’s context into policy also takes care, because a user’s entitlements can change between the request and the action. None of this has a clean answer. It takes a judgment about each workflow, and it is the kind of thing a diagnostic is meant to surface. If you want a second pair of eyes on yours, you can book a diagnostic call.
The question to sit with
Pick one agent running in your business today and look at the credentials it uses. If it is acting as a person, ask what the worst thing is that it could do with that person’s access, and whether anyone chose to allow that. If you cannot tell from the logs whether the agent or the person did something last Tuesday, whose decision was that?