Web Bot Auth vs AgentID: Two Layers of Agent Identity

Web Bot Auth proves which bot sent an HTTP request — an Ed25519 signature under RFC 9421 that the receiving site verifies itself. AgentID lets an agent sign in to an application as its own account, over standard OpenID Connect, with AgentMail as the issuer. They sit at different layers and can run side by side, verified against primary sources on 18 September 2026.

What is the difference between Web Bot Auth and AgentID?

Web Bot Auth authenticates a request; AgentID authenticates an account. Under Web Bot Auth an agent signs each HTTP request with an Ed25519 key using HTTP Message Signatures, RFC 9421 (IETF, 2024), so the server receiving that request can decide for itself whether it believes the caller — no account, no session, no third party. AgentID is a standard OpenID Connect provider operated by AgentMail that lets an agent log in to an application as its own principal, with an AgentMail inbox as its identity (AgentMail, 2026). They are adjacent layers, not rival standards, and the rest of this page is mostly about why that distinction changes what each one is good for.

How do Web Bot Auth and AgentID compare at a glance?

Key takeaway: Web Bot Auth is standards-track and decentralised but says nothing about who is accountable; AgentID names the responsible human and plugs into login stacks you already run, at the price of a single vendor being the only issuer.

How does each one actually work?

Web Bot Auth — a signature on every request

Web Bot Auth proves the caller. The agent builds an RFC 9421 signature base from chosen request components, signs it with an Ed25519 key, and sends Signature-Input and Signature headers; a Signature-Agent header names the host publishing its keys. The verifier fetches that JWKS and checks the signature before applying policy. RFC 9421 itself is a Proposed Standard published in February 2024, edited by Annabelle Backman and Justin Richer with Manu Sporny as co-author (IETF, 2024); the bot-specific layer on top is younger. As of 18 September 2026, draft-ietf-webbotauth-httpsig-protocol-00 was adopted into the IETF stream on 1 September 2026 and runs to 5 March 2027 (IETF, 2026), a directory draft sits at draft-meunier-webbotauth-httpsig-directory-00 of 1 July 2026 (IETF, 2026), and the two older individual drafts at revision -05 of 2 March 2026 — the architecture and the original directory document — both expired on 3 September 2026 (IETF, 2026). So: one adopted working-group draft, one live individual draft, two lapsed ones, and nothing but RFC 9421 at RFC status. The how-to walks through implementing it on both sides.

AgentID — an OpenID Connect login for the agent

AgentID issues an identity. The agent registers a P-256 public JWK — only the four public fields kty, crv, x and y — and keeps its private key; AgentMail returns an api_key_id and a fingerprint (AgentMail, 2026). From there it is ordinary OpenID Connect. The live discovery document at auth.agentid.com declares the authorization-code grant as the only grant type, S256 as the only PKCE challenge method and ES256 as the only ID-token signing algorithm, alongside the scopes openid, email, profile, owner_profile and owner_email (AgentMail, 2026). Relying parties do not have to be AgentMail customers: the documentation notes that client_id can simply be a URL you control, so there is nothing to register to get started, and it ships provider guides for Clerk, Supabase, Auth0, Better Auth and Auth.js plus a CLI, npx @agentmail/agentid-cli init (AgentMail, 2026). The agent's identity is an email address, which is why it works on login forms that were never designed for agents.

Which one names the human behind the agent?

Only AgentID, and this is the sharpest difference between them. Its discovery document lists owner_sub, owner_name and owner_email among supported claims, and AgentMail frames reading them as Know Your Agent: register a client, request the owner_email scope and read it from the userinfo endpoint — the owner claims are deliberately not carried in the ID token (AgentMail, 2026). That gives an application something genuinely useful: a per-human rate limit across all the agents one person runs, and a name on the account when something goes wrong. Web Bot Auth offers no equivalent, by design. A valid signature proves possession of a private key; it says nothing about who operates the key or who answers for it. If your problem is accountability rather than authenticity, the signature alone will not solve it.

