Google signs some AI agent requests so sites can spot fakes

Google published developer documentation on 2026-05-04 for Web Bot Auth, an experimental protocol that lets its AI agents cryptographically sign their HTTP requests. SE Roundtable reported the new page the next day. According to Google’s Web Bot Auth documentation, a subset of requests from Google-Agent, the user agent Google’s AI agents send, now carry a signature that identifies them as https://agent.bot.goog.

Why a signature is harder to fake

Bot verification today rests on two checks. The user-agent string says who the bot claims to be, and anyone can copy it. The IP address and its reverse DNS lookup say where the request came from, which is harder to fake but ties identity to Google’s network ranges. Plenty of scrapers already pass the first check by pretending to be a known bot, the same problem covered in the earlier article on AI crawlers that fake their identity.

A signature closes that gap. Google’s agent signs each participating request with a private key, and your server checks the signature against the public keys Google publishes at agent.bot.goog. A scraper can copy the Google-Agent string, but it cannot produce a valid signature without Google’s key. The signing format follows the Internet Engineering Task Force (IETF) HTTP Message Signatures standard (RFC 9421), and Google’s documentation says the approach separates an agent’s identity from its IP addresses.

Google still says to keep the old checks

Google calls its implementation experimental, and its documentation spells out what that means in practice. Web Bot Auth is still a draft from an IETF working group and may change. Not all Google user agents use it. Google is not yet signing every request from the agents that do. Google recommends that sites keep relying on IP addresses, reverse DNS and user-agent strings alongside the new protocol.

A valid signature proves a request came from Google, but a missing signature proves nothing. Real Google traffic can arrive unsigned, either from a user agent that does not take part or from a request Google simply did not sign.

The change also applies to one kind of bot only. Google’s documentation describes the test as covering “some AI agents hosted on Google infrastructure.” It does not mention Googlebot, so verification of the search crawler stays as it was.

What to do

1. Ask your CDN, web application firewall (WAF) or bot-detection provider first. Google says major bot-detection services, CDNs and WAFs support Web Bot Auth, and that a provider which supports it likely verifies Google-Agent signatures automatically. For most sites, that is the whole job.
2. Allow a valid signature, but do not block an unsigned request. Route unsigned Google-Agent requests through your existing IP and reverse DNS check.
3. If you verify requests yourself, fetch Google’s public keys and cache them for as long as the Cache-Control header allows. Signed requests carry a Signature-Agent header with the g label, and Google says to verify the Signature and Signature-Input headers carrying that same label.

# Google's public key set (cache per its Cache-Control header)
https://agent.bot.goog/.well-known/http-message-signatures-directory

# Header on signed Google-Agent requests
Signature-Agent: g="https://agent.bot.goog"

4. Skip the latency cost where it matters. Google says a server can send its response first and validate the signature afterwards, within the signature’s expiry window. A request that fails the check then gets blocked on its future requests instead of the current one.

Nothing here is urgent. A site that does nothing keeps verifying Google traffic the way it always has, and loses nothing while the protocol stays experimental.