A2A Protocol 1.0 at the Gateway: Identity, Tenant Routing, and Signed Agent Cards

A2A Protocol 1.0 gives agent platforms a clearer contract for discovery, authentication requirements, protocol selection, and multi-tenant routing. It does not ask every agent framework to invent those fields. It also does not turn an Agent Card into an authorization decision. Production operators still have to validate credentials, select trusted cards, bind tenants to authenticated callers, and restrict which remote agents are reachable.

That distinction matters now. A recent Hacker News discussion about A2A adoption questioned whether the protocol solves a real operational problem or merely adds another abstraction. The A2A 1.0 announcement answers part of that criticism with concrete enterprise-oriented features, including multi-tenancy and signed Agent Cards. The remaining question is how to deploy those features without confusing protocol metadata with runtime trust.

Key Takeaways

• An Agent Card advertises endpoints, protocol bindings, skills, and authentication requirements. It is a discovery contract, not proof that a caller is authorized.
• A2A delegates caller authentication to established web mechanisms and requires the server to authorize requests according to its own policy.
• A2A 1.0 supports URL-based, credential-based, and body-based tenant routing. Operators must decide which input is authoritative.
• Signed Agent Cards protect card integrity and provenance when clients verify the signer and accepted algorithms. They do not authenticate each A2A request.
• A gateway is useful when it consistently enforces the deployment decisions around these protocol features.

What A2A 1.0 Standardizes

A2A connects a client agent to a remote agent without exposing the remote agent's internal framework, memory, or tools. The protocol defines how a client discovers an agent, selects a supported interface, sends messages or tasks, and receives results through synchronous, streaming, or asynchronous interactions.

The A2A core concepts describe three actors: a user, an A2A client acting on the user's behalf, and an A2A server that exposes the remote agent. That separation is useful because identity can exist at more than one layer. The authenticated network caller might be a coordinator service, while the business action is performed for an end user inside a tenant.

The Agent Card is the starting contract. It can advertise:

• the agent's name, provider, version, and skills;
• one or more supported interfaces, including URL, protocol binding, and protocol version;
• security schemes and requirements;
• optional capabilities such as streaming or push notifications;
• optional signatures over the card.

In production, the standard discovery location is typically /.well-known/agent-card.json. The agent discovery guidance also recommends protecting cards that expose sensitive capabilities or internal endpoints. A public card can be cacheable metadata; a detailed card for an internal agent may need authenticated retrieval and selective disclosure.

Three Identity Questions, Not One

An A2A deployment becomes easier to reason about when identity is separated into three questions.

Who Published This Agent Card?

A signed Agent Card can help a client verify that card metadata has not been modified and that it came from a recognized signer. A2A 1.0 uses JSON Web Signature and canonicalized JSON for this purpose. The specification says cards may be signed, and clients should verify signatures when present.

Verification is more than checking that some signature is mathematically valid. The client or gateway also needs a trust policy: which issuers are accepted, how verification keys are obtained, which algorithms are allowed, and what happens when a key or card is revoked. The A2A signing guidance explicitly depends on JWS and the JSON Canonicalization Scheme, but the operator still owns the trust store and failure behavior.

A valid card signature therefore establishes card integrity and signer provenance. It does not prove that the agent is safe, reliable, or approved for every tenant.

Who Is Calling the A2A Server?

A2A does not place user or client identity inside the semantic message payload. Its enterprise security guidance relies on standard web mechanisms such as OAuth 2.0, OpenID Connect, API keys, and transport security. Authentication requirements are advertised in the Agent Card, credentials are acquired out of band, and clients send them through the transport layer.

The A2A server must authenticate incoming requests and authorize operations based on the authenticated identity. Authorization remains implementation-specific because only the server knows which skills, data, and actions a caller may use. This is an important correction to a common framing: A2A does define security responsibilities, even though it does not prescribe one authorization product or policy language.

Which Agent or Tenant Should Receive the Request?

A2A 1.0 adds an optional tenant value to an advertised interface. When the selected interface contains that value, the client must echo it in each request. The value is opaque; the server decides whether it represents a customer, workspace, agent, or another routing key.

That field solves protocol consistency, not tenant authorization. A caller can copy an opaque value unless the deployment binds it to authenticated identity. Treating a client-provided tenant as authoritative without that binding creates an insecure direct-object-reference pattern at the routing layer.

Choosing an A2A Multi-Tenant Routing Model

The official A2A multi-tenancy guide describes three complementary routing approaches.

