Agent Verifier

whoami, for AI agents. How a request looks from the outside.

First, what this is about: Web Bot Auth

When an automated client asks a website for a page, the site has to decide whether to serve it. Today that decision rests on two things, and both are claims the client makes about itself: the User-Agent string, which anyone can copy, and lists of addresses that operators publish, which many operators never publish at all. So impostors get served and real crawlers get blocked.

Web Bot Auth replaces the claim with a proof. The client publishes a public key at a domain it controls and signs every request with the matching private key. The site checks that signature against the published key. That proves one thing, and proves it properly: the request came from whoever controls that domain.

The work is happening at the IETF, in a working group with editors from Cloudflare and Google and contributors from Amazon and Mozilla. The signing mechanism underneath is RFC 9421, a finished standard. Verifiers are already running: Cloudflare, AWS, Akamai and DataDome all read these signatures today.

And what this page is: a free way to check yours

Setting it up means getting a key, a published directory and a byte-for-byte signature base all right at once. Get one of them wrong and the site refuses the request without saying which one.

Send the request you already send everyone else. The answer says what the signature actually proved, what the key directory actually publishes, and which single thing to change, in the words of the standard.

No account. No key. No registration. Free.

A wrong signature is worse than no signature

A verifier that refuses a signature does not say why. It answers with a refusal and nothing else. From the client side, a malformed signature base and a site that has never heard of you look exactly the same, so debugging turns into changing one thing at a time and guessing.

This check names the fault instead. Same request, same headers, one sentence saying what to change.

One request, one answer

No body, no parameters. Everything in the answer is read from the request itself.

curl https://fp.packet.guru/api/v1/connection \
  -H 'Signature-Agent: sig1="https://your-agent.example"' \
  -H 'Signature-Input: sig1=("@authority" "signature-agent";key="sig1");created=…;expires=…;keyid="…";tag="web-bot-auth"' \
  -H 'Signature: sig1=:…:'

An answer, abbreviated:

{
  "success": true,
  "signals": {
    "agent": {
      "signature": { "present": true, "outcome": "invalid" },
      "webBotAuthDetail": {
        "reason": "key-not-in-directory",
        "fix": "No key with this keyid is in your directory. Make sure
                keyid matches either the key thumbprint or its kid."
      },
      "keyDirectoryBinding": "binding-key-proven"
    }
  },
  "ip": { "org": "…", "origin": "datacenter" }
}

Most callers still arrive unsigned

Signing is new, and few operators have adopted it. Most automated clients still identify themselves by the address ranges their operator publishes, or by nothing at all. So the answer reads two independent things, and both come back whether the request was signed or not.

If you sign

The signature

RFC 9421 with the Web Bot Auth profile. The key directory named in the request gets fetched, the signing key is checked against it, and so is what that directory proves about its own key set. An agent card is the file saying who you are and what you promise to send. Point at it with type=cimd and it is read back to you, with the User-Agent it promises compared against the one that arrived.

Everyone, always

The address

Whether it sits inside a crawler range its operator publishes, what kind of network it belongs to, and its standing on public abuse lists. Taken from the address that opened the connection, never from a header.

Where to call

The API answers on fp.packet.guru. Send the request there, and do not route it through a proxy: the answer describes the request exactly as it arrives, so anything that re-sends it on your behalf changes what the answer is about.

Prompt: ask an agent to check this machine

Paste this into any agent that can make an HTTP request. Nothing has to be set up first, and it works whether or not the agent signs. An agent that does not sign still gets an answer about the address it called from, which is the half that is read for everyone.

Find out how this machine looks to the websites it visits, using the free check at
https://fp.packet.guru/api/v1/connection

Make one GET request to that address from this machine, directly. Do not use a proxy
and do not route it through any service that re-sends the request on your behalf,
because the answer describes the request exactly as it arrives.

Then tell me:

1. Did the request carry a Web Bot Auth signature at all? If it did and it failed,
   quote the fault and the fix sentence from the answer.
2. What kind of network is this address on, and who operates it?
3. Is this address inside any crawler range its operator publishes?
4. If the request carried no signature, say so and stop there: the answer describes an
   anonymous caller and prescribes nothing. If it carried one, list in order what the
   answer says has to change.

Answer only from what the response says. Do not guess and do not fill gaps from memory.

The standards behind this

RFC 9421 HTTP Message Signatures. The mechanism everything here is built on.
RFC 7638 JWK Thumbprint. How a key identifier is derived from the key itself.
RFC 9651 Structured Field Values. The grammar the Signature-Agent header follows.

For machines

API catalog Every API here, each with its description and its documentation. Standard address, RFC 9727.
openapi.json The response contract, machine-readable. The same source the reference page is built from.
MCP server card What an MCP registry reads about this server: address, transport, and the tool it exposes.
packet.guru key directory The public keys this site signs its own outbound requests with. A working example of the file you publish.
packet.guru agent card What the fetcher on this site promises about itself, including the exact User-Agent it sends.