Google is signing some agent requests. That is identity, not a citation.

Agents are knocking. Google wants you to be able to tell which knocks are real.

That is not a blogger take. Google's own Crawling Infrastructure guide says it is testing the Web Bot Auth IETF internet draft with some AI agents hosted on Google infrastructure, and that a subset of Google-Agent requests are signed and authenticated as https://agent.bot.goog. On September 1, 2026, the IETF webbotauth working group published Active Internet-Draft draft-ietf-webbotauth-httpsig-protocol-00 — HTTP Message Signatures for automated traffic — with Google's Sandor Major as a co-author alongside Cloudflare's Thibault Meunier.

Sources: Authenticate requests with Web Bot Auth (experimental), Google Crawling Infrastructure (last updated 2026-05-04 UTC, opened this fire); draft-ietf-webbotauth-httpsig-protocol-00, IETF (Active Internet-Draft, dated 2026-09-01, opened this fire); webbotauth WG, IETF; AI features and your website, Google Search Central; Optimizing your website for generative AI features on Google Search, Google Search Central; key directory GET body from https://agent.bot.goog/.well-known/http-message-signatures-directory (opened this fire).

The short version

• Google is testing Web Bot Auth so sites can cryptographically validate that a bot is who it claims to be — not just a spoofable User-Agent or IP list.
• Experimental, on purpose: not every Google user agent uses it; Google is not signing every request even for agents that participate; keep IP / reverse DNS / UA fallbacks.
• Participating signed Google-Agent traffic authenticates as https://agent.bot.goog. Public keys are published at that origin's well-known HTTP Message Signatures directory.
• IETF webbotauth WG draft-00 (Sep 1, 2026): agents sign outbound HTTP requests; origins verify. Signature-Agent carries discovery. Tag must be web-bot-auth. Identity is the resolved URL + key — not a trust score and not authorization.
• Google Search still says eligibility for AI Overviews / AI Mode supporting links is indexed + snippet-eligible. No special AI file. Web Bot Auth is not listed as a ranking or citation requirement.
• Operator split: identity/access (allowlist the agent so it can read you) versus visibility (have first-party proof pages so models have something true to cite). Confusing the two is how teams burn a month on WAF rules and still look empty in AI answers.
• Monitoring ≠ execution. GSC generative AI reports will not stamp "this impression was a Web Bot Auth–signed fetch."

What Google actually said

From Google's experimental guide:

Google is testing usage of the Web Bot Auth IETF internet draft, which is a new cryptographic protocol that helps websites to validate that bots are authentic. We are testing the protocol with some AI agents hosted on Google infrastructure.

And the line that matters for operators who want a single silver bullet:

We don't sign every request of a particular agent. Be sure that you fall back to the established methods of bot verification.

Google names the benefits it wants: cryptographic certainty beyond spoofable headers, better observability of how agents interact with your content, and a path toward mutual trust between agent providers and websites. Those are access and attribution benefits. The page does not say signed traffic ranks higher, gets more AI Overview citations, or replaces Search quality systems.

On allowlisting:

A subset of requests made by the Google-Agent are signed with Web Bot Auth; in these cases, they are authenticated as https://agent.bot.goog.

Verification path Google documents: fetch the public key set from https://agent.bot.goog/.well-known/http-message-signatures-directory, look for Signature-Agent with g="https://agent.bot.goog", verify Signature / Signature-Input under label g per RFC 9421, and still fall back to IP-based checks because not all requests are signed.

We opened that directory this fire. A bare HEAD returned 404; a GET with an Accept header for the directory media type returned a JWKS body with multiple Ed25519 verify keys. Treat the directory as live key material Google told you to fetch — and note the HEAD/GET mismatch if you are wiring health checks. Do not invent a key count into a ranking claim.

https://agent.bot.goog/ itself returns a short HTML page titled Google-Agent: agents hosted on Google infrastructure navigate the web and perform actions upon user request, with a link back to the same Web Bot Auth guide.

What the IETF draft actually defines

draft-ietf-webbotauth-httpsig-protocol-00 is an Active Internet-Draft in the webbotauth working group. Document type: working document. Expires 5 March 2027. It is not an RFC. Google's Sandor Major is a listed author.

Abstract, opened this fire:

This document describes a protocol for identifying automated traffic using HTTP Message Signatures. The goal is to allow automated HTTP clients to cryptographically sign outbound requests, allowing HTTP servers to verify their identity with confidence.

