Whose permissions does an AI agent act with?
A team connects a support agent to the CRM with one service account that can read every customer record, because that was the fastest way to get it working. Now every employee who uses the agent can reach records they could never open themselves, and the audit log says "support-bot" for all of it. The fix is to choose, for each job, whether the agent acts on behalf of a specific person with that person's access, or acts as itself with access granted to the agent directly. Whichever you pick, the log should name both the agent and the person behind it.
A shared account answers the wrong question
Most first agent deployments run on whatever credential was closest to hand: an admin API key, a bot user, or a service account created for an older integration. It works in a demo because the person testing it usually has broad access anyway.
Problems show up once other people use it. The agent's access is no longer tied to the person asking, so a sales rep can ask it to summarize an HR ticket they have no right to see. Every action is logged under the same name, so an incident review can tell you what happened but not on whose request. Revoking access for one person means revoking it for everyone, so in practice nobody does it. All three problems come from an identity decision nobody made on purpose.
There are two workable models
Microsoft's documentation for Entra Agent ID describes the two options plainly. With delegated access, agents "act on behalf of human users, using access rights given to the user." With autonomous access, agents act "using access rights given directly to the agent identity."
The OAuth token exchange standard, RFC 8693, draws a related line between delegation and impersonation. When A impersonates B, "A is B within the context of the rights authorized by the token." With delegation, A keeps a separate identity, and "any actions taken are being taken by A representing B." In the standard's words, "A is an agent for B."
For agents, prefer delegation. Impersonation makes the agent indistinguishable from the person in every log, while delegation keeps both names attached to each action.
Pick the identity from the job
A useful rule: if a person started the work and is accountable for the result, the agent should act on that person's behalf. If the work runs on a schedule or an event with nobody in the loop, the agent should have a dedicated identity, scoped to that one job.
| Job | Acts as | Why |
|---|---|---|
| Draft replies in someone's inbox or summarize their documents | The person | It should see exactly what they see, and nothing more |
| Answer questions across team tickets for whoever asks | The person asking | Two people asking the same question may be allowed to see different records |
| Reconcile invoices every night | A dedicated agent identity | No person is present, so access should belong to the job |
| Watch alerts and open tickets | A dedicated agent identity | It runs continuously and needs a narrow, stable scope |
| A sub-agent started by another agent | The same person, with less access | A sub-agent should never be able to do more than the agent that started it |
The labels will shift by organization. A nightly job that a manager kicks off by hand might be better run on their behalf. The point is to make the choice per job, in writing, before the agent goes live.
Delegation should narrow access, never widen it
Acting on behalf of a person sets a ceiling: the agent can reach what that person can reach. It does not mean the agent should reach all of it.
A finance lead may be allowed to issue refunds. An agent that drafts customer replies for her does not need that permission, even though she has it. Give the agent the subset its job needs, and keep the rest with the person.
RFC 8693 is direct about the risk: "Any time one principal is delegated the rights of another principal, the potential for abuse is a concern." Delegating everything by default is how an assistant meant to draft emails ends up able to move money.
A dedicated agent identity needs an owner
When an agent runs as itself, there is no person standing behind each action, so the identity has to carry that accountability instead. Give it a named owner who answers for what it does. Scope it to one job rather than reusing it across agents. Review its access on the same schedule as other non-human accounts, and remove it when the job ends.
A service identity shared by five agents has the same attribution problem as a shared login, one level down.
Record both names on every action
A log entry that says only "agent" or only "user" is half an answer. The IETF working draft on AI identity management (draft-ietf-wimse-aims, still a draft rather than a standard) proposes that audit events record, at a minimum, the "authenticated agent identifier; delegated subject (user or system), when present; resource or tool being accessed."
In practice, that means a line like this for every call:
2026-11-03 10:42 agent=support-drafter on_behalf_of=maria.k tool=crm.read_case case=1842
With both names, an incident review can answer which agent acted, for whom, and whether that person was allowed to do it. Our answer on MCP authorization covers why passing a user's raw token through to downstream tools breaks this.
Make the safe choice the default
Metorial is built around this model. In Magic MCP, every tool call runs on the signed-in user's identity, so an agent can only reach what that person can reach. Access control can then narrow a specific agent by tool, provider, action, or session. With identity delegation, agents start with no access, a sub-agent can never do more than its parent, and delegation can require approval before access is granted. Automation that runs without a person gets a separate service account instead of borrowing someone's login. Tracing ties each action to the agent that took it and the person it ran on behalf of.
Whatever tools you use, the checks are the same. For each agent in production, can you say whose access it uses, why, who owns it, and which name will appear in the log when something goes wrong?
Sources
- IETF, RFC 8693: OAuth 2.0 Token Exchange (delegation, impersonation, and the actor claim; accessed 2026-11-02)
- Microsoft Learn, What are agent identities (delegated and autonomous access; accessed 2026-11-02)
- IETF, draft-ietf-wimse-aims: AI Identity Management System (working draft, audit event fields; accessed 2026-11-02)