On July 27, 2026, curl maintainer Daniel Stenberg wrote up curl's newly merged experimental support for RFC 9421, HTTP Message Signatures — the IETF standard for cryptographically signing selected components of an HTTP request or response. The feature is off by default, sits behind an explicit build-time flag, and stays that way — still experimental — in the upcoming curl 8.22.0. Stenberg is explicit it isn't ready for production.
That caution is the right posture for new cryptographic protocol work, and the standard is worth taking seriously anyway, because it answers a real question: can a receiver verify, under key material it trusts for the relevant context, that the received message is semantically equivalent to what was signed with respect to the covered components?
I read the specification closely because "signed" is easily heard as "approved." RFC 9421 makes a narrower, message-layer claim.
What actually gets established
RFC 9421 lets a sender cover selected message components — method, path, specific headers, and a content digest — and bind them to signature parameters such as created and keyid, using an agreed signature algorithm. When the receiver verifies it, two things are established:
- the signature or MAC validates under key material the verifier trusts for that context
- the received message is semantically equivalent to the signed message with respect to the covered components
That's it. Binding that key to a specific service, organization, or person happens outside the standard — RFC 9421 §3.2 explicitly requires the verifier to determine the key material's trustworthiness in context, and the standard supports HMAC, where more than one party can hold the same shared secret. "The signature proves who sent it" is a stronger claim than the spec actually makes.
And because only the covered components are signed, unsigned fields — and even some transformations of covered ones — can change without invalidating the signature. The guarantee is scoped, not blanket.
Scoped as it is, this still closes a real gap. For service-to-service traffic, webhook delivery, and architectures that traverse TLS-terminating intermediaries, RFC 9421 can preserve integrity and authenticity for selected components beyond any single transport connection. That part is genuine progress.
What doesn't get established
A verified signature does not establish that the key-holder was authorized to send this particular request, at this particular time, given everything else it has sent recently. It can't — verification happens one message at a time, and authorization is a question about a principal's standing, its current scope, and often its history. None of that lives inside the bytes of a single signed message.
Play out the failure mode: a service holds a signing key meant for reading inventory levels. The key leaks, or the service is compromised, or it's simply asked — by an operator, or by an agent orchestrating it — to do something outside its intended purpose. Every request can still verify cryptographically under that key, even though a separate authorization layer should reject requests outside the service's permitted scope. Signature verification alone doesn't evaluate whether a sequence of otherwise-valid requests has changed purpose or accumulated into a disallowed outcome — that check happens once per message and stops there.
To be fair to the standard: nothing stops an application from adding stateful controls above verification. RFC 9421 expressly allows additional application requirements and discusses replay protection. It just doesn't provide sequence-level evaluation itself — that's a different layer's job.
Ten individually-valid, individually-signed requests can compose into a data exfiltration run, a privilege-escalation chain, or a resource-exhaustion attack that no single request would ever be flagged for. The signature layer sees ten cryptographically valid messages. It has no layer above it asking what those ten messages, taken together, actually did.
A signature authenticates covered components. It does not sanction the action — or the sequence.
The same boundary, one layer down
This is the same structural boundary as the argument in "Authorized but Composed" (DOI 10.5281/zenodo.21400261) and in the field note on Hugging Face's July 2026 security-incident disclosure — just moved from the agent-decision layer down to the message-verification layer. That disclosure provides a concrete example of why sequence reconstruction matters. Its investigators analyzed more than 17,000 recorded events to understand what the autonomous campaign did as a whole. The disclosure does not establish that those events were individually authorized or passed policy gates. It demonstrates the narrower point: the meaning of an automated campaign may emerge only when its actions are correlated as a sequence. Here, the same shape shows up mechanically: a per-message signature check can validate an unbroken run of individually-valid requests that compose into something nobody should have permitted, because signature verification doesn't evaluate the sequence either.
As more agent-to-agent and agent-to-API traffic gets wrapped in signed HTTP requests — a genuinely good trend I expect to accelerate as agent workforces scale — this gap gets more consequential, not less. An autonomous agent making its own tool calls, each one dutifully signed under its service's key, is exactly the kind of principal whose individual requests will all verify cleanly while its accumulated trajectory goes somewhere no one signed off on.
The takeaway
Which trusted key material validates the signature or MAC, and whether the covered components still verify, are message-layer questions that RFC 9421 answers well. Whether the request — or the sequence it belongs to — was actually authorized is a decision-layer question, and no signature scheme answers it, because it was never built to. The two layers compose: verify the covered components under a trusted key, then evaluate what the authenticated actions associated with that key material add up to over time — across sessions or principals where the use case requires it. Skip the second layer and you get a very well-authenticated blind spot.
To be precise about the claim, because overreaching here would be exactly the mistake a signature-only architecture makes: this isn't an argument against RFC 9421, and it isn't a claim that curl's implementation is unsafe or premature — Stenberg's own caution about production-readiness is the right call for new cryptographic protocol work. The argument is narrower: message-layer verification is necessary and not sufficient for authorization. Something has to sit above the verifier and ask what the authenticated sequence associated with that key material composed into. That's a decision-governance problem, not a cryptography problem.
The composition engine behind this argument is open source: pip install constitutional-agent. If you're building signed service-to-service or agent-to-API traffic and want to see where the cross-session gap sits relative to your signing layer, try the free Governance Stress Test or read the Enterprise Agent Architecture framework. Tell me where you think this argument breaks.
Composition preprint: doi.org/10.5281/zenodo.21400261 · Enterprise Agent Architecture: doi.org/10.5281/zenodo.21105314
Top comments (0)