On-behalf-of

One field is doing two jobs here, and most implementations do the first while describing it as the second. Attribution is the easy half: record the principal on the trace, and a request has a person attached to it, which is what makes an agent’s activity reviewable by anyone other than its author. Authorisation is the half that changes what an agent can do, and it is only real when the named human’s own access actually bounds the call. The distinction is worth policing, because “our agents act on behalf of the user” is a sentence that is true of both and means something entirely different in each.

The design constraint that decides everything else is that the header is a string the caller chose. In most deployments there is no signed claim behind it — no verified subject, no acting-party claim, nothing the receiving side checked. Anything built on top of it therefore has to remain safe when the string is a lie, which is a far stronger requirement than making it work when the string is true. That rules out the intuitive design immediately: an agent must never gain authority by naming somebody, because then naming somebody is the attack.

The construction that satisfies the constraint is to treat the human as one more link in a delegation chain, evaluated by the same rule that every link must allow. Because the chain intersects, the human’s permissions can only subtract. This has a consequence worth stating because it is the footgun an operator reaches for on the first day: a person whose directory group maps to a role granting everything becomes a no-op rather than an escalation, since a wildcard satisfies its own link and cannot satisfy anyone else’s. Order matters too. The agent’s own decision should be taken before any field of the named human is read, so that a request the agent could never have made is refused for the agent’s reason — otherwise an intersection failure quietly overwrites the real cause of a refusal in the record.

The hard part is where the human’s permissions come from, and the honest answer involves a snapshot. The usual source is the group claims captured at that person’s last single sign-on, mapped to roles by an administrator. That is not a live directory read, and pretending otherwise is the single most common overstatement in this area: a group revoked this morning keeps granting until the person signs in again, or until the capture ages past a configured window and the request is refused rather than decided on stale evidence. Identity providers also disagree about whether the claim exists at all. Entra ID stops emitting group claims past roughly two hundred groups and sends a directory-API link instead; Okta requires the claim to be configured and its scope granted; Google Workspace emits no group claim on an ID token, so the intersection is simply unavailable there whatever else is configured. Each of those has to fail closed, and each should fail with a distinguishable reason, because the remedy differs — one person needs to sign in again, another needs an administrator to add a mapping, and an operator mid-rollout has to be able to tell those apart.

The weakness that survives all of this is omission rather than forgery. An agent that names nobody skips the mask entirely and is authorised on its own roles, so the control is opt-out by whoever is attacking it. Requiring a principal per agent closes that, at the cost of breaking every unattended batch job that agent runs, which is why it belongs on the agents where an unattributed call is genuinely the anomaly — a copilot, a ticket triager — rather than as an estate-wide default. And the rollout itself has to be stageable: Token Observe runs the intersection in three settings, where the default reads nothing at all, a shadow setting computes and records what it would have refused, and only the third refuses anything — which means an install that has not reached the third should not describe the intersection as a control it holds.