>Agent Verifier:See Your Signed Request the Way a Server Sees It

Introduction

Web Bot Auth gives an automated client a way to say who it is and prove it: an Ed25519 key, a signature over the request, and a key directory published on the client's own domain.

Adopting it is uncomfortable for a reason that has nothing to do with cryptography. An operator generates a key, publishes a directory, signs outbound requests, and then has no way to find out whether any of it worked. A signature either verifies or it does not, and a server that refuses one has no obligation to explain which of a dozen things went wrong.

A broken signature does not announce itself either. It does not come back as an error, it simply does not count, and the client goes on being judged the way it was before: by the reputation of the address it rents and by how closely its handshake resembles a browser. That is the pile legitimate automation adopted a signature to climb out of, and from the operator's side everything still looks configured correctly.

packet.guru runs a tool for exactly that gap: the Agent Verifier, where an agent asks how its own request looks from the outside and gets back the fault by name and the line that fixes it. It is free, it needs no account, and it can be called as an ordinary HTTPS endpoint or connected as an MCP server, so an agent can run the check on itself. If the protocol is unfamiliar, how the web started checking an agent's ID covers the mechanics first.

Where It Usually Goes Wrong

A signed request has three moving parts, and each one fails in its own way.

• The signature: computed not over the request as sent, but over a short text that the sender and the receiver each build from the same rules, character for character. Almost every failure here is a difference in how that text was assembled rather than anything to do with keys: a name written without the quotes around it, an extra line break at the end, the whole of a header put in where only one part of it belonged. The expensive part is that a text assembled wrongly still verifies against its own key on the sender's own machine, so everything looks right from the side that built it.
• The key directory: the small file on the agent's own domain that lists its public keys. The verifier has to fetch it, and that fetch goes through whatever sits in front of the domain. A bot rule refusing an unfamiliar client, a file published on the apex while the header names the www host, a certificate that expired last week. None of it is visible from the agent's side, and all of it stops the key from ever being read.
• The agent card: the optional file where an agent states what it promises to send and who to contact. It is read only if the request points at it, so a card nobody was told about is a card nobody has seen.

Checking Your Own Setup in One Request

The check takes no arguments, because there is nothing useful to pass. The answer describes the very request that carried the call: the signature on it, the key directory that signature named, the agent card if one was pointed at, and plain facts about the address it arrived from. It works whether or not the request is signed, and an unsigned call still gets an answer about its address.

There are two ways in, running the same engine. An ordinary HTTPS request works. So does a call over the Model Context Protocol, where the check appears in an AI client's own tool list and can be invoked without anyone reading documentation first.

One thing has to be asked for. An agent card, where an agent states the User-Agent it promises to send and whom to contact, has no standard address, so a verifier has to be told where yours is: Signature-Agent: sig1="https://example.com/bot-card";type=cimd points at the card instead of at a key directory. Point at one and its promises are read back to you, compared against what actually arrived.

If the agent is an AI agent, which by now most of them are, none of this has to be done by hand. Every agent page here carries a prompt written to be pasted straight into it: one that generates the key and publishes the directory, one that connects the check as a tool the model can call, and one that needs nothing set up in advance. A capable model reads the page, does the setup and then runs the check on itself, which is usually faster and more accurate than a person following the same steps.

Reading the Answer

A failing call returns something like this:

{
  "signals": {
    "agent": {
      "signature": { "present": true, "outcome": "invalid" },
      "webBotAuthDetail": {
        "reason": "directory-bad-status",
        "directoryStatus": 403,
        "fix": "Your key directory answered with an HTTP status other than 200. A 403 or 429 almost always means a firewall or CDN in front of it is refusing this verifier rather than anything about your keys, and the usual fix is to exempt the well-known directory path itself from that rule…"
      }
    }
  }
}

Three fields, three jobs. The reason is the fault in machine-readable form, stable enough to branch on. The directoryStatus is what the operator's own origin actually answered. The fix is the sentence a person acts on, and there is one for every fault the check can report. The whole list of them lives on the response reference.

A successful call reports the identity that was proven, what the key directory proved about its own key set, and, if a card was pointed at, whether the User-Agent that arrived matches the one the card promised. That last comparison is the one claim a single live request can settle: a card is a statement of intent, and checking it against what actually arrived turns it into a fact. The rule runs both ways, so the verifier's own fetcher publishes its exact User-Agent on its own card.

FAQ

Q: My signature verifies on my own test rig but fails here. What is different?

Usually the text the signature was computed over. The answer names which part of it differs, and the numbers behind a fault come back as numbers rather than as categories, so there is something exact to compare your own build against.

Q: Does a valid signature mean an agent is trustworthy?

No. It means a specific key signed that request, inside a validity window. Trust is the receiving site's policy, and it always was.

Recommendations

For agent operators

Check the setup before assuming the problem is cryptographic. The fault turns out to be the directory fetch more often than the signature, and a refusal there is invisible from the agent's own side. Cover the authority and the Signature-Agent member keyed to your own label, keep the validity window short, and keep the clock in sync. A drifting clock is the most common avoidable failure there is.

For site operators

Treat a valid signature as an identifier, not as permission. It gives you a stable handle to log, rate limit or allowlist, and unlike a User-Agent string it cannot be borrowed by whoever fancies the name. What the client does after that still belongs to the transport and behavioural layers, because a signature narrows the question rather than answering it.

Check your own setup

One request, no account, no key. It reports whether the signature verified, what the key directory looks like from outside, the exact fault if there is one, and the line that fixes it.

• Agent Verifier — what it checks, and how to call it over HTTPS.
• Implementation guide — key, directory, signature, card, step by step, with the mistakes that cost the most time.
• MCP server — connect an AI agent and let it run the check itself.
• Response reference — every field in the answer and every fault, each with the sentence saying what to change.