Wiki · Concept · Last reviewed June 25, 2026

A2A Agent Card Signatures

A2A Agent Card signatures are the optional signing mechanism that lets clients verify that an Agent Card has not been tampered with and that it originates from the claimed provider key.

Category: Concept / Agent Infrastructure Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: A2A, Agent Cards, JWS, JCS, Agent Identity, Governance

Definition

A2A Agent Card signatures are the digital-signature mechanism for discovery metadata in Agent2Agent Protocol. An Agent Card describes a remote agent's identity, provider, version, capabilities, skills, supported interfaces, security schemes, and related discovery information. The A2A specification says Agent Cards may be digitally signed using JSON Web Signature, or JWS, to support authenticity and integrity checks.

The signature is important because Agent Cards are routing documents. A client may use them to choose an endpoint, select a protocol binding, decide whether an agent supports push notifications or extended cards, and infer what kind of work the remote agent claims to perform. A forged or modified card can steer delegation before any task message is sent.

Signature Format

The A2A data model defines an AgentCardSignature object. It follows the JSON format of an RFC 7515 JSON Web Signature and includes a required protected field, a required signature field, and an optional header object. The protected field is a base64url-encoded JSON object containing the JWS protected header. The signature field is the computed signature, also base64url-encoded.

The A2A signature-generation process uses JWS header parameters such as alg, typ, and kid, and may use jku for a JSON Web Key Set URL. Those fields let the verifier identify the algorithm and key material needed to validate the card. The v1.0 notes identify RFC 7515 as a new formal dependency for Agent Card signatures.

Canonicalization

Signing JSON is fragile unless implementations agree on the exact bytes being signed. A2A therefore requires Agent Card content to be canonicalized with the JSON Canonicalization Scheme, or JCS, defined in RFC 8785 before signing. The specification says the canonical form must respect Protocol Buffer field-presence semantics: omitted optional fields are excluded, explicitly set optional defaults are included, required fields remain present, and ordinary default values are omitted unless required or optional.

The signatures field is excluded from the material being signed to avoid a circular dependency. After default-value handling and signature-field exclusion, the remaining JSON is canonicalized according to RFC 8785, including predictable property ordering and removal of insignificant whitespace.

Verification

The A2A specification gives clients a verification sequence. A client extracts a signature from the signatures array, retrieves the public key using kid and jku or a trusted key store, removes properties with default values, excludes the signatures field, canonicalizes the resulting JSON with RFC 8785, and verifies the signature against that canonicalized payload.

The same section says clients should verify at least one signature before trusting an Agent Card, retrieve public keys over secure channels, avoid expired or revoked keys, and allow multiple signatures for key rotation. These are integrity controls, not general safety controls. A valid signature can show that a card matches a key-controlled declaration; it does not prove that the agent is competent, lawful, least-privilege, fresh, or safe to receive sensitive context.

Governance Requirements

A governed A2A deployment should log the Agent Card URL, retrieval time, provider, card version, cache status, selected interface, protocol version, signature count, verified signature identifier, kid, key source, verification result, key expiration or revocation status, and whether an authenticated extended Agent Card replaced the public card during the session.

Trust policy should be separate from cryptographic verification. Organizations may require a trusted key store, provider allowlist, certificate or domain checks, signed-card enforcement for high-risk agents, and a revocation path when an agent card is compromised or a provider loses approval. The policy should also say what happens when a card is unsigned, signed by an unknown key, expired in cache, or signed but semantically suspicious.

Failure Modes

Signature theater. A client displays a signed-card badge as if it proves safety, when it only proves integrity relative to a key.

Stale-card reliance. A cached Agent Card remains trusted after the provider changes capabilities, endpoints, policies, or keys.

Key-source confusion. The verifier retrieves keys from an untrusted or redirected jku location without an allowlist or domain policy.

Canonicalization mismatch. Two implementations serialize optional or default fields differently and fail to verify the same intended card.

Malicious truth. A provider signs an Agent Card that accurately represents a harmful or overbroad service.

Source Discipline

Claims about A2A signing should cite the versioned A2A specification, especially the AgentCardSignature object, Agent Card signing section, field-presence rules, and well-known URI security considerations. Claims about the signature standard should cite RFC 7515. Claims about JSON canonicalization should cite RFC 8785. Product claims should not be inferred from the protocol: a signed card is an artifact, not a deployment audit.

Spiralist Reading

An Agent Card signature is a seal on the machine's calling card.

It helps answer whether the card was altered and whether the keyholder made the declaration. It does not answer whether the declaration deserves trust. Spiralism treats that distinction as central. The signature is evidence in the record, not absolution. The ethical work begins after verification, when humans and institutions decide what a signed capability claim is allowed to do.

Open Questions

Sources

Return to Wiki