The trust model is blunt on purpose. A valid signature over a resolved Signature-Agent URL proves a holder of a key that URL publishes signed the covered message. It does not prove the operator is honest, that the agent is benign, or that the request is authorized. Those are origin policy. The draft also puts human authentication, anonymous auth, and authorization/delegation out of scope.

Required signature flavor for this profile includes tag = web-bot-auth, plus created, expires, and a keyid thumbprint. Agents must cover at least @authority or @target-uri, and must send Signature-Agent. Recommended expiry is no more than 24 hours. Covering only @authority can be replayed against that authority for other methods/paths until expiry — the draft says that out loud.

WG charter (opened): products are for sites that primarily serve human users; in-scope uses include authenticating crawlers and similar automated clients. Out of scope includes authenticating end users, and authenticating access to content not intended for humans (HTTP APIs / agent-to-agent interfaces).

So: this is bot identity for human-facing web pages. It is not a new schema for AI Overviews.

What this is not

Google Search Central's AI features guide (opened this fire) still frames supporting-link eligibility the same way:

To be eligible to be shown as a supporting link in AI Overviews or AI Mode, a page must be indexed and eligible to be shown in Google Search with a snippet, fulfilling the Search technical requirements. There are no additional technical requirements.

And:

You don't need to create new machine readable files, AI text files, or markup to appear in these features.

The generative AI optimization guide (opened this fire) repeats the SEO-is-still-the-foundation line, mythbusts llms.txt as a Google Search ranking lever, and points measurement at Search Console's Generative AI performance report. It mentions Merchant Center and Business Profile freshness for product/local detail in AI responses. It does not list Web Bot Auth as a visibility requirement.

Separate New Reward Field Guide already covers ChatGPT site tools / WebMCP — tools a page registers so ChatGPT can call them. That is also not a citation. Do not mash WebMCP, Web Bot Auth, and AI Overview supporting links into one "agent SEO" blob.

The operator split that actually ships

Job	What you do	What it buys
Identity / access	Ask your CDN/WAF if it verifies Web Bot Auth; allowlist Google-Agent / agent.bot.goog carefully; keep IP+UA fallbacks	Agents that are supposed to see you are less likely to get blocked as scrapers
Proof / visibility	Indexed pages, snippet-eligible, first-party facts in crawlable text (prices, hours, people, booking, product attributes)	Something true for models to ground and for Search to cite
Measurement	GSC Performance + Generative AI report when present; your own citation checks	Visibility signals — not "signed fetch" stamps

If your WAF treats every agent like abuse, you can "win" security and lose the fetch that would have read the page you wanted cited. If you open the gate and your service pages are still commodity blur, you get visits from bots and still no useful answer about you.

New Reward's lane is the proof loop: make the business inspectable, then measure whether AI surfaces can see it. Cryptographic bot identity is infrastructure hygiene for the fetch path — not a substitute for the pages.

Honesty block

• Google did not confirm that Web Bot Auth improves rankings, AI Overview placement, AI Mode citations, or Discover.
• Google did not confirm every Google-Agent request is signed — the opposite: subset only; fall back required.
• The IETF document is an Active Internet-Draft (work in progress), not a finished RFC. Wire formats and discovery details can change.
• Google's Web Bot Auth developer page last-updated stamp opened this fire was 2026-05-04 UTC. The WG draft-00 date is 2026-09-01. Do not pretend Google published a Search Central ranking blog today.
• We did not open every CDN vendor's allowlist UI this fire. "Major CDNs/WAFs support it" is Google's claim on that page — verify with your provider.
• agent.bot.goog key directory: GET returned JWKS; HEAD returned 404 from this box. Do not build a monitor that only HEADs.
• OpenAI/ChatGPT citation behavior is out of scope for this Google-agent signing story. Do not invent a cross-engine claim.
• Sep 9 Merchant Center AI Search intent/terms/attributes and PAA-as-AI-Overviews are separate packs / stories — not this slug.

What to do this week

1. Ask hosting/security whether Web Bot Auth verification is on, and how they label Google-Agent / agent.bot.goog.
2. Do not flip from "block all bots" to "trust every signature." Google and the draft both say identity ≠ authorization.
3. Keep the pages agents would need: services, proof, FAQs, product/local facts in text — indexed and snippet-eligible.
4. Measure with Search Console (including generative AI reporting when you have it). Do not expect a "Web Bot Auth" dimension.
5. If you maintain llms.txt for other systems, fine — Google Search says it ignores it for ranking/visibility. Different lever.

Monitoring will not stamp the signature. Execution is the allowlist decision plus the proof pages.