How do I verify signed messages between A2A (agent-to-agent) agents?

The receiving agent verifies an incoming A2A request by reading the Signature and Signature-Input headers, rebuilding the RFC 9421 signature base from the covered components (method, path, key headers, and the RFC 9530 Content-Digest of the body), and checking the signature against the sender's registered public key, then confirming the credential binding (key anchored, scope valid, not revoked or expired). Verification is offline: it needs the sender's public key, not a vendor call. The free open algovoi-rfc9421-verifier (pip install algovoi-rfc9421-verifier or npm install @algovoi/rfc9421-verifier) does all of it in one call.

← AlgoVoi answers

Answer

How do I add HTTP message signatures to agent-to-agent (A2A) requests?

To add HTTP message signatures to agent-to-agent (A2A) requests, you apply the RFC 9421 standard to your HTTP calls. This ensures each request is authenticated, integrity-protected, and optionally bound to an agent credential for authorization. The process involves signing key parts of the HTTP message (headers, method, path) and attaching the signature in a structured header.

Last updated 21 August 2026

Agent-to-agent workflows rely on HTTP for coordination, but raw HTTP lacks built-in authentication or tamper evidence. RFC 9421 fills this gap by letting agents sign requests and responses, creating a verifiable chain of custody. When combined with Key Credential Binding (KCB), the signature can also prove the agent holds a valid credential, adding authorization to the mix.

Why sign A2A HTTP requests?

Agents exchange data, payments, and decisions over HTTP. Without signatures, you face three risks:

Impersonation: an attacker replays or forges a request.
Tampering: a man-in-the-middle alters headers or payloads.
Repudiation: the sender later denies sending the request.

RFC 9421 signatures solve all three. They bind the request to a cryptographic key, prove the message was not altered, and create a non-repudiable record. For agents, this is the foundation of trust: every call can be traced back to a known identity.

How RFC 9421 signatures work

RFC 9421 defines a way to sign HTTP messages by selecting a set of "covered components" (headers, method, path, query, payload digest) and producing a signature over their canonical form. The signature is then attached to the request in a Signature header. The verifier repeats the canonicalization and checks the signature against the sender's public key.

Step 1: Choose what to sign

You decide which parts of the HTTP message to include in the signature. Common choices:

@method: the HTTP method (GET, POST, etc.).
@path: the request path.
@query: the query string.
host: the Host header.
content-digest: the RFC 9530 digest of the payload.
authorization: if present, to bind the signature to an auth token.

For A2A, you typically sign @method, @path, host, and content-digest. This covers the request line and payload, the two most critical parts.

Step 2: Canonicalize the components

Each component is normalized into a byte string using strict rules. For example:

Headers are lowercased, trimmed, and concatenated with a colon.
The path is percent-decoded and normalized (no duplicate slashes).
The payload digest is computed over the exact bytes sent.

This step ensures the signature is deterministic: the same message always produces the same byte string.

Step 3: Compute the signature

You sign the canonicalized byte string with your private key. RFC 9421 supports multiple algorithms (Ed25519, ECDSA-P256, RSA-PSS). The signature is then base64-encoded and attached to the request in a Signature header.

Example Signature header:

Signature: sig1=:KXF3...gHY=:;keyId="agent-123";created=1712345678;expires=1712349278;headers="(@method @path host content-digest)"

Step 4: Verify the signature

The recipient repeats the canonicalization and checks the signature against the sender's public key. If the signature matches, the request is authentic and untampered.

Binding signatures to agent credentials (KCB)

Signing proves the request came from a known key, but not that the key belongs to a trusted agent. Key Credential Binding (KCB) solves this by binding the RFC 9421 signature to an issued agent credential. The verifier checks four things:

Key anchored: the signature key is registered in the verifier's key registry.
Signature valid: the RFC 9421 signature verifies.
Scope valid: the request falls within the credential's allowed scope.
Credential valid: the credential itself is valid (not revoked, not expired).

With KCB, the signature becomes a proof of authorization, not just authentication. This is critical for A2A workflows where agents act on behalf of users or organizations.

How do I verify signed messages between A2A agents?

The receiving agent verifies an incoming A2A request the same way, in reverse: it reads the Signature and Signature-Input headers, rebuilds the RFC 9421 signature base from the covered components (method, path, key headers and the RFC 9530 Content-Digest of the body), and checks the signature against the sender's public key. Only if that passes does it trust the request. Verification is offline: it needs the sender's public key, not a call back to any vendor.

Validate the Content-Digest (RFC 9530) so you know the body is intact before you trust anything derived from it.
Rebuild the signature base from the components named in Signature-Input, in the exact canonical form RFC 9421 defines.
Verify the signature against the sender's registered public key.
Check the binding (KCB): key anchored, scope valid, credential not revoked or expired.

Use the free, open algovoi-rfc9421-verifier (pip install algovoi-rfc9421-verifier or npm install @algovoi/rfc9421-verifier) to do all four in one call, or the hosted verifier at verify.algovoi.co.uk/rfc9421. See the full walkthrough on verifying RFC 9421 HTTP message signatures.

Do it with AlgoVoi

AlgoVoi provides two open tools to add RFC 9421 signatures to your A2A requests:

algovoi-rfc9421-verifier: a free, open-source verifier for RFC 9421 signatures. Install with pip install algovoi-rfc9421-verifier (Python) or npm install @algovoi/rfc9421-verifier (TypeScript). It handles canonicalization, signature verification, and supports Ed25519 today, with ECDSA-P256 and RSA-PSS on the roadmap. Use it to verify incoming A2A requests in your agent.
Key Credential Binding (KCB): an open package (pip install algovoi-key-credential-binding or npm install @algovoi/key-credential-binding) that binds RFC 9421 signatures to agent credentials. It verifies the four KCB dimensions (key anchored, signature valid, scope valid, credential valid) and ensures the signature is authorized, not just authenticated.

For a hosted verifier, use verify.algovoi.co.uk/rfc9421.

Next steps

Start with the docs to integrate RFC 9421 signatures into your A2A workflows: https://docs.algovoi.co.uk/quickstart.

Related: RFC 9421 HTTP message signatures

A connected set of answers on signing and verifying HTTP messages and agent-to-agent calls under RFC 9421.