3.3 Identity crosses the boundary; authority does not

Book 3 · The Orchestrated OrganizationChapter 3 · section 3 of 6

The two Hermes instances in Chapter 16 refused each other because neither could tell who the other was, and the fix was identity. Move the same problem across an organizational boundary — your operations system taking a task from a partner’s development system, or a supplier’s procurement agent placing an order with yours — and identity turns out to be the part that is nearly finished. Three specifications show what finished looks like and where it stops.

MCP’s authorization specification, in the protocol revision current as of this writing, makes a protected MCP server an OAuth 2.1 resource server. The server publishes protected-resource metadata under RFC 9728 saying which authorization server it trusts; the client must request its token with an RFC 8707 resource indicator naming that server; the server must verify that the token was issued for it specifically; and the specification forbids the shortcut that would otherwise be universal — a server “MUST NOT accept or transit any other tokens,” which means it may not forward the token it received to the next system in line.12 A2A does the equivalent at the agent layer. An Agent Card advertises its securitySchemes in OpenAPI’s vocabulary and may itself be signed with a JSON Web Signature so a client can verify the card came from the provider it claims; the project’s enterprise guidance is explicit that A2A payloads “don’t carry user or client identity information directly,” that identity is established at the transport layer, and that skill-level authorization is the receiving agent’s own policy. Below both sits workload identity. SPIFFE federation lets two independently operated trust domains — a broker and a stock exchange, in the project’s own tutorial — publish bundle endpoints, fetch each other’s trust bundles, and let their workloads authenticate with mutual TLS across the boundary, so a service in one company can prove to a service in another exactly which workload it is.13 The vendor products Chapter 5 surveyed — Entra’s agent identities, Okta’s Agent SSO, Google’s SPIFFE-based agent identity — are these standards with a sponsor and an expiry attached.

Read the three together and notice what every one of them verifies: which workload is calling, which server the token was minted for, and whether the card describing the agent has been tampered with. Those are questions of identity and audience. None of them verifies that the person whose authority the agent is exercising was entitled to delegate it, or that what arrived is a subset of what they delegated. MCP’s rule against token passthrough is correct security, and it is also the mechanism by which authority evaporates at every hop: each system mints a fresh token for the next, and the meaning of that token is decided by the minting system’s authorization server, not by the principal three systems back. A2A puts identity at the transport layer and leaves authorization to the implementation, so two A2A agents can authenticate each other perfectly and still disagree about what the task permits. A SPIFFE identity says which workload; it has no field for on whose behalf, or under which grant. The IETF’s OAuth charter coordinates with the WIMSE working group on “multi-hop workload identities,” and the noun is still identity.

The gap has a precise shape, and naming it precisely is the useful thing an orchestrator can do this year. A receiving system today can answer two questions mechanically — is this really the caller it claims to be, and was this token meant for me — and cannot answer a third: was the authority behind this instruction granted by someone entitled to grant it, and is the instruction inside that grant? The confused-deputy issue open against A2A since April 2025, the context-binding profile proposed in June 2026, and the IETF attenuation drafts are three faces of the same gap, and none has shipped. Until one does, the third question is answered by a contract between the two organizations and by whatever the sending system chose to write down, which means the orchestrator supplies the authority out of band — the handoff file in the next section — and records it where both operating records can reach it. The operating rule is short. A valid identity and a valid token are the entry ticket for a cross-boundary instruction, not the authorization for it, and a system that treats the two as the same thing has automated the confused deputy that Chapter 14’s injection cases exploit by hand. Identity tells you who acted. The harder question, and the one the courts have started answering, is who owns what they did.


  1. MCP authorization specification, revision 2026-07-28, https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization. For HTTP transports, protected servers act as OAuth resource servers, publish metadata, use resource indicators, validate token audience, and reject token passthrough. Authorization is optional, and the specification covers the client-to-server leg rather than how a downstream system preserves the original user’s authority.↩︎

  2. SPIFFE project, “Deploying a Federated SPIRE Architecture,” https://spiffe.io/docs/latest/architecture/federation/readme/ (verified September 9, 2026) — two SPIRE servers in different trust domains (broker.example and stockmarket.example) each expose a federation bundle endpoint, retrieve each other’s trust bundles, and register workloads that “federate with other trust domain” so that “two workloads that need to communicate each other via mTLS” can do so across the boundary. A tutorial, cited for what SPIFFE federation carries — workload identity — and not for adoption. SPIFFE’s identity document is an SVID; nothing in the federation model represents a human principal or a delegated grant.↩︎