The A2A specification is unusually honest about what it does not do.
Authentication it delegates to the web: HTTP headers, OAuth2, OpenID Connect, with the Agent Card's security field advertising which schemes a remote agent accepts. Authorization it hands back to you. The spec says authorization logic is specific to the agent's implementation, the data it handles, and the enterprise policies that apply. When a task needs extra credentials mid-flight, the client is told to obtain them through a process outside the A2A protocol itself.
The scope boundaries are stated plainly:
| In scope | Out of scope |
|---|---|
| Transport security (TLS) | Federated identity |
| HTTP-layer authentication | Delegated authority models |
| Skill-based access control | Cross-boundary permission frameworks |
This is not a criticism. A protocol that tried to specify cross-organizational delegation in v1.0 would not have reached 150 organizations, a Linux Foundation home, and native support in Azure AI Foundry, Bedrock AgentCore and Google Cloud inside a year. Punting was the right call.
But it leaves a question open. When an agent at one company asks an agent at another company to do something, what authorizes that?
We went looking for the product that answers it. This post is what we found, which is mostly an absence.
"Cross-boundary" is four different problems
The phrase covers four cases that have very little in common. Three of them are solved. The fourth is the one people mean when they say A2A.
| The crossing | Status | |
|---|---|---|
| ① | An agent calls a third-party SaaS tool on behalf of a user | Solved. OAuth plus a token vault |
| ② | An agent in app A reaches app B, both connected to one enterprise IdP | Solved in 2026. Cross-App Access |
| ③ | A workload authenticates to a workload in another trust domain | Partial. SPIFFE Federation |
| ④ | An agent in org A delegates to an agent in org B, carrying attenuated, revocable, auditable authority derived from a human | No product exists |
Case ① is a solved commercial problem. Arcade, Descope, Stytch and Auth0's Token Vault all ship a version of it. The user consents once through normal OAuth, the platform holds the refresh token, the agent gets a scoped access token per action. This is what most "agent auth" companies are actually selling today.
Case ② got solved this summer. It is worth understanding precisely, because it is the one most likely to be mistaken for case ④. Cross-App Access uses OAuth 2.0 Token Exchange to mint an assertion and the JWT Bearer grant to redeem it, following the Enterprise-Managed Authorization extension added to MCP in June. Okta took Agent SSO to general availability on August 24 and folded it into core SSO plans at no extra cost. Descope shipped ID-JAG validation on September 1. The authorization-server list already includes Auth0, Athenz, Descope, Keycloak, Ping, Scalekit and Stytch. The adopter list includes Anthropic, Asana, Atlassian, Canva, Datadog, Figma, Linear, Slack and WorkOS.
That is real, and it genuinely spans companies: an enterprise IdP issues, a different vendor's app validates. But look at the trust topology. There is exactly one root, and every participant has been connected to it in advance. The enterprise IdP is the hub, both apps are spokes. It is hub-and-spoke federation, and it is agent-to-application, not agent-to-agent.
Case ③ has real infrastructure and a known seam. SPIFFE issues cryptographic identities to workloads, and SPIFFE Federation extends trust across domains through trust bundles exchanged bilaterally. It works. But it carries workload identity, not the human delegation behind the request. The documented limitation is that SPIFFE does not carry identity across the MCP-to-A2A hop between organizations. It tells org B that a machine from org A is calling. It does not say on whose behalf, under what constraint, or for how long.
Case ④, and why it stays empty
Case ④ needs something none of the above provides. Authority that travels, narrows at each hop, names the human it came from, can be checked by a stranger, and can be killed.
We could not find a shipping product that does this. What exists instead is a standards conversation, and the most useful document in it is a requirements draft that proposes nothing at all.
draft-reece-wimse-cross-org-delegation-00, in the IETF's WIMSE working group, lists six challenges: recursive attenuation across hops, verification without a pre-existing agreement, decisions without runtime callbacks, binding to a human principal without creating a confused deputy, cross-domain revocation and freshness, and composable audit across organizations. Then it states requirements and stops. Four are worth quoting directly:
R1: The mechanism MUST allow authority to be delegated through multiple hops such that each hop conveys a subset of the authority of the preceding hop
R3: The mechanism MUST permit a relying party to reach an authorization decision without a synchronous call to the originating organization on the critical path
R5: The mechanism MUST be able to convey the on-behalf-of principal along the delegation chain and MUST allow a relying party to verify that intermediary agents have not altered the identity
R7: The mechanism MUST support revocation whose authenticity is verifiable offline and whose staleness is bounded
The draft then names the tension it cannot resolve. R3 and R7 pull against each other. You cannot both decide offline and revoke instantly. Any solution has to make staleness explicit and fail safely, and the document offers no approach for doing so.
A second draft does propose a mechanism. draft-mishra-oauth-agent-grants-00 gives each agent a DID, runs an OAuth-shaped consent flow with a human, and issues signed JWTs carrying agt, dev, grnt, scp, parentAgt, parentGrnt and delegationDepth. A sub-agent's scopes must be a strict subset of its parent's. Delegation depth is capped, defaulting to three. A child token cannot outlive its parent. Revoking a parent invalidates every descendant, and the draft requires that to happen inside a single recursive transaction so no validity window opens.
The research side reaches the same place. Governance Gaps in Agent Interoperability Protocols finds that MCP, A2A and ACP cannot express cross-organizational delegation, cannot represent consent or bind a delegation to a stated purpose, cannot revoke across a chain, and cannot attribute an action to the agent that took it or the principal behind it.
Two IETF drafts and a paper naming the hole. That is the state of the art.
Why the square is empty
The obvious explanation is that case ④ is hard. It is hard. But that is not the main reason.
Case ④ is a two-sided adoption problem. Cases ①, ② and ③ can each be sold to one buyer. A developer who wants their agent to reach Gmail. An enterprise that wants its IdP to stay authoritative. A platform team that wants mTLS between services. Each of those produces value the day one party adopts it.
Case ④ produces value only when both organizations have adopted the same thing. There is no version you can sell to a single customer and have it work. That is the hardest go-to-market shape there is, and it explains the market better than difficulty does. It is why this work sits in a standards body instead of a product.
It should also temper anyone's excitement about an empty square. An empty square on a market map is not automatically an opportunity.
There are two ways through, and we only see two. Solve the single-organization case first, well enough that the cross-organization case becomes an extension rather than a prerequisite. Or anchor on the standard, so that adopting you is not a bilateral commitment to you. It is a bilateral commitment to a specification, and you are the first implementation.
We are taking the second path, and those four requirements are why.
R3 is the one that shapes everything else. If a relying party cannot decide without calling back to the originating organization, then every cross-boundary request inherits someone else's uptime. That is not a preference you can trade away later, and it decides where permission data has to live.
R5 is the one we find most interesting. A relying party has to be able to check that nothing in the middle rewrote who the request is for. The usual answer is a rule name in an audit log, which tells you which line matched and nothing else. We take the other approach: our audit events carry a content identifier for the exact authority set a decision was made against. A stranger can reconstruct the whole grant from it and check the decision themselves.
That is the property case ④ actually needs, and nobody is shipping it yet. We would rather build toward a specification that does not exist than a product that only works inside one company's walls.
If you are building on A2A and assumed the permission story was handled: it is listed as out of scope, in the spec, in writing. Worth reading before you need it.