On-Behalf-Of Delegation

What On-Behalf-Of Delegation Means in Practice

On-behalf-of delegation is not just a token swap, it is a trust decision. The system is allowing one actor to exercise authority that was originally granted to another, so the security meaning depends on who can delegate, what authority is transferred, and how the resulting action is represented for later review.

That matters because the pattern can preserve useful automation without erasing accountability. It is the difference between an action being merely performed by a technical intermediary and that action remaining attributable to the originating subject, the delegated actor, and the policy that allowed the chain.

Where the Authority Comes From

On-behalf-of delegation usually sits inside OAuth-style token exchange, where a subject token and an actor token are combined so a downstream service can see both the original identity and the acting identity. The important design point is that delegation should be explicit, scoped, and bound to a clear trust relationship rather than inferred from technical reach alone.

That is why the pattern is often discussed alongside act claims, may_act style constraints, and audience scoping. Those elements help separate “who initiated the work” from “who is permitted to carry it out,” which becomes essential once requests pass through multiple services or agent steps.

OAuth token exchange and delegation is the core mechanism behind this pattern, while RFC 8693: OAuth 2.0 Token Exchange defines the standard token exchange model used for delegation and impersonation flows.

Why It Matters for Accountability and Governance

The main value of on-behalf-of delegation is that it can preserve traceability across chained actions. In agentic or service-to-service workflows, that means a downstream action should still be explainable as “done by this actor, for that subject, under this policy,” rather than collapsing everything into one opaque bearer credential.

Without that context, delegated access becomes hard to govern. Reviewers may not be able to tell whether a request came from a genuine delegated workflow, an overbroad intermediary, or a system that is quietly reusing authority in ways the original subject never intended.

Agentic AI identity covers the identity, delegation, and retirement concerns that arise when autonomous systems act with borrowed authority, and confused deputy in AI agents explains the governance failure that appears when an intermediary uses valid authority in the wrong context.

How Delegation Differs from Simple Impersonation

Delegation is meant to preserve the relationship between the initiating subject and the acting component, while impersonation usually aims to make the acting component look like the subject alone. That difference is not cosmetic, it changes how much context survives into logging, authorization decisions, and later investigations.

In well-designed flows, the downstream service can evaluate both the delegated actor and the original subject, then decide whether the action is permitted for that exact combination. In weaker designs, the original context is lost, and the system may grant more authority than intended because it only sees a valid token, not the policy chain behind it.

This is why policy context, audience restriction, and precise claims matter. They are what keep on-behalf-of delegation governable rather than merely convenient.

Risk and Threat Considerations

On-behalf-of delegation creates exposure when the delegated authority is broader than the original purpose or when the system cannot reliably distinguish the subject, the actor, and the policy that connected them. The risk is not the delegation pattern itself, but the way it can become a confused deputy, privilege amplification, or audit blind spot if trust is too loose.

Failure mechanism: A valid intermediary receives authority that is acceptable in one context and then reuses it in another, allowing actions to be authorised by technical presence rather than by the intended business or policy context.

Impact: Unauthorized actions may be attributed incorrectly, excessive privilege may be exercised without clear intent, and investigators may lose the ability to reconstruct who actually initiated the chain.

Practitioner Guidance

Why practitioners should care: Treat on-behalf-of delegation as an explicit authorization design, not a transport detail. The implementation should carry enough identity and policy context that reviewers can distinguish the original subject, the acting component, and the permitted scope of the exchange.

What to watch for: Be suspicious of delegation flows that rely on a single bearer token, omit actor context, or make it impossible to tell whether the downstream service is acting for a user, for another service, or for itself. Those are the conditions that usually turn delegation into accidental impersonation.

Related resources from NHI Mgmt Group

• What happens when an AI agent acts on behalf of a user but the delegation record is missing?
• What breaks when AI agents can buy on behalf of users without scoped delegation?
• How can organizations effectively manage access delegation for AI agents?
• How should security teams handle unconstrained delegation in Active Directory?