Routing input	How it works	Primary control to verify
URL path	Each Agent Card advertises a distinct path such as /billing or /support.	Only approved cards and paths are published; route ownership is explicit.
Authentication credential	Claims, scopes, or an API-key mapping select the backend behind a shared URL.	The credential is validated before its identity or scope influences routing.
Request tenant field	The client echoes the opaque tenant value from the selected interface.	The tenant is allowed for the authenticated caller and matches the selected card.

URL routing is simple and easy to inspect, but it may expose a large route catalog. Credential-based routing keeps the message body unchanged, but identity and target selection become tightly coupled. Body-based routing is flexible, but it is safe only when the server or gateway validates the tenant against an authoritative identity.

Many platforms will combine the approaches. A product line may have its own URL, while a tenant value selects a workspace inside that product. The important rule is to define precedence. If the path says billing, a token is scoped to support, and the body names another tenant, the request should fail rather than follow whichever value is easiest to parse.

Where the Gateway Fits

A gateway can enforce the deployment contract around A2A without replacing the protocol.

flowchart LR
    C[A2A client] -->|TLS and caller credential| G[Gateway]
    G --> A[Authenticate caller]
    A --> T[Validate route and tenant binding]
    T --> P[Apply rate and access policy]
    P --> S[A2A server]
    S -->|Task or message result| G
    R[Approved Agent Card registry] -->|Card, signer, interfaces| G

At discovery time, the gateway or an adjacent registry can expose only approved Agent Cards, protect extended cards, and verify accepted signatures. At request time, the gateway can authenticate the transport caller, compare route and tenant inputs, apply rate limits, and forward only the headers the server needs. At response time, it can preserve request IDs and status evidence without logging sensitive task content by default.

This is also where A2A deployment differs from generic agent identity guidance. API7.ai has already explained why agent identity needs gateway accountability. A2A 1.0 adds protocol-specific artifacts to that operating model: preferred interfaces, security declarations, card signatures, and the tenant echo rule.

Signed Agent Cards Are Not Request Signatures

The distinction between discovery integrity and request authentication deserves special attention.

A signed Agent Card protects a canonical representation of the card, excluding the signatures field itself. A client can verify that the advertised URL, skills, security schemes, and interface metadata were not changed after signing. This helps when cards pass through registries, caches, or organizational boundaries.

The card signature does not sign a later task request. It does not prove possession of the caller's OAuth token, prevent replay of an A2A operation, or authorize access to a skill. Those controls still belong to TLS, transport authentication, server authorization, and any request-level protections selected by the deployment.

Operators should also avoid blindly following a key URL supplied by an untrusted card. Signature verification needs an approved key-discovery policy, bounded network access, accepted algorithms, and clear behavior when verification cannot complete. The cryptographic format is standardized; trust establishment is an operational decision.

A Production Checklist for A2A 1.0

Before exposing an A2A server, answer these questions:

1. Where do clients obtain the Agent Card, and is sensitive card content authenticated?
2. Are card signatures required, optional, or ignored for each trust domain?
3. Which issuers, keys, and signature algorithms are accepted?
4. Which security scheme in the card maps to the real gateway or server configuration?
5. Is authorization checked for every task, skill, artifact, and task-management operation?
6. Which routing input is authoritative when URL, credentials, and tenant fields disagree?
7. How is the tenant value bound to the authenticated caller?
8. Which request identifiers and policy outcomes are retained, and which content is redacted?
9. How are card, key, route, or server changes rolled back?

The success condition is not merely that two SDKs can exchange a task. It is that the same caller, card, tenant, and policy decision can be reconstructed when a request is denied, misrouted, or investigated.

Conclusion

A2A 1.0 makes agent interoperability more deployable: cards describe endpoints, transport credentials establish callers, servers authorize requests, tenant fields support shared endpoints, and signatures protect discovery metadata.

A gateway turns those declarations into deployment policy by validating transport identity and tenant routing, exposing approved cards, enforcing traffic policy, and preserving evidence. A signed card does not make an agent trustworthy, and a tenant field does not authorize itself.

For request proxying, AISIX Agent Gateway proxies A2A 0.3 or 1.0 requests with caller authentication, agent grants, and traffic controls, without protocol translation.

In 0.10.0, the Agent Card deserializer requires the legacy top-level url, which pure 1.0 cards omit. Hybrid cards parse, but AISIX rewrites advertised URLs while preserving signatures. A2A canonicalization excludes only signatures, so the rewrite invalidates them. Use this release for governed request proxying, not as a transparent signed-card proxy; keep signed 1.0 discovery outside the rewrite path.