Anti-Patterns

Identity 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.

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.

Solution

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.

When to use

  • Never. Cite when reviewing how an agent authenticates on a user's behalf.
  • Replace with delegated, scoped tokens carried under the agent's own identity.
  • Stamp every action with both the consenting principal and the acting agent so audit can separate them.

Open the full interactive page

Diagram, neighbourhood map, code examples, related patterns and full provenance.

Related