Why architecture matters here
A2A auth matters because agents are autonomous actors that take actions, so verifying their identity and authority is essential to security — especially as agents act across organizational boundaries. An agent calling another agent may trigger real actions (accessing data, invoking operations, making changes), so the called agent must know who the caller is (authentication) and whether it may do what it's asking (authorization) — just like any API, but with the added stakes of autonomous agents that may be manipulated (prompt injection) or misbehave. And as agents interconnect across organizations (an agent from company A calling an agent from company B), the auth must work across trust boundaries (federated identity, cross-org authorization) — a harder problem than within-organization auth. Getting A2A auth right (proper authentication, least-privilege authorization, secure delegation, cross-org trust) is foundational to a secure agent ecosystem; getting it wrong (weak authentication, over-broad authorization, insecure delegation) opens the agent ecosystem to abuse (impersonation, unauthorized actions, privilege escalation). For any system where agents call agents — especially across organizations — auth is a first-order security concern.
The delegation dimension is what makes agent auth distinctively complex, and it's the key concept for agents acting on behalf of users. An agent frequently acts on behalf of a user — a user's assistant agent calling another agent to perform a task for the user. The agent's authority in this case derives from the user (the agent should be able to do what the user is authorized to do, for this task, not what the agent itself might do generally). This is delegation: the user delegates authority to the agent (for a scope of actions), and the agent acts with that delegated authority. Delegation must be handled securely — the agent should only have the authority the user delegated (scoped to the task, not unlimited), the delegation should be verifiable (the called agent can verify the agent is legitimately acting for the user), and it should be revocable (the user can revoke the delegation). OAuth's delegation mechanisms (tokens representing delegated authority, scopes limiting it) provide this. Getting delegation right — the agent has exactly the user's delegated authority, scoped and verifiable and revocable — is central to agent auth (since agents so often act for users), and getting it wrong (over-broad delegation, unverifiable delegation) is a serious security gap (an agent with more authority than the user delegated, or impersonating a user without verification). Understanding delegation — the agent's authority deriving from and scoped to the user's — is understanding the distinctive complexity of agent auth.
And the cross-org trust challenge is what makes A2A auth harder than within-org auth, and it's the frontier of agent interoperability. Within an organization, agents can share a trust domain (a common identity provider, shared authorization policies) — auth is relatively straightforward (established trust). But agents interconnecting across organizations (the vision of an open agent ecosystem — agents from different companies calling each other) face the cross-org trust problem: how does an agent from company A trust an agent from company B (different identity providers, no shared trust)? This requires federated identity (mechanisms for one organization to trust another's identity assertions — via standards like OIDC federation, verifiable credentials, or established trust relationships) and cross-org authorization (how company B's agent decides whether to trust and authorize company A's agent, and any user delegation involved). This is genuinely hard (it's the same federation problem the web faced, applied to agents) and is a frontier of A2A (the standards and practices for cross-org agent trust are evolving). Understanding that cross-org trust is the hard, evolving part of A2A auth — the federation of identity and authorization across organizational boundaries — is understanding both the promise (an interoperable agent ecosystem) and the challenge (secure cross-org trust) of A2A.
The architecture: every piece explained
Top row: identity and tokens. Agent identity: agents have verifiable identities (via verifiable credentials, certificates, or identity provider registration) — the basis for authentication. OAuth / OIDC: token-based authentication (the agent presents a token proving its identity/authority; OIDC for identity, OAuth for authorization) — the standard mechanism (reusing established web auth). Scopes and claims: the token carries scopes (what the agent may do — the granted permissions) and claims (assertions about the agent/user — identity, attributes) — defining the agent's authority. Delegation: mechanisms for an agent acting on behalf of a user (the token represents delegated user authority, scoped to the task) — handling the common case of agents acting for users.
Middle row: the mechanisms. Agent card auth: the agent's card (its public description) declares its authentication requirements (the auth schemes it requires — OAuth, API key, mTLS) — so callers know how to authenticate. mTLS / signatures: transport security (mutual TLS — both parties authenticate at the transport layer) and message integrity (signatures on messages — verifying they weren't tampered with, proving the sender) — securing the communication. Trust establishment: deciding who to trust and how — for known agents (established trust relationships), for dynamically-discovered agents (verifying credentials, checking against trusted registries) — the trust decision. Token exchange: cross-domain delegation (an agent exchanging a token from its domain for one valid in another — for calling across trust boundaries with delegated authority) — enabling cross-org delegated calls.
Bottom rows: authorization and federation. Authorization decisions: deciding whether an authenticated agent may invoke a capability — policy per capability (which callers, with which scopes/claims, may invoke which capabilities) — the authorization layer (authentication says who; authorization says whether they may). Cross-org trust: federated agents (agents from different organizations) — federated identity (trusting another org's identity assertions) and cross-org authorization (deciding to authorize another org's agent) — the hard, evolving frontier. The ops strip: credential management (managing the agents' credentials/tokens securely — issuance, rotation, revocation, secure storage — the operational foundation), scope minimization (least-privilege — agents and delegations having the minimum scope needed, limiting the blast radius of compromise), and audit (logging authentication and authorization decisions — who called what, authorized how — for security and compliance).
End-to-end flow
Trace a delegated cross-org agent call. A user's assistant agent (company A) needs to book a service via a booking agent (company B) on the user's behalf. Authentication and delegation: the user has authorized their assistant agent to act on their behalf for booking (delegation — the assistant holds a token representing the user's delegated authority, scoped to booking). The assistant agent, calling company B's booking agent, must authenticate (proving its identity — company A's agent) and present the delegation (proving it acts for the user, with the user's scoped authority). Cross-org: company B's booking agent must trust company A's identity (federated trust — an established relationship or verifiable credentials) and verify the delegation (the assistant legitimately acts for the user, with booking authority). If the trust and delegation verify, company B's agent authorizes the booking (the assistant, acting for the user with booking scope, may book) and performs it. The call succeeded with proper authentication (company A's agent identity), delegation (the user's scoped authority), and cross-org trust (company B trusting company A) — the A2A auth handling the delegated cross-org call securely.
The scope-minimization and token-exchange vignettes show the security discipline. A scope case: the user's delegation to the assistant is scoped narrowly (booking only, not the user's full authority) — so even if the assistant agent were compromised (prompt injection), it could only book (its delegated scope), not do more (the least-privilege limiting the blast radius). The team designs delegations with minimal scope (the agent gets exactly the authority needed for the task, no more) — the scope-minimization discipline. A token-exchange case: the assistant's token (valid in company A's domain) can't be directly used at company B (different domain); the assistant exchanges it (token exchange — trading the company-A token for one valid at company B, carrying the delegated authority) — enabling the cross-domain call with the delegated authority. The token exchange bridged the trust domains while preserving the delegation.
The trust-establishment and audit vignettes complete it. A trust case: the assistant agent discovers a new booking agent (not previously known) — before trusting it, the assistant verifies its credentials (checking the agent's verifiable credentials or its registration in a trusted registry) and its declared auth (from its agent card) — establishing trust before calling (not blindly trusting a discovered agent). An audit case: all the authentication and authorization decisions (the assistant authenticated as company A's agent, presented the user's booking delegation, was authorized to book) are logged — providing an audit trail (who acted for whom, authorized how) for security investigation and compliance. The consolidated discipline the team documents: authenticate agents (verifiable identity, OAuth/OIDC tokens), handle delegation securely (agents acting for users with scoped, verifiable, revocable delegated authority), minimize scopes (least-privilege limiting compromise blast radius), establish trust before calling (verify credentials, check registries — especially for discovered/cross-org agents), use token exchange for cross-domain delegation, make authorization decisions per capability (policy about who may invoke what), handle cross-org trust (federated identity and authorization — the evolving frontier), manage credentials securely, and audit auth decisions — because A2A auth is foundational to a secure agent ecosystem, verifying agent identity and authority (especially delegated and cross-org) so that agents calling agents is secure rather than an avenue for impersonation and unauthorized action.