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
Fraud and risk analyst
Signals, scores, chargebacks, agent abuse patterns.
Role
Goals
- Tell agent-initiated transactions apart from human and bot traffic in the data the model sees.
- Build features from agent identity, mandate constraints and payment tokens that predict disputes.
- Catch new abuse patterns: agent farms, prompt-injected purchases, mandate stretching, replayed credentials.
- Keep approval rates high for legitimate agents while dispute rates stay flat.
- Feed risk signals back into the protocol fields that carry them (ACP risk signals, AP2 risk_data, Agent Score).
Pains
- Agent indicators are missing or unreliable in authorization data, and the networks are testing probability scores instead.
- Agents that fill card forms with token-shaped values look like card testing in rules built for humans.
- Velocity rules break: one agent legitimately makes hundreds of small payments per minute on x402 or MPP.
- Sybil reputations on ERC-8004 and farmed x402 volume make external trust signals noisy.
- No agent-specific dispute reason codes exist, so chargeback labels do not tell the analyst what went wrong.
- A compromised agent can run within its mandate and still cause harm, so limit checks alone are not enough.
Decisions they own
- Which agent-related features enter the risk model and how to weight unverified ones.
- Rule changes for agent traffic: velocity, device, geolocation and merchant-category exceptions.
- Review and step-up thresholds for agent-initiated orders.
- Which external trust signals (registries, scores, trusted lists) are allowed into decisions.
Vocabulary
- risk score
- signal
- velocity
- chargeback
- friendly fraud
- card testing
- agent indicator
- device data
- step-up
- false positive
- approval rate
- reason code
- risk_data
- Sybil
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: HighDesigns fraud rules for a merchant or acquirer and decides how much a valid TAP signature should lower friction. Source [1, 2, 3]
Goals
- Separate approved agents from malicious bots
- Stop replay and relay of signed requests
- Detect card testing through agents
Pains
- Signatures that do not cover the method, query or body
- Optional nonce tracking
- Consumer data that may be used even when unverified
Implements
- Rules that combine TAP results with other bot signals
- Nonce storage and replay alerts
- Credential hash comparison at key-entered checkout
Must trust
- The CDN's verification results
- Visa's agent onboarding
- VIC's passkey approval of the user's instruction
Questions they ask
- Is a valid browse signature enough to skip a challenge?
- What should I do with a payment container whose key I cannot find?
- Can an unsalted credential hash leak card data?
First three steps
- Log TAP verification results next to existing bot scores
- Turn on nonce tracking with an 8-minute retention
- Treat unverified consumer data as untrusted in risk scoring
Metrics they care about
- Fraud rate on TAP-verified versus unverified traffic
- Replay attempts blocked
- False declines on agent checkouts
A day in the life. Sam tunes fraud rules for an acquirer's merchants. A valid TAP signature proves an approved agent signed this host and path in the last 8 minutes, but nothing about the method or body. He scores TAP as one strong signal among others, keeps nonce records so a copied request fails, and refuses payment containers that fail verification. When a merchant asks to use unverified consumer data to skip login, he says no. He also flags the credential hash: without a stated salt, the hash of a card number and a three-digit code is weak.
Steps in the responsibility table
- ObservesOnboard the agent and register its key
- ObservesHost the key store (JWKS)
- ObservesSign each request with a TAP tag
- Relies onVerify header signature, window and nonce
- Relies onVerify body objects and process payment data
- ObservesApprove the purchase instruction with a passkey (VIC)
- ObservesAuthorize the card payment
- ObservesHandle a dispute on an agent purchase
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: HighModels fraud and disputes for an issuer, acquirer or merchant, and decides how agent transactions are scored and reviewed. Source [4, 5, 6, 7]
Goals
- Separate agent traffic from fraud
- Use signed evidence in disputes
- Avoid blanket declines of agent purchases
Pains
- No public description of the agent information or the probability score fields
- Verifiable Intent has no revocation protocol in 0.1
- Form-filling agents look like bots
Implements
- Rules keyed on agent indicators and signature verification results
- Review queues for deferred orders that fail intent validation
- Dispute evidence collection
Must trust
- The network's agent information and score
- Agent certification
- Merchant intent validation
Questions they ask
- How reliable is the agent information today?
- What does a Verifiable Intent chain prove in a dispute?
- Which attacks does the threat model leave open?
First three steps
- List the agent signals you receive today
- Read the Verifiable Intent security model
- Ask the network for probability score documentation
Metrics they care about
- Fraud basis points on agent transactions
- Dispute win rate with evidence
- Manual review rate
A day in the life. Lena runs fraud strategy for an acquirer. Agent transactions are still a small slice, but her models treat form-filling agents like bots. Mastercard's 2026-09-30 probability score tells her the network itself does not always know when an agent was involved. She reads the Verifiable Intent threat model and likes what it covers, replay, constraint stripping and split-agent attacks, but notes that version 0.1 has no revocation protocol. She sets up a separate review queue for agent orders and asks her network contact what the score looks like in the message.
Steps in the responsibility table
- ObservesRegister agent key and pass certification
- ObservesAuthenticate consumer and set limits
- ObservesSign request with Agent-pay-auth tag
- ObservesVerify signature at edge or backend
- ObservesDetokenize and check token limits
- ObservesVerify Verifiable Intent chain
- ImplementsApprove or decline
- ImplementsHandle dispute
Sources
- Trusted Agent Protocol merchant specifications (external link)
- draft-ietf-webbotauth-httpsig-protocol-00: HTTP Message Signatures for automated traffic (external link)
- Agentic Commerce: The Threat Landscape (external link)
- Mastercard Advances Agentic Commerce With New Trust and Intelligence Services (external link)
- Verifiable Intent: Security Model and Threat Analysis, version 0.1-draft (external link)
- Level 1 Agentic Commerce: Enable Agent Support with Minimal Changes (external link)
- Level 3 Agentic Commerce: Advanced Programmatic Checkout (external link)