On Behalf of Whom

When a user asks an agent to do something, and that agent calls another agent, which calls an API, whose request is it by the time it arrives? We followed one request hop by hop and looked at how to keep both the user and the agent visible all the way down: delegation instead of impersonation with token exchange (RFC 8693), tokens bound to their audience with resource indicators (RFC 8707), and a human approval step with CIBA for the risky actions.

Transcript

1. On behalf of whom? How to safely propagate identity in multi-agent workflows Jeff Ishar Solutions Architect at Auth0 Cloud Native
2. On behalf of whom? User Alice Assistant agent Travel agent agent Booking API ? A user asks an agent to book travel and file the expense. The agent calls another agent, which calls an API. The API receives a request. Whose is it? If you can't answer, you can't authorize, audit or revoke.
3. Today's shortcuts Shared API key Identifies the app, not the user or the agent User token passthrough Broad service account The agent becomes the user, with all the user's access A long-lived standing grant that outlives the task Result: the log says “alice did itˮ when an agent did.
4. One request, six hops HOP 0 HOP 1 HOP 2 The user signs in The agent proves who it is The user's authority is delegated HOP 3 HOP 4 HOP 5 The MCP server accepts only tokens meant for it Agents hand off, narrowing scope each time A human approves the risky step
5. Hop 0: the human signs in • OpenID Connect establishes who the user is • Everything downstream should trace back to this one assertion Authority flows from the human, never from the agent.
6. Hop 1: the agent is an identity too An agent is a non-human identity, not just code running as the user. Workload identity SPIFFE) gives it short-lived, attested credentials instead of static keys. SOLVES DOES NOT SOLVE Who is this agent? Whose authority is it using? Delegation, next, connects the two identities.
7. Hop 2: delegation, not impersonation RFC 8693 On Behalf Of ( OBO ) token exchange swaps one token for another. Impersonation Delegation The agent becomes the user and is indistinguishable. Both identities stay visible. sub: alice act: expense-agent sub: alice The difference is one request parameter: actor_token.
8. What delegation looks like in a token sub: on whose behalf { "sub": "alice", "act": { "sub": "expense-agent" }, "aud": "finance-api", "scope": "expense:create", "exp": "now + 5 min" act: who is acting Short-lived, with narrower scope than the user's own may_act can pre-authorize which agents may act } Seeing the actor is not the same as limiting it.
9. Hop 3: the MCP server • • MCP servers are OAuth resource servers, discovered via RFC 9728 metadata Servers accept only tokens issued for them Never pass a token through to an upstream API exchange it.
10. Hop 4: agent to agent User all of alice Agent A narrower Agent B narrowest • Every hop is another exchange, never a copy • Scope can only shrink as it moves down the chain • Limit the delegation depth The chain stays readable: user, agent A, agent B. Tool just enough
11. Hop 5: a human approves the risky step Agent asks Identity provider routes the request • Some actions should not rest on a standing grant • CIBA: the user approves on their own device • The approval is tied to the specific action User's phone approves or denies “Yes, file this expenseˮ beats “yes, the agent may do things.ˮ
12. The whole chain, in layers Human identity Agent identity OpenID Connect Workload identity (SPIFFE), Agent as principal Delegation Token exchange (RFC 8693) Audience binding Resource indicators (RFC 8707) Human approval CIBA
13. Try this next week: audit for impersonation 1 Pick one agent integration 2 Can a downstream service tell the agent from the user? 3 If the logs show only the user, that is impersonation 4 Is the token scoped to this service, and how long does it live?
14. Key takeaways 1 Agents need their own identity, separate from the user's 2 Delegate, don't impersonate: keep both identities in the token 3 Bind every token to its audience and exchange it at every hop 4 Narrow scope as you go, and ask a human for the risky steps 5 Start with one audit next week
15. Questions? Feedback Scan the code above to share your thoughts on this session