Wiki · Concept · Last reviewed June 25, 2026

HTTP Message Signatures

HTTP Message Signatures are a standards-track method for signing selected parts of an HTTP request or response, giving verifiers evidence about message integrity, signer identity, and covered components without making the signature a complete authorization decision.

Definition

The HTTP Message Signatures specification is the mechanism specified in RFC 9421, published in February 2024 by A. Backman, J. Richer, and M. Sporny. The IETF datatracker lists it as a Proposed Standard. It defines a way for an application to create, encode, and verify digital signatures or message authentication codes over components of an HTTP message.

The standard is useful because HTTP messages are not always available to sign as one stable byte sequence. Intermediaries, libraries, proxies, transports, and application frameworks can transform safe parts of a message before verification. RFC 9421 therefore builds a signature base from selected fields and derived components rather than assuming that the raw request bytes are identical at each hop.

For AI and agent systems, HTTP Message Signatures are not a safety framework by themselves. They are a lower-level evidence layer: a way to say which request components were bound to which key, algorithm, timestamp, and context.

Mechanism

A signed message carries a Signature-Input field and a Signature field. Signature-Input identifies the covered components and signature parameters. Signature carries the resulting signature value. RFC 9421 also defines derived components such as method, target URI, authority, scheme, path, query, query parameters, and status code, allowing applications to sign protocol meaning rather than only literal headers.

The verifier parses the signature input, determines trusted key material, checks that the algorithm is allowed for the application, reconstructs the signature base from the received message, and applies the appropriate verification algorithm. The RFC is explicit that the verifier must decide whether the key is trustworthy for the context; a cryptographically valid signature from an unknown or inappropriate key is not enough.

Message body integrity is a separate design choice. RFC 9530 defines digest fields including Content-Digest and Repr-Digest. When a body matters, a system can sign a digest-bearing field rather than pretending that a header-only signature protects content that was never covered.

Agent Use

The agent-web relevance comes from request accountability. A crawler, browser agent, shopping agent, enterprise assistant, monitoring service, or API automation can sign the parts of a request that matter to a relying service. The March 2026 IETF Web Bot Auth architecture draft applies HTTP Message Signatures to automated traffic so servers can verify the identity of automated HTTP clients with more confidence than user-agent strings or IP heuristics alone.

The companion HTTP Message Signatures Directory draft proposes one missing piece: key discovery. It describes a JWKS-based key directory, a well-known URI, and a Signature-Agent header for locating signing-key material. Both drafts are Internet-Drafts, not final RFCs, but they show why RFC 9421 is becoming agent infrastructure.

Security Boundaries

The first boundary is coverage. RFC 9421 warns that unsigned portions of a message can be modified without invalidating the signature. For agent traffic, that means a signature receipt should record what was covered, not merely that "the request was signed."

The second boundary is replay. A captured signature can sometimes be attached to another compatible message unless the signed components distinguish the message and the signature includes defenses such as nonce, creation time, and expiration time. TLS still matters because signatures provide integrity over covered components, not confidentiality for the communication.

The third boundary is identity. Reusing a key across verifiers or over long periods can make the signer trackable. That may be desired for a public crawler, but it can be dangerous for user-directed agents that should not become cross-site tracking beacons.

Governance Use

Governance should treat HTTP Message Signatures as receipt material. A signed request can support allowlists, rate limits, bot policy, agent admission, non-repudiation, forensic review, and incident response. It cannot answer whether the agent had the user's authority, whether the requested action was fair, whether content use was licensed, or whether prompt injection changed the agent's intent upstream.

A serious implementation records signer identity, key identifier, algorithm, covered components, signature parameters, digest fields, verification result, policy decision, and retention rule. For high-risk agent requests, that record should connect to the user's mandate, tool permission, and downstream action receipt.

Spiralist Reading

HTTP Message Signatures turn machine action into something less ghostly: a signed trail of selected facts about a request.

The signature does not bless the agent. It does not settle law, consent, price, truth, copyright, privacy, or safety. It only narrows one ambiguity: who, with which key and parameters, stood behind these covered pieces of this HTTP message?

That is still important. The agent-native web cannot run on vibes, scraped headers, and hopeful logs. It needs receipts precise enough to govern, humble enough to admit what they do not cover, and private enough not to turn every delegated task into permanent surveillance.

Sources

Return to Wiki