Web Bot Auth directory — agent readiness

Why an agent cares

It is how an automated client proves its identity instead of being judged on a user-agent string, which is the basis of every allowlist that is not guesswork. We read the published key directory, so the population that can get it wrong is signing operators.

Adoption

Early production. Several independent organisations run it in production, though it is still niche on the open web.

Direction of travel: ▲ rising, as at 2026-09-15.

OpenAI signs its agent traffic in production, Cloudflare, Vercel and Akamai verify those signatures, and Amazon Bedrock AgentCore signs by default. Deployment ran ahead of the standard: the IETF working group adopted its first draft in September 2026.

Adopter	Depth	Evidence
OpenAI (signs ChatGPT agent and Operator requests)	`production`	help.openai.com
Cloudflare (signed agents, Verified Bots)	`production`	blog.cloudflare.com
Vercel (verifies signatures)	`production`	vercel.com
Amazon (Bedrock AgentCore Browser)	`default-on`	coronium.io

What we check

Absence is never a finding. Every check below runs only when this technology is detected, so a site that has not adopted this is not assessed on it and appears in no report. 9 of these 9 can fail it. In Lumar these appear once per site, in the site-wide results of each crawl.

Check	Severity	Raises	On whose authority
Web Bot Auth Malformed Directory	high	conformance, usability	specification: JSON Web Key (JWK)
Supporting documents: JSON Web Key (JWK) Required by JSON Web Key (JWK). Bad: the served file isn't a conformant JWKS (invalid JSON, or its "keys" isn't an array per RFC 7517), so no keys can be read. Fix: serve {"keys": [ ...JWKs... ]} as valid JSON.
Web Bot Auth Missing Keys	high	usability	specification: Web Bot Auth: HTTP message signatures for bots (IETF working-group draft)
Supporting documents: Web Bot Auth: HTTP message signatures for bots (IETF working-group draft) Related guidance in Web Bot Auth: HTTP message signatures for bots (IETF working-group draft). Bad: the JWKS is served but lists no keys, so there's nothing to verify signed bot requests against. Fix: publish the bot's public verification key(s) in the keys array.
Web Bot Auth Invalid Key	high	conformance, usability	specification: JSON Web Key (JWK), HTTP Message Signatures, Web Bot Auth: HTTP message signatures for bots (IETF working-group draft)
Supporting documents: JSON Web Key (JWK), HTTP Message Signatures, Web Bot Auth: HTTP message signatures for bots (IETF working-group draft) Required by JSON Web Key (JWK), HTTP Message Signatures and Web Bot Auth: HTTP message signatures for bots (IETF working-group draft). Bad: keys are listed but none carries usable public verification material for HTTP message signatures (Ed25519, EC P-256/P-384, or RSA with well-formed base64url params). A key whose material is sound but whose "alg" is spelled the JOSE way is NOT this defect — that is Unregistered Alg Name, and it is a one-word fix. Fix: publish a conformant public JWK, e.g. an OKP Ed25519 key with a valid base64url "x".
Web Bot Auth Private Key Exposed	high	conformance, usability, security (CWE-522)	specification: JSON Web Key (JWK)
Supporting documents: JSON Web Key (JWK) Required by JSON Web Key (JWK). Provisional security check; precision has not yet been measured. Bad (high severity): a published key includes private material (a JWK d/p/q/… member), so the site has leaked its signing key and anyone can impersonate its bots. Fix immediately: remove the private members, publish public keys only, and rotate the compromised key. Exposed identity material or weak authentication can enable identity misuse. OWASP Agentic ASI03 (2026) — Identity & Privilege Abuse OWASP API API2 (2023) — Broken Authentication ASVS V13.3.2 (5.0.0) — Restrict access to secrets Actual credential use, permissions and privilege abuse are not tested. Related guidance does not establish exploitation or framework compliance. Security checks are provisional.
Web Bot Auth Test Key	high	usability, security (CWE-1394)	specification: Web Bot Auth: HTTP message signatures for bots (IETF working-group draft), HTTP Message Signatures, CFRG keys in JOSE, JSON Web Key (JWK), JSON Web Signature, JOSE examples
Supporting documents: Web Bot Auth: HTTP message signatures for bots (IETF working-group draft), HTTP Message Signatures, CFRG keys in JOSE, JSON Web Key (JWK), JSON Web Signature, JOSE examples Related guidance in Web Bot Auth: HTTP message signatures for bots (IETF working-group draft), HTTP Message Signatures, CFRG keys in JOSE, JSON Web Key (JWK), JSON Web Signature and JOSE examples. Provisional security check; precision has not yet been measured. Bad: the directory publishes one of RFC 9421's example keys, whose private half is printed in the RFC: verifiers that follow the draft reject your bots, and any that don't would accept forgeries from anyone. RFC 9421 allows these keys only for testing. Fix: generate a new key pair, publish only its public half, and sign with it. Exposed identity material or weak authentication can enable identity misuse. OWASP Agentic ASI03 (2026) — Identity & Privilege Abuse OWASP API API2 (2023) — Broken Authentication ASVS V13.3.2 (5.0.0) — Restrict access to secrets Actual credential use, permissions and privilege abuse are not tested. Related guidance does not establish exploitation or framework compliance. Security checks are provisional.
webBotAuth HTTPS Downgrade	medium	usability, security (CWE-319)	Lumar readiness bar
An advertised HTTP destination permits unencrypted communication. OWASP API API8 (2023) — Security Misconfiguration ASVS V12.2.1 (5.0.0) — TLS for external HTTP services Only advertised transport configuration is observed; API deployment security is not fully assessed. Related guidance does not establish exploitation or framework compliance. Security checks are provisional.
Web Bot Auth Weak RSA Key	medium	usability, security (CWE-326)	specification: JSON Web Algorithms
Supporting documents: JSON Web Algorithms Client requirements in JSON Web Algorithms. Provisional security check; precision has not yet been measured. A published RSA verification key has a modulus below 2048 significant bits. RFC 7518 sets this minimum for RSA signature algorithms; runtime use is not observed. Fix: replace the weak key, internal destination or downgraded transport with the intended public secure configuration, as applicable. A published RSA modulus is below the supported algorithms’ minimum key strength. OWASP API API8 (2023) — Security Misconfiguration Only modulus size is checked; key generation, storage, runtime usage and signature verification are unassessed. Related guidance does not establish exploitation or framework compliance. Security checks are provisional.
Web Bot Auth Unregistered Alg Name	medium	conformance, usability	specification: Web Bot Auth: HTTP message signatures for bots (IETF working-group draft)
Supporting documents: Web Bot Auth: HTTP message signatures for bots (IETF working-group draft) Required by Web Bot Auth: HTTP message signatures for bots (IETF working-group draft). Bad: a key's material is fine, but its "alg" uses the JOSE spelling (EdDSA, ES256, RS256) where the directory draft requires a name from the HTTP Signature Algorithms registry, so a strict verifier rejects the key it could otherwise have used. Fix: rename the algorithm, e.g. "alg": "ed25519" for an Ed25519 key, "ecdsa-p256-sha256" for P-256. This is separate from Invalid Key, which means no key carries usable public material at all.
Web Bot Auth Wrong Media Type	medium	conformance, usability	specification: Web Bot Auth: HTTP message signatures for bots (IETF working-group draft)
Supporting documents: Web Bot Auth: HTTP message signatures for bots (IETF working-group draft) Required by Web Bot Auth: HTTP message signatures for bots (IETF working-group draft). Bad: the directory isn't served with the draft's required media type (a missing Content-Type also fails), so strict verifiers reject the response. Fix: set Content-Type: application/http-message-signatures-directory+json on the response.

Examples

Both run through the same checks as a live scan: the first passes, the second is flagged.

correctjson

{
  "keys": [
    {
      "kty": "OKP",
      "crv": "Ed25519",
      "x": "hhsWfvG6EQ1kRa2CH_90BaGBZ2UIlQ4oJEnVnJBsTkk"
    }
  ]
}

present but wrongjson

{
  "keys": [
    {
      "kty": "OKP",
      "crv": "Ed25519",
      "x": "tooShort"
    }
  ]
}

Specifications

Document	Revision	Kind
RFC 7515 — JSON Web Signature	Published RFC	specification
RFC 7518 — JSON Web Algorithms	Published RFC	specification
Web Bot Auth: HTTP message signatures for bots (IETF working-group draft)	Draft, 1 September 2026	specification
RFC 8037 — CFRG keys in JOSE	Published RFC	specification
RFC 7520 — JOSE examples	Published RFC	specification
RFC 9421 — HTTP Message Signatures	Published RFC	specification
Cloudflare — Web Bot Auth verification	Living document	vendor profile
Google — Web Bot Auth for crawlers	Living document	vendor profile
RFC 7517 — JSON Web Key (JWK)	Published RFC	specification

Last re-read against the published documents: 2026-10-05.