ERC-8004: Trustless Agents
Relevance: NoneNot one of the main personas on the ERC-8004: Trustless Agents page. The responsibility table gives this persona no step.
Persona
CDN or bot-management engineer
Verifies signatures at the edge and separates good agents from bad bots.
Role
Goals
- Verify RFC 9421 signatures at the edge in a few milliseconds and pass a trusted-agent verdict to the origin.
- Fetch and cache keys from multiple directories (Visa, Mastercard, Web Bot Auth, UCP JWK sets) with sane rotation.
- Enforce time windows and nonce uniqueness at scale across many points of presence.
- Keep scrapers and credential-stuffing bots out while letting verified shopping agents through.
- Give merchants a simple policy knob: block, allow verified, allow all, with per-path rules.
- Report agent traffic separately from human and bot traffic.
Pains
- TAP, Web Bot Auth, UCP and Mastercard use the same signature mechanism with different tags, keyid formats and directory locations.
- The minimum covered components in TAP omit @method, @query and a content digest, so a verified request can still be tampered with.
- Nonce tracking is optional in some specs, and global nonce state across edges is expensive.
- Key directories are controlled by single vendors, and an outage or key rotation breaks verification for everyone.
- A verified agent is not a safe agent. Signatures prove who sent a request, not whether it will abuse the catalog or checkout.
- Sample code in vendor repositories deviates from RFC 9421, and merchants copy it.
Decisions they own
- Which directories to trust and how to handle unknown keyids.
- Whether to require a content digest and more covered components than the spec minimum.
- Nonce storage strategy and replay window.
- How to label and route agent traffic (Direct versus Intermediary, browse versus pay).
Vocabulary
- RFC 9421
- Signature-Input
- Signature
- Signature-Agent
- keyid
- nonce
- created
- expires
- tag
- signature base
- JWKS
- Web Bot Auth
- verified bot
- Content-Digest
Each protocol from this seat
Relevance levels: High, a main persona on the protocol page; Medium, owns, implements or verifies a step; Low, relies on or observes a step; None, no role found in the protocol page.
x402
Relevance: NoneNot one of the main personas on the x402 page. The responsibility table gives this persona no step.
Visa Trusted Agent Protocol
Relevance: HighRuns the Site Protection Provider in front of merchant sites and verifies TAP signatures at the edge on the merchant's behalf. Source [1, 2, 3, 4]
Goals
- Let approved shopping agents through without opening the door to bots
- Verify signatures fast enough to sit on every request
- Give merchants one rule that covers Visa and Mastercard agents
Pains
- Two networks with two directories and different tags
- A key store whose single RSA key does not match the Ed25519 examples
- Nonce records that must be shared across edge locations
Implements
- The header checks: tag, minimum fields, window, nonce, key, signature
- Key caching by keyid with refresh from the Visa JWKS
- Logging of verification outcomes for the zone owner
Must trust
- Visa's onboarding of agents and its key store
- Checkout Enablers to pass headers through unchanged
- Its own RFC 9421 implementation to match the agents' serialization
Questions they ask
- Where do production agent keys come from, if not the published JWKS?
- Must I keep nonces, given that TAP makes it optional?
- How do I treat a request that carries both a TAP and a Web Bot Auth signature?
First three steps
- Read the TAP specification's verification steps and Cloudflare's 2025-10-24 post
- Fetch https://mcp.visa.com/.well-known/jwks and inspect what it holds
- Build a verifier that blocks windows over 8 minutes and repeated nonces
Metrics they care about
- Share of agent traffic with a valid TAP signature
- Verification latency at the edge
- Blocks by reason (tag, window, nonce, key, signature)
A day in the life. Ana runs bot management for a CDN. A retail customer wants shopping agents in and scrapers out. She turns on TAP verification: the edge reads Signature-Input, checks the tag, the 8-minute window and the nonce, fetches the key for keyid and verifies the signature. On day one the dashboard shows a spike of requests tagged web-bot-auth from an agent that copied Cloudflare's example, and she routes them to the normal bot policy. She also notices the Visa key store holds one RSA key, so she asks Visa how production keys reach her edge. Until she gets an answer, she keeps the rule in log-only mode.
Steps in the responsibility table
- Relies onOnboard the agent and register its key
- Relies onHost the key store (JWKS)
- VerifiesSign each request with a TAP tag
- OwnsVerify header signature, window and nonce
- ObservesVerify body objects and process payment data
Agentic Commerce Protocol (ACP)
Relevance: NoneNot one of the main personas on the Agentic Commerce Protocol (ACP) page. The responsibility table gives this persona no step.
UCP
Relevance: NoneNot one of the main personas on the UCP page. The responsibility table gives this persona no step.
Stripe MPP (Machine Payments Protocol)
Relevance: NoneNot one of the main personas on the Stripe MPP (Machine Payments Protocol) page. The responsibility table gives this persona no step.
AP2
Relevance: NoneNot one of the main personas on the AP2 page. The responsibility table gives this persona no step.
Mastercard Agent Pay
Relevance: NoneNot one of the main personas on the Mastercard Agent Pay page. The responsibility table gives this persona no step.