Agentic Rails Atlasby merces.ai

Persona

Card network product owner

Token standards, rules, ecosystem programs.

Verified (verified under 30 days ago)

Role

Goals

  • Define the agentic token format and lifecycle that issuers, acquirers and agent providers implement.
  • Run an agent registration and key directory so merchants and CDNs can recognize trusted agents.
  • Publish rules for agent transactions: indicators, step-up, disputes and liability.
  • Grow acceptance through PSPs, CDNs and agent platforms without forcing merchants to rebuild checkout.
  • Keep card rails relevant against stablecoin pay-per-call protocols by joining their governance (the x402 Foundation, the MPP card method).
  • Align with IETF Web Bot Auth, FIDO and EMVCo so the network scheme does not become a proprietary island.

Pains

  • The network's own spec (TAP) sits under revocable proprietary terms and lags the IETF draft, which draws criticism.
  • Agent indicators are not populated reliably, so fraud models and issuers cannot rely on them.
  • Live agent transactions are still controlled pilots, and no public volume exists to show progress.
  • Liability rules for agent disputes do not exist yet, and every issuer and acquirer is asking.
  • Agents filling checkout forms with token-shaped values keep legacy acceptance alive but defeat the purpose of agent recognition.
  • Two networks run two different directories and two different token definitions, and merchants want one.

Decisions they own

  • Token scoping model: per interaction, per merchant, or per mandate.
  • Rules for liability and dispute reason codes on agent-initiated transactions.
  • Which identity protocols to accept (own directory, Web Bot Auth, Know Your Agent partners).
  • Which external standards bodies to align with and when to retire the proprietary spec.
  • Program requirements for agent certification and trusted lists.

Vocabulary

  • agentic token
  • tokenization
  • key directory
  • Signature-Input
  • tag
  • Web Bot Auth
  • Know Your Agent
  • liability shift
  • reason code
  • scheme rules
  • EMVCo
  • acceptance framework
  • Agent Score

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.

ERC-8004: Trustless Agents

Relevance: None

Not one of the main personas on the ERC-8004: Trustless Agents page. The responsibility table gives this persona no step.

x402

Relevance: None

Not one of the main personas on the x402 page. The responsibility table gives this persona no step.

Visa Trusted Agent Protocol

Relevance: High

Visa itself: writes the specification, onboards agents, hosts the key store and signs the ID Token. Source [1, 2, 3, 4, 5]

Goals

  • Make agent commerce on Visa credentials safe enough for merchants to allow it
  • Keep agent identity tied to VIC participation
  • Align with standards bodies over time

Pains

  • A competing Mastercard design with another tag and directory
  • Criticism of proprietary terms and an unversioned specification
  • A sample repository that has not changed since 2025-10-28

Implements

  • The TAP specification and Product Terms
  • The key store at mcp.visa.com
  • The Agentic Directory and Agent Score

Must trust

  • Agent Providers to protect their signing keys
  • CDNs to verify correctly
  • Merchants to handle consumer data lawfully

Questions they ask

  • When does TAP get a version number and test vectors?
  • Can the key store be shared across payment schemes?
  • How does TAP map to the IETF Web Bot Auth draft?

First three steps

  1. Publish versioned specifications and test vectors
  2. Publish the production key distribution model
  3. Bring the sample code to RFC 9421 conformance

Metrics they care about

  • Merchants verifying TAP
  • Agent transactions on VIC
  • Disputes and fraud on agent transactions

A day in the life. Tom works on the agentic commerce team at Visa. TAP launched on 2025-10-14 with twelve partners and Cloudflare, and by 2026-07-02 agents completed live purchases at named European merchants. His inbox holds the hard questions: why the key store has one sandbox RSA key, why the examples cannot verify, and why community fixes sit unmerged. He also follows the IETF Web Bot Auth draft, which differs from TAP in tags and key discovery. He drafts a plan for a versioned specification with test vectors and a public directory.

Steps in the responsibility table

  • OwnsOnboard the agent and register its key
  • OwnsHost the key store (JWKS)
  • ImplementsSign the consumer and payment objects
  • OwnsApprove the purchase instruction with a passkey (VIC)
  • ImplementsAuthorize the card payment
  • Relies onHandle a dispute on an agent purchase

Agentic Commerce Protocol (ACP)

Relevance: None

