AgenID, Visa Trusted Agent Protocol and Web Bot Auth: identity records and signed requests

What the Trusted Agent Protocol and Web Bot Auth are

Visa's Trusted Agent Protocol overview describes agents generating signatures that are specific to the merchant and purpose, time bound, and unable to be replayed or relayed, so merchants can verify agents and connect a browsing or payment action to a customer's existing merchant account. Visa's page states that the product is in the process of development and deployment. The specification page says the protocol is based on HTTP Message Signatures defined by RFC 9421 and aligned with Web Bot Auth. Its Signature-Input carries created, expires, keyid, alg, nonce and tag, with tag values agent-browser-auth for browsing and agent-payer-auth for payment. Examples include Ed25519, and public keys are retrieved as a JWKS. The specification describes the agent as a certified AI platform onboarded by a payment scheme, acting on behalf of its account holders.

Visa's GitHub repository describes itself as a sample implementation, and its license file refers to the Visa Developer Center Terms of Use.

Web Bot Auth is the underlying pattern. Cloudflare's documentation describes it as an authentication method that uses cryptographic signatures in HTTP messages to verify that a request comes from an automated bot. A bot hosts a key directory at /.well-known/http-message-signatures-directory, sends a Signature-Agent header pointing to it, uses the tag web-bot-auth, and Cloudflare supports Ed25519 keys. The IETF webbotauth working group is active, and draft-ietf-webbotauth-httpsig-protocol is its working-group Internet-Draft. RFC 9421, HTTP Message Signatures, is a Standards Track RFC and includes EdDSA using Curve edwards25519.

What AgenID is

AgenID is an open protocol, specified in the MIT-licensed AgenID specification, that gives an AI agent a permanent identifier, agenid:<ULID>. The operator generates an Ed25519 key pair locally or in the browser at /issue and signs a proof binding a manifest that declares identity, ownership, purpose and disclosure. The registry at www.agenid.com serves it at https://www.agenid.com/a/<agenid> as a Verification Card or a JSON resolution envelope that anyone can re-verify offline.

Key differences

The signed object differs. Web Bot Auth and the Trusted Agent Protocol sign HTTP request components, with creation and expiry times and a nonce, so the signature is about one request. AgenID signs a proof over a manifest digest, so the signature is about an agent's declared identity, and it stays valid across requests. AgenID v1.1.1 does not bind a live HTTP request to a registered agent at all.

The unit of identity differs. In the Trusted Agent Protocol specification, the agent is a certified AI platform onboarded by a payment scheme. In Web Bot Auth, the signer is the automated client whose key directory the Signature-Agent header names. In AgenID, the subject is an individual logical agent with an accountable operator.

The key discovery differs. Web Bot Auth publishes keys in a JWKS directory at a well-known path on the signer's domain. AgenID publishes the operator key in the registry at GET https://www.agenid.com/v1/keys/<key-ulid> and expects the operator to publish a copy at /.well-known/agenid/keys.json on its own domain, so a verifier can compare the two (two-path key discovery).

Identity is not permission

A valid request signature shows who sent a request; a valid AgenID record shows which agent an operator declared. Neither, on its own, says what the agent is allowed to do. AgenID v1.1.1 defines no authorization object, so permission decisions stay with the merchant or service.

Where they are complementary

Request signing and identity records sit at different layers, so they can be used together. A merchant could verify a signed request under Web Bot Auth or the Trusted Agent Protocol and separately resolve the agent's AgenID identifier to see its operator and declared purpose. Neither specification currently defines a field that carries or references the other, so linking them would be an implementation choice by the parties involved, not a feature of either protocol.

When to use which

These are fit questions, not quality judgments.

• Consider Web Bot Auth when a server needs to check, per request, that automated traffic comes from the holder of a published key.
• Consider the Trusted Agent Protocol when you are a merchant or agent platform working within Visa's agentic commerce program.
• Consider AgenID when a counterparty needs a permanent, operator-signed identity for a specific agent that it can re-verify offline, across channels that include voice, SMS and email as well as HTTP.

AgenID's current limits

AgenID's boundaries, stated as plainly as its design:

• Issuance ceiling: the reference deployment at agenid.com issues nothing above L1_REGISTERED today. The specification defines L2_DOMAIN_VERIFIED, L3_ORGANIZATION_VERIFIED and L4_DEPLOYMENT_VERIFIED, but each requires a VerificationAssertion signed by a root authority key, and that key has not been created yet. L1_REGISTERED is a self-declaration: it means an operator-signed manifest is in the registry, not that anyone checked the operator. L5 is reserved and not issuable.
• No revocation flow is deployed. Agent status values such as SUSPENDED and REVOKED exist in the schema so the envelope shape is stable, but nothing in production writes them, so every registered agent reads ACTIVE. The specification keeps retired and revoked keys resolvable permanently so that historical signatures remain checkable.
• No authorization object exists in v1.1.1. The DECLARED, VERIFIED and AUTHORIZED claim states are never inferred from one another, AUTHORIZED has no signed object, and permissions and authorizations are reserved manifest keys that a v1.1.1 validator rejects. A v1.2 authorization layer is a draft in development, not something available.
• Two-path key discovery depends on the operator. The registry serves the operator key at GET https://www.agenid.com/v1/keys/<key-ulid>, and the operator is expected to publish its own copy at https://<operator_domain>/.well-known/agenid/keys.json. If the operator publishes no copy, a verifier has one source, not two.