How an agent identifies itself

If you received a 403 with "error": "identify_required", the store you were browsing allows automated agents but asks them to say who they are before certain actions, usually checkout. Nothing is broken; the store's policy asked for an identity it could not see.

The response is machine-readable:

{
  "error": "identify_required",
  "message": "…the store's own wording…",
  "how": {
    "user_agent": "Send a user agent that names your agent (see the Tactical agent registry).",
    "verified_ip": "Publish the IP ranges your agent uses and register them with the operator.",
    "signed_request": "Sign requests with Web Bot Auth from a key directory listed in the Tactical agent registry.",
    "docs": "https://tactical-app.work/docs/gate/identify"
  }
}

Three ways to be recognised

1. A user agent that names you

Send a User-Agent that carries a stable token for your agent, for example MyShopper/1.0 (+https://example.com/agent). Stores running Tactical recognise the agents in the public agent registry; an agent not yet listed is treated as unidentified. To be added, publish a page describing the agent and its user-agent token and contact [email protected]. A user agent identifies you but doesn't verify you: anyone can send it, so a named agent is at the likely tier.

2. Signed requests (verified)

Sign your requests with Web Bot Auth (HTTP Message Signatures, RFC 9421). This is the only way to reach the verified tier, the highest, which is what most policies mean by "allowed" (Declared and verified agents are welcome).

• Publish your Ed25519 public keys as a JWKS at https://<your-origin>/.well-known/http-message-signatures-directory, served with a 200 and no redirect. Tactical matches the signature's keyid to a key's kid, or else to the key's RFC 7638 thumbprint.
• Send Signature-Agent naming that origin (sig1="https://your-origin.example"; the older bare string "https://your-origin.example" is accepted too), plus Signature-Input and Signature.
• The signature must carry tag="web-bot-auth", created, expires (at most 24 hours after created) and keyid, and cover @authority (or @target-uri) and the Signature-Agent entry. Covering @method and @path as well is better practice: a signature over the authority alone can be reused on any page of that store until it expires.
• Ask for your origin to be added to your agent's registry entry ([email protected], with a link to where you document it). Stores only fetch directories for signers in the registry; until yours is listed, a valid signature leaves you identified by your user agent, not verified.

Verified today: ChatGPT agent (https://chatgpt.com) and Google-Agent (https://agent.bot.goog, on some requests). Cloudflare Browser Run signs too, but isn't treated as verified, because anyone can drive it. An invalid signature (expired, tampered, or made for a different site) never counts as verified; the request is treated as if it were unsigned.

3. Published IP ranges

Publish the IP ranges your agent sends from (a JSON document of CIDR prefixes, the way OpenAI does for GPTBot) and register its URL in the registry entry. Tactical checks crawler visits against them in the store's reports; the Gate doesn't use them to verify an agent. A signature does that.

What identification does not do

It does not bypass the store's policy. A store can still throttle, challenge or block an identified agent. It removes the unidentified condition, which is the one most policies restrict first.

For store owners

You never have to accept an agent because it identified itself. The policy on your Gate page decides what identified agents may do; the policy reference has the details.