We spent two decades teaching the web how to trust people. Passwords, OAuth, WebAuthn, passkeys — each generation a little less phishable than the last. It worked because the client was a human, or a program a human wrote, and there was typically one of them per session.
That assumption has quietly collapsed.
An autonomous AI agent showing up at your API today looks nothing like a human user. A single natural-language prompt — “book me a flight, then add it to my calendar, and email the itinerary” — can fan out into dozens of tool calls across half a dozen vendors, each one made by a different sub-agent, each one a plausible-looking HTTP request that your server has no good way to attribute.
Bearer tokens get replayed. API keys leak into logs. mTLS wants infrastructure no agent framework ships with. OAuth assumes a redirect flow and a human at a keyboard.
None of them answer the question that actually matters in an agentic system:
Did the agent I think I’m talking to send exactly this request, right now, unmodified?
That question has had a standards-track primitive since February 2024 that gets us much closer to an answer: RFC 9421 — HTTP Message Signatures.
What it is — and what it isn’t
HTTP Message Signatures let a client cryptographically sign a well-defined subset of a request — method, target URI, chosen headers, body digest — and attach the signature as two ordinary HTTP headers:
POST /v1/tools/exec HTTP/1.1
Host: api.example.com
Content-Digest: sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:
Signature-Input: sig1=("@method" "@authority" "@path" "content-digest");\
created=1713657600;keyid="agent-42";alg="ed25519"
Signature: sig1=:dHA0...base64...==:
Three things to be honest about from the start:
| RFC 9421 gives you | RFC 9421 does not give you |
| Message integrity (the request wasn’t tampered with) | Authorization (is agent-42 allowed to call this?) |
| Origin authenticity (the holder of the private key signed it) | Intent correctness (did the agent mean to call this?) |
| Portable verification (over proxies, gateways, logs) | Agent legitimacy (is agent-42 a real, sanctioned principal?) |
| A keyid hook for identity discovery | Key distribution, revocation, rotation, reputation |
Everything in the right column still needs a system above the signature — JWKS registries, DID resolvers, policy engines, audit logs. What 9421 gives you is the one primitive all of those systems depend on: a cryptographic binding between a request and a principal.
That may sound like a narrow claim. It isn’t. Today, we don’t have even that.
Why it matters for agents specifically
And note: this complements TLS rather than replacing it. TLS secures the channel, signatures secure the message. One guarantees no one is eavesdropping between you and the next hop; the other guarantees that the request sitting in a log file tomorrow was authored by a specific key.
Agent architectures break three assumptions classical API auth quietly depends on:
- “One call per user action.” Agents fan out. You need per-request attribution, not per-session.
- “The client is a trusted binary.” Agents are stochastic. Sign what was actually sent, not what the developer meant.
- “Delegation is rare.” In the agentic web, delegation is the default: user → orchestrator → sub-agent → tool → upstream API. Multiple 9421 signatures on the same request make this chain legible — we’ll call this the chain of custody and come back to it in Part 3.
Ed25519 is why this is cheap enough to mean it
Pair RFC 9421 with Ed25519 keys — 32-byte public keys, 64-byte signatures, constant-time verify — and you get an HTTP-native identity primitive cheap enough to attach to every tool invocation an agent makes, not just the important ones.
We’ve been landing native RFC 9421 support in curl, with Ed25519 math from wolfCrypt (and OpenSSL for the bigger backends). The goal: make signing an agent request as boring as –user:
curl --httpsig ed25519 \
--httpsig-key agent-42.hex \
--httpsig-keyid agent-42 \
--data-binary @tool_call.json \
https://api.example.com/v1/tools/exec
One flag family. Signatures verifiable by anything that speaks RFC 9421.
Coming up
In Part 2 — The Identity Gap, we’ll compare 9421 to the three things people usually reach for first — AWS SigV4, JWT, and mTLS — honestly, including where those options are genuinely better. Then we’ll survey the (early-stage but rapidly emerging) ecosystem of agent-auth projects building on top: Vestauth, OpenBotAuth, AgentSign, Cloudflare Web Bot Auth.
If you’ve ever squinted at a log line and wondered which of your agents actually made that call — this series is for you.
If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now