Web Bot Auth vs CAPTCHA: naming the bot or testing for a human

A CAPTCHA is for telling humans and automated clients apart, so a site can serve people and stop bots, either through a challenge the visitor solves or through a background risk score. Web Bot Auth is for letting an automated client, such as a crawler or an AI agent browsing for a user, sign its HTTP requests so a site can verify which operator sent them and apply its own policy to that operator.

The two start from opposite assumptions. A CAPTCHA assumes automation is unwelcome and tries to exclude it. Web Bot Auth assumes some automation is welcome and gives it a way to identify itself. A site that wants to admit some agents and block others needs the second, and may keep the first for anonymous traffic.

Status as of September 26, 2026. Web Bot Auth is an IETF working group, chartered on October 23, 2025. Its protocol document, draft-ietf-webbotauth-httpsig-protocol-00, was published on September 1, 2026 by authors from Cloudflare and Google. It is an Internet-Draft and can still change. It builds on RFC 9421, HTTP Message Signatures (February 2024). Cloudflare uses Web Bot Auth as a verification method for verified bots and agents; its documentation still cites the earlier individual drafts. CAPTCHAs have no standard. They are vendor services, such as Google reCAPTCHA and Cloudflare Turnstile, and their accessibility problems are documented in a W3C Group Draft Note from December 16, 2021.

What CAPTCHAs are for

A CAPTCHA protects an action, typically a sign-up, a login, a comment form or a checkout, from automated abuse. Modern services work in two ways:

• Challenges. The visitor solves a task believed to be easy for people and hard for programs, such as reading distorted text or picking images.
• Risk scores. The service watches the interaction in the background. Google’s reCAPTCHA v3 returns a score from 0.0 (very likely a bot) to 1.0 (very likely a good interaction) without interrupting the user, and the site decides what to do with it.

Either way, the browser receives a token and the site’s server verifies it with the vendor. The tokens are short-lived: reCAPTCHA tokens expire after two minutes, and a Cloudflare Turnstile token is valid for 300 seconds and can be validated only once.

The costs fall on people. W3C’s note on the inaccessibility of CAPTCHA says interactive tests inherently exclude many people with disabilities, and that research finds many popular techniques no longer very effective or secure. WCAG 2.2 success criterion 3.3.8, Accessible Authentication (Minimum), allows object-recognition tests at Level AA only as an exception, and the AAA criterion 3.3.9 removes that exception.

A CAPTCHA also answers only one question: human or not. It says nothing about which program is visiting, and it treats a customer’s own agent the same as an abusive scraper.

What Web Bot Auth is for

Web Bot Auth gives an automated client a verifiable name. The operator publishes public keys, by default as a JWK Set at /.well-known/http-message-signatures-directory. The client signs each request with RFC 9421 HTTP Message Signatures and sends three headers:

• Signature, the signature itself;
• Signature-Input, listing the covered components (at least @authority or @target-uri) and parameters including created, expires, a keyid equal to the key’s JWK thumbprint, and tag="web-bot-auth";
• Signature-Agent, the HTTPS URL where the site can fetch the operator’s keys.

The draft’s example request, with its line wrapping removed:

GET /path/to/resource HTTP/1.1
Host: origin.example.com
Signature: sig=abc==
Signature-Input: sig=("@authority" "signature-agent";key="sig");created=1700000000;expires=1700011111;keyid="ba3e64==";tag="web-bot-auth"
Signature-Agent: sig="https://signer.example.com"

The site fetches the keys, verifies the signature, and treats the resolved URL as the agent’s identifier. The draft is careful about what that proves: a key holder signed the covered message, which can still be replayed until the signature expires. It recommends expiry of no more than 24 hours. It says nothing about who operates the agent, whether it is benign, or whether the request is authorized; those are the site’s policy. The draft also places authenticating human users, authorization and delegation out of scope.

One implementation detail matters today. Cloudflare’s documentation says it implements Signature-Agent as a structured string from an earlier draft, such as "https://signature-agent.test", and fails verification for the dictionary form used in later drafts. Check which form your verifier expects.

Side by side

	CAPTCHA	Web Bot Auth
Purpose	Tell humans from bots and keep bots out of an action	Let automated clients prove which operator sent a request
Layer	Challenge or risk check embedded in a page, verified server-side	HTTP Message Signatures on each request
Who talks to whom	The site challenges the visitor’s browser; the site’s server checks the token with the vendor	The agent signs; the site verifies against the operator’s published keys
Transport	JavaScript widget, a token posted with the form, a vendor verification API	Signature, Signature-Input and Signature-Agent headers
Discovery	None; the site embeds the widget	Key directory at /.well-known/http-message-signatures-directory, located through Signature-Agent
Auth	Evidence of a human, or a score; no identity	Proof of key control by the operator; no end-user identity
State	Single-use tokens that expire in minutes	Signatures with created and expires; recommended expiry no more than 24 hours
Governance and status	Vendor services; no standard; W3C note on accessibility (2021)	IETF working group (chartered October 2025); Internet-Draft, September 2026

When to use each

Use a CAPTCHA where you expect only people and anonymous automation causes harm: account creation, password guessing, spam on open forms. Prefer non-interactive modes and alternatives the W3C note discusses, so people with disabilities are not locked out.

Use Web Bot Auth where you want to admit some automation on known terms: search crawlers, archivers, and AI agents fetching pages for users. Verify signatures, then allow, rate limit or block by operator, the way sites already handle IP ranges and user-agent strings, but with a cryptographic check.

Using both

Layer them. Verify signatures first and apply your policy to known operators. Send unsigned or unknown traffic through your existing bot defenses, including CAPTCHAs where a human is expected. Avoid putting a CAPTCHA in front of an operator you have already chosen to allow; it cannot solve it without defeating the purpose.

For work between a customer’s agent and a business, neither tool is the right front door. The Web Bot Auth charter targets websites built for people and lists HTTP APIs and agent-to-agent interfaces as out of scope. A business that wants agents to request refunds or bookings can publish an A2A endpoint, where authentication is declared in the Agent Card. See What is the A2A protocol?.

Common misconceptions

“A valid signature means the bot is safe.” It means the request came from whoever holds the operator’s key. Trust, reputation and permissions are your decisions.

“CAPTCHAs identify bots.” They estimate whether a visitor is human. A pass or a score carries no identity for the program or the person behind it.

“Web Bot Auth proves the agent acts for a real customer.” The draft excludes authenticating users, authorization and delegation. Proof that a person authorized an action needs something else, such as an OAuth grant or a signed mandate.

“An audio alternative makes a CAPTCHA accessible.” The W3C note reviews audio CAPTCHAs along with visual ones and finds barriers in both. It then examines non-interactive and multi-party approaches as alternatives.