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

Why This Matters for Security Teams

In OAuth-based agent workflows, the delegation versus impersonation choice determines whether security teams can still prove who initiated an action, which policy applied, and which system actually exercised authority. That distinction matters because autonomous agents do not behave like fixed human users. They chain tools, vary their requests, and can traverse multiple downstream systems in ways that make static trust assumptions brittle. Current guidance suggests preserving attribution and context wherever possible.

This is one reason NHI governance and agentic AI governance overlap so heavily. OAuth tokens become the practical control plane for agent access, and weak handling of those tokens is visible in real incidents such as CoPhish OAuth Token Theft via Copilot Studio and broader agent risk analysis in OWASP Agentic AI Top 10. NHIMG research found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which shows how quickly delegated access can become an opaque supply-chain problem when identities blur.

In practice, many security teams notice the delegation-versus-impersonation problem only after an agent has already triggered an incident response review and the audit trail can no longer explain whose authority was actually used.

How It Works in Practice

Delegation means the agent receives limited authority to act on behalf of a user, usually through scoped tokens, consented claims, and explicit provenance that survives each hop. Impersonation means the downstream service sees the agent as if it were the user, often with the user’s broader rights and with weaker attribution. For agent workflows, the safer design is usually delegation with constrained scopes, short lifetimes, and policy checks at each step.

In practice, teams should prefer token designs that preserve the subject, actor, and intended action. That can include token exchange patterns, on-behalf-of flows, and runtime authorisation that checks the task, the resource, and the current risk context instead of assuming the original consent is still sufficient. This aligns with the direction of NIST AI Risk Management Framework and CSA MAESTRO agentic AI threat modelling framework, both of which emphasise context, accountability, and operational risk rather than blind trust in a single grant.

• Use delegation when the downstream system must know both the user and the agent.
• Use narrowly scoped, short-lived OAuth grants so the agent cannot reuse authority beyond the task.
• Log the original requester, the agent identity, the target service, and the specific action approved.
• Re-evaluate access at runtime when the agent changes task, data set, or tool chain.

For additional context on agent identity risk, OWASP NHI Top 10 covers how token misuse and privilege sprawl emerge in autonomous workflows. These controls tend to break down in legacy SaaS integrations that only support broad user impersonation, because the application cannot preserve actor context or enforce per-hop policy decisions.

Common Variations and Edge Cases

Tighter delegation often increases implementation overhead, requiring organisations to balance auditability and least privilege against compatibility with older OAuth integrations. That tradeoff is real, especially where vendor APIs only support full impersonation or where a downstream service expects a human user principal rather than an agent-as-actor model.

There is no universal standard for this yet. Best practice is evolving toward context-aware authorisation, but some environments still rely on impersonation for operational simplicity, especially in service desks, productivity suites, and thin integration layers. The risk is that impersonation can hide which system made the decision, which complicates incident response, revocation, and legal accountability.

One practical exception is read-only assistance, where a short-lived delegated token may be acceptable if the agent only retrieves data and cannot write, approve, or transfer anything. Another is break-glass automation, where impersonation may be tolerated temporarily but should be tightly monitored and explicitly time-bound. NHIMG research in the state of non-human identity security shows how limited visibility and over-privilege are persistent problems, so any exception should be treated as a control debt, not a default pattern.

Security teams should treat impersonation as an exception that needs documented rationale, expiry, and compensating controls. In environments with multi-agent chains, shared service accounts, or third-party OAuth apps, that exception can quickly become the weakest link in the entire trust model.

Related resources from NHI Mgmt Group

• What is the difference between human identity governance and AI agent governance?
• What is the difference between governing human access and governing AI agent access?
• What is the difference between linear orchestration and graph-based agent workflows?
• What is the difference between identity-based access control and MCP content inspection for AI agents?