Not one of the main personas on the Agentic Commerce Protocol (ACP) page. The responsibility table gives this persona no step.

UCP

Relevance: None

Not one of the main personas on the UCP page. The responsibility table gives this persona no step.

AP2

Relevance: None

Not one of the main personas on the AP2 page. The responsibility table gives this persona no step.

Mastercard Agent Pay

Relevance: High

Mastercard itself: registers and certifies agents, runs the key directory and trusted agent lists, issues and detokenizes agentic tokens, and verifies Verifiable Intent chains before authorization. Source [6, 7, 8, 9, 10]

Goals

  • Make every agent transaction recognizable to every party
  • Keep raw card numbers away from agents
  • Set the rules other networks and EMVCo converge on

Pains

  • Agents that still drive human checkout forms
  • Stateful Verifiable Intent constraints that need new network-side state
  • Competing formats from Visa, Google and others

Implements

  • Agent registration, security review and trusted agent lists
  • Agentic token issuance and detokenization
  • The probability score for AI-initiated transactions in US testing

Must trust

  • Agent developers to keep signing keys safe
  • Acquirers to register merchants correctly
  • Issuers to make sensible decisions with the additional information

Questions they ask

  • How do we revoke an agent across the network?
  • Where do we hold budget and occurrence state for Verifiable Intent mandates?
  • How do our tags and directory align with the IETF Web Bot Auth draft?

First three steps

  1. Publish a resolvable key directory location
  2. Document a revocation path for agents and tokens
  3. Fix the duplicate-digest issue in the Verifiable Intent L2 format

Metrics they care about

  • Registered and certified agents
  • Agentic tokens issued
  • Share of agent transactions verified with Verifiable Intent

A day in the life. Marco works on the network side of Agent Pay. His team certifies agents, keeps the trusted lists and issues the tokens, and since 2026-09-30 it tests a probability score for transactions that look agent-initiated. That score exists because not every agent purchase arrives with a clean flag. His backlog is long: a key directory location that developers can actually resolve, a revocation path for a misbehaving agent, network-side state for Verifiable Intent budgets, and an open issue saying the L2 format lists digests twice. He starts with the directory, because every merchant verification depends on it.

Steps in the responsibility table

  • OwnsRegister agent key and pass certification
  • Relies onRegister merchant for Agent Pay
  • OwnsProvision agentic token
  • Relies onSign request with Agent-pay-auth tag
  • OwnsDetokenize and check token limits
  • VerifiesVerify Verifiable Intent chain
  • Relies onApprove or decline
  • ImplementsHandle dispute

Sources

  1. Visa Introduces Trusted Agent Protocol: An Ecosystem-Led Framework for AI Commerce (external link)Visa. Announcement, primary source. Published . Accessed .
  2. Visa and Banks Across Europe Reach the Next Phase of Agentic Commerce, Unlocking Secure Access to Merchants (external link)Visa. Announcement, primary source. Published . Accessed .
  3. Visa well-known JWKS (live fetch) (external link)Visa. Dataset, primary source. Accessed .
  4. visa/trusted-agent-protocol repository metadata, commits, pull requests and issues (GitHub API) (external link)GitHub. Repository, primary source. Accessed .
  5. draft-ietf-webbotauth-httpsig-protocol-00: HTTP Message Signatures for automated traffic (external link)IETF Web Bot Auth working group. Standard, primary source. Published . Accessed .
  6. The Rails for Agentic Commerce (external link)Mastercard Developers (Merchant Cloud tutorials). Documentation, primary source. Accessed .
  7. Mastercard Advances Agentic Commerce With New Trust and Intelligence Services (external link)Mastercard (Investor Relations, Business Wire release). Announcement, primary source. Published . Accessed .
  8. Level 1 Agentic Commerce: Enable Agent Support with Minimal Changes (external link)Mastercard Developers (Merchant Cloud tutorials). Documentation, primary source. Accessed .
  9. Verifiable Intent: Security Model and Threat Analysis, version 0.1-draft (external link)agent-intent (Verifiable Intent Working Group). Specification, primary source. Published . Accessed .
  10. VI v0.1 L2 format lists each mandate disclosure digest in both _sd and delegate_payload; RFC 9901 requires verifiers to reject the credentials (external link)GitHub (agent-intent issue). Repository. Published . Accessed .

Source details

    Loading the index.

    Enter open Esc close ? shortcuts