Identity Impersonation

also known as Delegation Not Impersonation, Agent Impersonation

Anti-pattern: let the agent act under the principal's own full identity and token, so every action it takes is recorded as the principal's and audit cannot separate user-initiated from agent-autonomous decisions.

Context

An agent acts for a user against systems that enforce access control. The fastest way to give it authority is to hand it the user's own session token or credentials, because the downstream services already trust that identity and no new identity has to be issued. The agent then presents on the network exactly as the user, with all of the user's permissions, and the team treats this as a working delegation mechanism.

Problem

When the agent assumes the user's full identity, it inherits every permission the user holds, far beyond the slice the task needs, and the downstream service has no way to tell that an agent and not the user is acting. Each action lands in the audit log attributed to the user, so a reviewer reading the log sees that the user placed the order or moved the funds, when in fact the agent chose that step autonomously from a goal the user only stated loosely. The distinction between what the user explicitly authorised and what the agent decided on its own collapses into one identity, and when the agent calls further agents downstream the whole chain disappears into that single borrowed identity, leaving no trace of the agent's own reasoning.

Forces

Passing the user's existing token is the path of least resistance because downstream services already trust that identity.
Issuing the agent its own identity that still proves the user consented requires delegation infrastructure that is harder to stand up.
Audit captures the identity presented at the call, not the actor that originated the decision behind it.
A single borrowed identity carries the user's full permissions, far more than any one task requires.

Example

A procurement agent is told 'keep the team stocked with laptops' and is handed the user's own SSO token to act with. It decides on its own to order fifty MacBook Pros from a supplier. The purchasing system records the order as placed by the user, and the approval workflow waves it through because the user has buying authority. Weeks later the user disputes the order, but the audit log shows only 'user placed order' with no evidence that an agent chose the quantity or the supplier, so the action cannot be traced to the agent's reasoning.

Diagram

flowchart TD Trigger[Agent acts under user's own identity / token] --> Bad{Recognise as anti-pattern?} Bad -- no --> Harm[Audit attributes agent's autonomous action to the user] Bad -- yes --> Mitigate[Switch to delegated identity carrying user consent] Mitigate --> Safe[User-authorised vs agent-chosen stays distinguishable] classDef bad fill:#fee,stroke:#c33; class Trigger,Harm bad;

Solution

Therefore:

Don't. Replace impersonation with delegation: have the agent act under its own identity that carries a delegation claim naming the consenting principal, via an on-behalf-of token exchange (delegated-agent-authorization), so a downstream service and a later audit can always see both the user who authorised the goal and the agent that chose the implementation. Pair it with a task-bounded agent identity class (ephemeral-agent-identity) so the agent's self is never the user's self, and scope the delegated authority to the task rather than copying the user's full permissions.

What this pattern forbids. No useful constraint; the missing constraint is that the agent must never present the principal's own identity and must instead act under a distinct identity carrying the principal's delegated consent.

The patterns that counter or replace it —

alternative-toDelegated Agent Authorization★— Have an agent act for a principal using scoped, short-lived, revocable delegated credentials rather than the principal's own static secrets, so each action stays attributable across the principal-to-agent-to-subagent chain and a compromise is contained.
alternative-toEphemeral Agent Identity★— Mint each agent run a short-lived identity of its own, scoped to one task and provisioned just-in-time, then revoke it on completion so no standing credential outlives the work.
complementsAgent Privilege Escalation✕— Anti-pattern: let an agent's effective permissions be the union of its own identity, the identities of its tools, and the identities of the services those tools call.
complementsAuthorized Tool Misuse✕— Anti-pattern: grant the agent a tool with broad authorization and trust the agent to use it in benign ways.