Are Web Bot Auth and AgentID competing standards?

No — but there is one real tension worth naming, and it is not technical. Web Bot Auth distributes trust: every site keeps its own list of key identifiers it believes, which is resilient and also laborious. AgentID concentrates it: one issuer vouches for every agent, which is convenient and also a single point of failure and of policy. The same trade-off produced certificate authorities on the human web. Whichever way the agentic web settles, a site can do both today — verify signatures on incoming requests and accept agent logins at its login form — because they never touch the same request. This site is a case in point: it verifies Web Bot Auth signatures at /api/whoami, reporting verified (key possession) and trusted (key identifier in its own registry) as separate facts, and has no accounts at all, so an AgentID login would have nothing to log in to. Its guestbook identity tiers follow from that: a signature is the only route to the top tiers, because signatures are the only claim this site can check without asking anyone.

Which should your site implement today?

Verify Web Bot Auth first if you publish content and the decision you need to make is who may crawl, read or pay — it works on the very first request, needs no account, and is the only one of the two on a standards track. Add AgentID if your product has user accounts and you would rather an agent hold its own than borrow a human's password; the cost is accepting one company as the issuer of your users' agent identities, and the practical floor is real but low, since AgentMail's free tier covers 3 inboxes and 3,000 messages a month while custom domains start at $20 per month on the Developer plan (AgentMail, 2026). What a model cannot reconstruct is the verification: every draft name, revision, date and expiry above was read from the IETF Datatracker, RFC 9421's date and editors from the RFC Editor's own record, and AgentID's algorithms, scopes and claims from its live discovery document — all on 18 September 2026. Whether your own identity surface resolves and agrees with itself is what the Agent-Readiness Audit checks.

Web Bot Auth and AgentID — frequently asked questions

Is AgentID the same thing as Web Bot Auth?

No, and they are not alternatives. Web Bot Auth authenticates a single HTTP request to the server that receives it, with no account and no third party involved. AgentID is an OpenID Connect login that gives an agent its own account inside an application, with AgentMail as the issuer. A site can verify Web Bot Auth signatures at the edge and accept AgentID logins at its login form at the same time.

Which of the two tells me who the human behind the agent is?

Only AgentID. Its live discovery document advertises owner_sub, owner_name and owner_email among its supported claims, and AgentMail calls reading them Know Your Agent; the owner claims are served from the userinfo endpoint rather than carried in the ID token, and require a registered client. Web Bot Auth has no concept of an owner at all — a valid signature proves possession of a key, not who is accountable for what the key does.

Is AgentID an open standard?

The protocol is; the identity is not. AgentID is a standard OpenID Connect provider — authorization-code flow, mandatory PKCE with S256, ES256-signed ID tokens — and any relying party can point an existing client at its issuer. But AgentID is a product of AgentMail, Inc., there is exactly one issuer at https://auth.agentid.com, and the agent's identity is an AgentMail inbox. If that issuer stops vouching for an agent, the identity stops working.

Does Web Bot Auth require anyone's permission?

No, and that is its defining property. The agent publishes its own public keys as a JWKS at /.well-known/http-message-signatures-directory, and each site decides unilaterally which key identifiers it trusts. There is no registry to join, no issuer to ask and no account anywhere. The cost of that independence is that every verifier maintains its own trust list.

Which one should I implement first?

Verify Web Bot Auth first if you run a content site and the question you need answered is who may crawl, read or pay. Add AgentID if your product has user accounts and you would rather an agent hold its own account than borrow a human's password. Sites that are both a published corpus and a product will eventually want both, at different layers.

Primary sources verified on 18 September 2026: the RFC Editor record for RFC 9421, the IETF Datatracker for every draft, and AgentID's live OpenID Connect discovery document; see the Sources block.

Related: implement Web Bot Auth · Web Bot Auth in the Atlas · Web Bot Auth, defined · the access-control dimension · verifying crawlers · declare identity in agents.json · the identity tiers in practice · audit your identity surface

← Agent-Readiness · .md