Is this just user impersonation?

No. Impersonation makes downstream systems treat the agent as if it were the user, which erases who actually performed the action. Delegation keeps two separate facts: the user authorised the work, and the agent executed it. That distinction matters for audits, incident response, revocation, and deciding whether an action exceeded the agent’s mandate.

Why not use one service account for all agent actions?

A shared service account is simple but weakens accountability and control. It hides which agent acted, which user delegated the task, and what authority was intended. It also makes revocation coarse: disabling the account may stop everything, while leaving it enabled may allow too much. Per-agent identity plus scoped delegation gives finer control.

What should be in the audit log?

At minimum, log the agent identity, the delegating user or organisation, the action, the target resource, the authorisation scope or policy decision, and the time context. The important point is semantic clarity: the log should not force investigators to infer whether a human directly acted or an agent acted under delegated authority.

How narrow should delegated authority be?

It depends on the action’s risk, the agent’s autonomy, and how long the authority must last. Prefer the narrowest scope that still lets the agent complete the task, with expiry and revocation. Destructive, financial, or externally visible actions often need additional approval or step-up checks rather than broad standing permission.

Agents Acting on Behalf of Users

Agents acting on behalf of users are AI or automated actors with their own system identity and limited delegated authority from a user or organisation. The key property is that an audit trail can distinguish the requesting user from the agent that executed each action.

The problem is accountability. If an agent uses a user’s session, password, or undifferentiated service account, every downstream action looks like it came from the wrong actor or from no meaningful actor at all. That breaks investigation, approval, revocation, rate limiting, and access review. The user may have asked for the work, but the agent may choose steps, retry, run later, or be compromised, so those facts must not collapse into one identity.

The usual pattern is delegated authorisation. The agent is registered or represented as a principal in the system, then receives credentials or tokens that say what it may do, for whom, and under what constraints. Requests carry both facts: the agent is the actor performing the call, and the user or organisation is the delegator. Scopes, expiry, audience, and policy checks limit the authority instead of handing over the user’s full identity.

The trade-off is more identity plumbing. You need token exchange, policy evaluation, audit schemas, revocation, and clear rules for asynchronous work. It is also easy to design scopes that are either too broad to be safe or too narrow to be useful. The honest answer to many design questions is: it depends on the risk of the action, how long the agent runs, and whether human approval is required.

Engineers meet this in OAuth-style flows, agent platforms, internal workflow systems, and audit log design. A good log entry does not merely say that a user deleted a record or that a background service did it. It records that a named agent performed the operation under delegated authority from a named user, tenant, or organisation, with the relevant scope and authorisation context available for review.

Go deeper

User SystemsAgents Acting on Behalf of UsersGive an AI agent an identity of its own and a delegated, scoped authority, so that 'the agent did it' and 'the user did it' are different facts in the log.Open the lesson

Common questions

Is this just user impersonation?: No. Impersonation makes downstream systems treat the agent as if it were the user, which erases who actually performed the action. Delegation keeps two separate facts: the user authorised the work, and the agent executed it. That distinction matters for audits, incident response, revocation, and deciding whether an action exceeded the agent’s mandate.
Why not use one service account for all agent actions?: A shared service account is simple but weakens accountability and control. It hides which agent acted, which user delegated the task, and what authority was intended. It also makes revocation coarse: disabling the account may stop everything, while leaving it enabled may allow too much. Per-agent identity plus scoped delegation gives finer control.
What should be in the audit log?: At minimum, log the agent identity, the delegating user or organisation, the action, the target resource, the authorisation scope or policy decision, and the time context. The important point is semantic clarity: the log should not force investigators to infer whether a human directly acted or an agent acted under delegated authority.
How narrow should delegated authority be?: It depends on the action’s risk, the agent’s autonomy, and how long the authority must last. Prefer the narrowest scope that still lets the agent complete the task, with expiry and revocation. Destructive, financial, or externally visible actions often need additional approval or step-up checks rather than broad standing permission.

Every term