X-Webhook-Signature HMAC, destination checks, redaction and delivery authority
remain in place. It does not authenticate incoming agents, issue API credentials
or bypass a webhook recipient’s authorization.
The implementation follows the September 2026
IETF Web Bot Auth working-group draft.
It uses the dictionary form of Signature-Agent. Cloudflare’s separately
documented legacy integration and verified-bot registration are not claimed.
Publish before activating
These commands are for an operator in the application repository with Node 24 and an installed Vercel CLI. The checkout must already be linked through.vercel/project.json; each command requires its explicit project ID and either
production or preview. Production and Preview use independent keyrings.
init creates an independent Ed25519 key with a maximum 90-day lifetime in an
owner-only file beneath .evalgate-runtime/web-bot-auth/. It starts with
activateAt: null: the key can prove possession in the public directory but
cannot sign outgoing requests. Status output includes public fingerprints and
lifecycle state only. Never print, commit, attach or paste the private keyring.
Authority-changing operations hold an exclusive per-keyring lock. A stale lock
is never cleared automatically; verify that its recorded process has stopped
before removing that exact lock file and retrying.
install verifies the linked project and team, inspects the explicit project,
and supplies both environment values through protected stdin using sensitive
Vercel variables. It captures and discards provider output. It never deploys or
promotes anything. Use --vercel-cli /path/to/vercel/dist/index.js when the
installed CLI is elsewhere. Production requires its explicit HTTPS origin;
when the Preview origin variable is unset, the server derives its own
https://<VERCEL_URL> origin.
The environment update must reach the deployment that serves
/.well-known/http-message-signatures-directory before activation. Environment
installation alone is not publication. The endpoint returns a public JWKS with
one possession signature per key, RFC 7638 fingerprints and nbf/exp bounds.
No configured keyring, or no valid published key, produces an unavailable
response rather than an invented identity.
Once the intended HTTPS origin serves that directory, select the public kid
reported by status:
activate fetches the exact canonical directory without following redirects.
It verifies the body digest, expected public key, fresh signature and origin
binding before scheduling activation ten minutes later. It changes only the
local protected keyring. Install the updated schedule and roll it out through
the normal reviewed deployment process. Protected or unavailable deployment
URLs cannot pass publication verification.
During initial pending setup, established HMAC-authenticated webhooks continue
without the extra Web Bot Auth headers. After activation, requests bind the
HTTP method, exact target, final redacted body digest and sender identity, with
a unique nonce and at most 60 seconds of signature validity. An expired or
revoked previously active configuration fails closed; it never silently falls
back to an unsigned sender identity.
Rotate or revoke
activate for its new
fingerprint, then install and roll out the schedule. The previous active key
stays available through activation plus 120 seconds, covering the 30-second
directory cache and 60-second request signatures. The keyring holds at most
three entries; expired or revoked history is pruned only when doing so cannot
turn a failed active signer into pending-only setup.