What is the difference between delegation and impersonation in OAuth-based agent workflows?

Delegation vs Impersonation in OAuth Agent Workflows

Delegation and impersonation can look similar in OAuth-based agent flows, but they create very different control and audit outcomes. Delegation preserves the acting agent as a distinct subject, while impersonation collapses that boundary and lets the downstream service treat the request as if it came directly from the user. That difference drives how much authority, attribution, and policy enforcement you retain.

For OAuth in particular, the distinction matters because token handling, audience restriction, and per-hop checks determine whether the agent is merely authorised to act on behalf of someone or is effectively borrowing that person’s full identity. OAuth 2.0 and OpenID Connect Guide for Identity Teams is useful background for the roles and token mechanics that make this distinction possible.

What delegation changes in practice

Delegation keeps the chain visible. The user remains the original principal, the agent becomes an explicit intermediary, and the receiving service can make a decision based on both the user intent and the delegated scope. That structure supports constrained tokens, narrower permissions, and decisions that can vary by action rather than by blanket user authority.

In agent workflows, that visibility is not just an accounting detail. It lets you enforce task-scoped access, separate user entitlement from agent entitlement, and limit what the agent can do if the task changes mid-flight. When delegation is implemented well, the service can still see who authorised the action and who executed it.

This is also why delegation is the better fit for multi-step workflows, where an agent may need to call several services in sequence. Delegation Chains and Attenuated Authority for AI Agents explains why the authority should narrow as it moves through the chain rather than expand.

Why impersonation is different and usually riskier

Impersonation removes the separate agent identity from the transaction. The downstream system sees the user identity only, so the agent inherits the user’s rights as though it were that user. That can simplify integration, but it also hides which software component made the request and makes policy enforcement and forensic review much harder.

The core risk is authority inflation. If the agent is compromised, over-scoped, or misrouted, it can exercise the user’s full rights without an obvious boundary in the request trail. For sensitive workflows, that turns an automation convenience into a broad trust assumption. OWASP Agentic Top 10 ASI03 Guide is a practical reference for understanding why identity and privilege abuse in agent systems needs explicit controls.

Impersonation can be acceptable in tightly controlled enterprise patterns, but only when the business deliberately accepts the loss of attribution and the wider blast radius. In most agent settings, especially where approvals, audit, or separation of duties matter, that trade-off is too expensive.

Risk and Threat Considerations

Delegation reduces exposure because compromise of the agent does not automatically grant the user’s full authority, but the model still depends on correct token audience, scope, and hop-by-hop enforcement. Impersonation creates a much larger failure domain: if the agent, broker, or token exchange is abused, the attacker can blend into legitimate user activity and move with the user’s standing privileges.

Failure mechanism: The control boundary fails when a system treats a delegated action as if it were a direct user action, or when a token is forwarded without preserving the actor chain and scope limitations.

Impact: Investigations lose attribution, policy checks become harder to enforce per action, and a compromised agent can generate user-authorised requests that are difficult to distinguish from legitimate activity.

Practitioner Guidance

What to verify: Confirm whether each hop preserves an explicit actor claim, a bounded audience, and a scope that matches the task rather than the user’s full standing access. If the design cannot show who authorised the action and who executed it, you are effectively in impersonation territory even if the documentation says delegation.

Decision rule: Use delegation when the workflow needs attribution, conditional approval, or partial authority. Reserve impersonation for rare cases where the downstream service genuinely cannot operate any other way and the risk owner has accepted the audit and blast-radius trade-off.

Practitioner takeaway: The safest OAuth agent pattern is the one that keeps authority narrow and identity visible; if the design erases the actor chain, it may be operationally convenient but it is no longer delegation in the security sense.

Related resources from NHI Mgmt Group

• Guide: Pretexting Guide
• Why does delegation create less audit ambiguity than impersonation in OAuth-based architectures?
• What is the difference between human identity governance and AI agent governance?
• When does AI agent access create more risk than it reduces?
• What is the difference between governing human access and governing AI agent access?