On-behalf-of tokens prove shape, not human attribution

At a glance

What this is: This is an analysis of on-behalf-of authorization patterns and the claim layouts that determine whether a token actually proves a human authorisation event.

Why it matters: It matters because IAM and NHI teams cannot rely on logs, token labels, or product flow names alone when they need defensible attribution across delegated and impersonated access.

Context

On-behalf-of authorization is an identity governance problem before it is a protocol problem. The issue is not whether a system can call another system, but whether the downstream service can still reconstruct who initiated the action and under what authority.

In delegated and impersonation flows, the same phrase can describe materially different token shapes. That distinction matters for NHI, human IAM, and agentic AI because auditability depends on whether the credential preserves one principal or two.

The failure mode is simple: if the resource server treats sub as a person by default, it may confuse service identity with human accountability. That creates audit trails that look complete while actually collapsing the chain of responsibility.

Key questions

Q: What breaks when an API treats sub as the user by default?

A: The audit trail breaks first. In some token profiles, sub names the client application, not the person, so a downstream service can record a perfectly valid request and still misidentify who acted. Teams should validate the grant type and token shape before writing user-centric logs or relying on them for approvals, investigations, or compliance evidence.

Q: Why does audience validation matter for delegated access?

A: Because attribution is only meaningful if the token was issued for the service that is consuming it. If aud points elsewhere, the downstream system is reading identity claims out of context and may misstate who authorised the action. Audience validation is therefore part of identity evidence, not just token hygiene.

Q: What do security teams get wrong about agent authorization?

A: They often treat role checks as sufficient because every call appears schema-valid and authorised. That misses the operational question of whether the call was appropriate in context. The common failure is assuming that trusted tools and trusted identities automatically produce trusted outcomes, which is not true in multi-step agent workflows.

Q: How should teams distinguish impersonation from delegation in IAM?

A: Use delegation when the downstream system must be able to recover both the subject and the actor, and use impersonation only when the application identity is the meaningful accountability boundary. The decision should be explicit in policy, because the same request can create very different audit evidence depending on the token layout.

Technical breakdown

Why sub alone does not prove human attribution

The subject claim is intentionally broad. In some token profiles, sub identifies the user; in others, it identifies the client application. That means a downstream service cannot infer human authorship from sub without also checking the grant context, client identity, and audience. In delegated flows, attribution survives only when the token preserves both the acting software and the human subject in a separable way. When that shape is absent, the system may still be authenticated, but it is not attributable in a governance sense. See the NHI Authentication Guide.

Practical implication: Validate the token shape before you write any audit record that claims a human performed the action.

How nested act claims preserve delegation chains

RFC 8693 uses the act claim to represent the current actor, and it allows nested act objects to preserve earlier actors in the chain. That is different from a flat token where only the subject is visible. The design matters when an agent calls another agent or when a middle tier acts for a person, because the resource server can read the subject and actor separately without consulting an external log join. The point is not merely that delegation happened. The point is that the token itself can carry a readable chain of responsibility. See the OAuth Token Exchange and Delegation Guide.

Practical implication: Prefer token designs that keep the originating human and the acting service separately visible at the resource server.

Why audience validation is part of attribution

Audience is not an identity claim, but it is what makes the identity claims trustworthy. If a token was minted for a different resource server, then any attribution extracted from it is detached from the system that is actually receiving the request. That is why validation must check aud before interpreting sub or any actor claim. In delegated and agentic flows, audience validation stops one service from laundering another service’s identity into its own logs. Without it, the downstream record can look precise while still being semantically wrong.

Practical implication: Reject any token whose audience does not match the resource server before you depend on its identity claims.

NHI Mgmt Group analysis

On-behalf-of is a token-shape problem, not a trust label. The industry keeps using one phrase for two different wire formats, then expects downstream systems to infer accountability from the wrong claim. That breaks the governance model because the resource server can only prove what the token carries, not what a UI label suggests. Practitioners should treat attribution as a structural property of the credential, not a post-hoc interpretation.

