HTTP Message Signatures (RFC 9421)

What HTTP Message Signatures are

HTTP Message Signatures are defined in RFC 9421, an IETF standard for creating and verifying digital signatures over parts of an HTTP request or response. A client chooses which components to cover (for example the method, the target URI, the authority and selected headers), builds a canonical signature base from them, and signs it with a private key. The result travels in two headers: Signature-Input (Section 4.1), which lists the covered components and parameters such as created, expires, keyid and alg, and Signature (Section 4.2), which carries the signature value itself. Both use the Structured Field Values syntax of RFC 9651.

The receiver rebuilds the same signature base (Section 2.5) from the request it actually received, looks up the public key referenced by keyid, and checks the signature. If anything covered by the signature changed in transit, verification fails.

Why they matter for apps, APIs and MCP servers

Most automated traffic identifies itself with a user-agent string or a self-chosen client name. Both are trivial to copy. A message signature is different: it ties a request to a key, and only the holder of the private key can produce a valid signature. For an application receiving traffic from crawlers, assistants and autonomous agents, that turns "this client says it is X" into "this request was signed by the key X publishes".

That distinction is the foundation for treating cooperating automated clients as known participants rather than anonymous traffic. It lets an API route a signed crawler to a structured endpoint, apply a different rate limit to a known operator, or give an MCP server more context about who is calling a tool.

How verification works in practice

1. Parse Signature-Input and Signature and confirm the expected components are covered. A signature that covers nothing useful proves little.
2. Check the created and expires parameters to reject stale or replayed requests within your tolerance (see Section 7.2.2 on signature replay).
3. Resolve keyid to a public key from a source you trust, such as a key directory the operator publishes at a known location. The IETF Web Bot Auth protocol draft defines such a directory for automated clients.
4. Rebuild the signature base exactly as specified and verify it with the declared algorithm.
5. Record what was verified and in which context, so later decisions can reference it.

In production, use a maintained RFC 9421 implementation rather than hand-rolled parsing: canonicalization details are easy to get wrong. The guide on how to verify signed AI agent requests walks through each step with code.

What a valid signature does and does not prove

A valid signature proves that the request was signed by a key, and, if the key is published under a domain, that the request is associated with that domain's operator. It does not prove:

• that the operator is honest or the action is safe,
• that a person instructed or approved the request (see delegated authority),
• that the client is permitted to do what it is asking (see agent authorization).

Identity evidence and permission are separate questions. Your application's own authentication and authorization still decide what a client may do. Our blog post on what signed AI agent requests prove, and what they don't covers this in more depth.

Common misconceptions

• "Signed means trusted." Signed means attributable. Trust is a policy decision you make about the attributed party.
• "Signatures replace API keys." They answer a different question. An API key says which account is calling; a signature says which client produced the request. Many deployments benefit from both.
• "Unsigned traffic is malicious." Most automated traffic today is unsigned. Missing signatures reduce what can be established, nothing more. That is why Unknown is a first-class result.

How Proof of Actor treats signatures

In Proof of Actor, a signature that validates against a published key is recorded with the basis verified, scoped to exactly what the check established: the key and the identifier it belongs to. The resulting class (usually Agent) never implies authorization. Results flow into Understand for analysis and into Route, where your own policies decide whether a signed client gets a structured path, a different limit, or no change at all. Signed-agent standards such as Web Bot Auth are evolving, and Proof of Actor is designed to verify signed requests as they mature.

Read more on what the evidence can establish, or apply for early access.

Sources

• RFC 9421: HTTP Message Signatures: the IETF standard defining signature components, parameters and verification
• RFC 9651: Structured Field Values for HTTP: the syntax of Signature-Input and Signature
• draft-ietf-webbotauth-httpsig-protocol: IETF Web Bot Auth draft applying RFC 9421 to automated clients (work in progress as of November 2026)