Skip to content
Agent Identity

Deployment pattern

All patterns

Multi-hop (one domain)

UserOrchestratorSpecialistAPISPIRE / WIMSE

Multi-hop on-behalf-of inside one domain

/patterns/multi-hop-obo

Orchestrator → specialist → API, still inside one trust domain. RFC 8693 act records who is acting. Transaction tokens carry immutable purpose. WIMSE re-binds the workload identity at each hop. AAuth call chaining (upstream_token / subagent_token) if you are already on AAuth.

When you see it

An orchestrator agent that fans out to a retrieval agent and a payments agent, all in the same cluster, all acting for the employee who started the task. Internal toolchains where every hop is your mesh. If the next hop is another company's AS, that is the cross-domain row.

Actors and trust

  • User (at the start)User

    Authorized the first agent. Must not be silently widened at a later hop.

  • Orchestrator agentAgent instance

    Holds the original grant. Exchanges or re-binds before calling specialists — does not forward the raw user access token.

  • Specialist / downstream APIResource

    Sees an attenuated token: subject = user, act = the calling agent, audience = itself, purpose unchanged.

  • Workload identity issuerWorkload

    SPIRE / WIMSE names each binary so a stolen user token presented by the wrong pod is a different incident.

Topology

UserOrchestratorSpecialistAPISPIRE / WIMSE
  • UserOriginal grant (OAuth or AAuth)Orchestrator
  • SPIRE / WIMSEWorkload identity for this binaryOrchestrator
  • SPIRE / WIMSEHop re-bind for the specialistSpecialist
  • OrchestratorRFC 8693 / txn-token / AAuth subagent_token — attenuatedSpecialist
  • SpecialistAudience-restricted, purpose-frozen callAPI
Same trust domain. Each hop attenuates and re-binds. The user grant does not travel as a raw Bearer token.

Primary

Optional

Do not use

  • Forwarding the original user access token

    Every hop becomes the user. No actor, no attenuation, no audience.

  • Expanding scopes at a hop

    On-behalf-of is a narrowing, not a promotion.

  • Identity chaining

    That draft is for crossing authorization servers / domains. Wrong row.

Why these, and not those

Inside one domain you do not need identity chaining across ASes. You do need a recorded actor (RFC 8693 act), a purpose that cannot grow (transaction tokens), and a workload identity that is re-bound at each hop (WIMSE). Agent-grants and AAP are individual OAuth profiles that try to say the same thing with extra claims — mark them draft/churn. If the fabric is AAuth, call chaining with upstream_token / subagent_token is the analogue: the sub-agent signs with its own key while nested act records the parent. Never expand scopes at a hop. Never forward the original user access token.

Related flows

Sequence diagrams, not this topology cut. All flows

Back to the matrix