On-Behalf-Of Header

What the on-behalf-of header does

An on-behalf-of header is a delegation signal, not just a routing detail. It lets a downstream service understand whether the request represents a user, a service, or an intermediary acting with delegated authority, which is essential when a single backend call may reflect multiple actors in the trust chain.

That distinction matters because the receiving system may need to apply different policy, logging, and approval logic depending on whether the caller is the original principal or an acting service. Without that context, audit records and access decisions can collapse into an incomplete view of who actually initiated the action.

Why on-behalf-of context matters for authorisation and traceability

On-behalf-of headers are most useful when access is delegated rather than direct. In those flows, the service making the call may be authenticated as itself, but the business action is performed for someone else, so the system must preserve both identities to avoid losing attribution.

This is why the header is closely tied to authorisation and traceability. A downstream service can combine the delegated identity with local policy checks, then record both the acting component and the represented principal for later audit, investigation, or dispute resolution.

Used well, this pattern supports clearer accountability across service boundaries. Used poorly, it can create false confidence if the header is treated as a trustworthy identity source without validating the delegation relationship that produced it.

How it fits into delegated access flows

On-behalf-of handling usually appears alongside token exchange or delegation mechanisms. The header helps convey who is being represented, while the underlying security model decides whether that representation is allowed and what scope of action should follow.

A useful mental model is that the header carries contextual identity, while the access token or authorization artefact carries permission. Those concerns should stay separate: a service should not assume that simply naming a user in a header proves the right to act for that user.

That separation is especially important in microservice and API architectures, where internal requests can cross multiple hops. Each hop may need to preserve the original actor, the intermediary service, and any constrained delegation scope so that policy decisions remain intelligible downstream.

Security and operational pitfalls

The main risk is confusion between asserted identity and trusted identity. If downstream systems trust an on-behalf-of header without strong validation, attackers or misconfigured services can forge attribution, overstate delegation, or hide the true source of an action.

Another common problem is log ambiguity. If audit trails capture only the intermediary service and not the represented principal, security teams may be unable to reconstruct what happened, which weakens incident response, access review, and abuse detection.

For delegation patterns, the safest designs make the header informative rather than authoritative, then bind it to a verified token or equivalent delegation proof before relying on it for access decisions.

Risk and Threat Considerations

On-behalf-of headers can become an abuse path when systems trust them as if they were proof of identity or permission. That creates a straightforward spoofing and attribution risk, especially in distributed systems where one service can relay requests for another and the original actor is no longer obvious.

Failure mechanism: A downstream service accepts a claimed represented principal from the header, but does not validate the delegation chain or constrain what the intermediary is allowed to assert. An attacker or compromised service can then misstate who initiated the request, bypass intended checks, or obscure the audit trail.

Impact: The result can be unauthorized action, corrupted logs, failed forensics, and weaker separation between service identity and user identity. In delegated workflows, that can also undermine non-repudiation and make privilege abuse harder to detect.

Practitioner Guidance

Why practitioners should care: Treat the header as part of the request context, not as a standalone trust anchor. The security value comes from pairing it with a verified delegation mechanism and a clear policy boundary for what the intermediary may assert on behalf of another principal.

What to watch for: Watch for services that forward or consume the header without checking whether the call path, token, or client credentials actually permit delegation. Also look for logging pipelines that drop the represented principal and leave only the technical caller, because that is where traceability is usually lost.

Practitioner takeaway: Preserve both the acting service and the represented principal, but only trust the latter when the delegation mechanism itself has been authenticated and authorised.

Related resources from NHI Mgmt Group

• How should security teams authorize API requests made by applications on behalf of users?
• Who is accountable when an AI agent runs a query on behalf of a user?
• How should security teams govern personal AI assistants that act on behalf of employees?
• How do organisations keep accountability when agents act on behalf of users?