Human attribution fails when the token collapses the actor chain. A delegated workflow is only auditable when the human subject and the acting software remain separately recoverable at the point of authorization. If the credential exposes only one principal, incident review has no stable join key and no authoritative answer. Agentic AI identity matters here because agent-led actions make this failure more frequent, not less.

Resource servers must stop pretending that logs can repair weak token semantics. Once the downstream service has accepted a token without checking its shape, the audit trail is already compromised as evidence. The issue is not lack of logging volume. It is that the log line may describe the client, the user, or both, depending on which grant produced the token. Practitioners should design for evidence quality at issuance and validation time, not after the fact.

Delegation needs a governance model that distinguishes impersonation from delegation. The same user-facing language can cover two different accountability outcomes: one where the software stands in for the user, and one where the software acts as a distinct actor representing the user. That distinction must be explicit in IAM, PAM, and NHI policy. Without it, organisations will keep certifying access paths that cannot later explain who actually acted.

Read next: OAuth Token Exchange and Delegation Guide

What this signals

Auditability will move closer to token issuance and validation. Teams can no longer assume that downstream logs will compensate for ambiguous credential semantics. The programme shift is toward designing evidence into the token itself, then checking that evidence at the first service boundary.

Delegation patterns need a shared vocabulary across IAM, PAM, and NHI teams. When a platform says on-behalf-of, practitioners should ask which claims are present, which actor is preserved, and whether the resource server can independently prove attribution. That question will increasingly sit beside approval design and access reviews.

Attribution debt: the gap between authentication success and defensible accountability will become a measurable governance issue. Organisations that cannot distinguish application identity from human intent will keep producing logs that are technically correct but operationally unusable.

For practitioners

• Decode one real production token Inspect the token that the resource server actually receives, not the one the client claims it sent. Confirm whether sub, client identity, act, and aud together support the attribution statement you intend to make.
• Separate attribution from authentication in audit design Store both the human subject and the acting software identity when the flow supports delegation, and do not collapse either into a generic user field. If the token does not preserve both, record that the action is not person-attributable.
• Validate audience before interpreting claims Reject tokens whose aud does not correspond to the resource server before you rely on sub, act, or client identity for logging, approvals, or investigations.
• Document which delegation pattern each service uses Record whether each integration uses impersonation, RFC 8693 delegation, or a vendor-specific on-behalf-of flow so reviewers know which claims should exist and which should not. See the OAuth Token Exchange and Delegation Guide.

Key takeaways

• On-behalf-of language hides two different accountability patterns, and only one of them preserves enough structure to prove a human action downstream.
• The strongest control point is not the log line after the fact but the token shape, especially the relationship between sub, actor claims, and audience.
• Teams that validate delegation semantics at the resource server can separate human intent from application execution without relying on guesswork later.

Related NHI Mgmt Group resources: Agentic AI Identity Guide · OAuth Token Exchange and Delegation Guide · OAuth 2.0 and OpenID Connect Guide for Identity Teams · AI Agent Authorisation Guide

Key terms

• On-Behalf-Of Authorization: On-behalf-of authorization is a decision pattern that evaluates both the calling service and the original user whose action triggered the request. It prevents delegated workflows from exceeding user intent by enforcing policy on the combined identity context instead of trusting the service alone.
• Actor claim: A token field that identifies the software entity carrying out the action on behalf of the original principal. It prevents audit logs from collapsing a human-initiated request into an anonymous machine action and is central to delegated identity governance for agents.
• Audience Validation: Audience validation checks that a token was issued for the exact service receiving it. In MCP, this prevents a valid token for one server from being reused elsewhere, which is critical because agent-driven workflows often move across multiple tools and trust domains.
• Token Attribution: The process of linking model consumption to the identity, task, and permission set that produced it. When attribution is weak, finance sees spend but not cause, and security cannot connect access decisions to cost behaviour.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.