Who controls whether an agent is allowed to spend? Visa, Mastercard, and crypto-native protocols are all building policy engines for agent spend — and only one will become the default.
Layer 3 answers: "Is this specific payment allowed?" It sits above identity (who is the agent?) and below the rails (how does money move). It's where spend limits, merchant allowlists, approval workflows, and delegation chains live. Whoever owns this layer controls the keys to the agent economy.
Why this is the biggest platform battle in payments
The company that owns agent authorization becomes the "Visa network" for the AI economy — every transaction has to route through its policy engine. That's a toll-road business with network effects. Visa and Mastercard are extending their existing card-control products. Crypto protocols are building from scratch with programmable on-chain logic. The question is: will enterprises trust their agent spend controls to card networks they already use, or to new infrastructure they don't control?
Traditional card networks extending to agents
Visa's agent payment authorization framework. TAP lets businesses define precise spending policies for AI agents — which merchants, which amounts, which categories, time windows. Built on top of Visa's existing tokenization infrastructure; no new card network needed.
Mastercard's competing product — programmable agent payment controls using their Multi-Token Network. Agent Pay lets businesses set spending parameters that travel with the payment credential, enforced at the network level regardless of merchant.
Crypto-native and open protocol approaches
Authorization baked directly into the payment transaction via ERC-3009. The payer signs a typed-data authorization specifying exact amount (ExactProxy) or maximum amount (UptoProxy). No separate policy engine needed — the cryptographic signature IS the authorization. Permissionless and auditable on-chain.
An emerging open protocol for agent payment authorization, distinct from x402. Focuses on the full authorization lifecycle: delegation (who authorized the agent), scope (what is the agent allowed to buy), and revocation (how is authorization cancelled). Designed to work across payment rails, not just crypto.
A broader standard covering agent-to-agent commerce including discovery, negotiation, and payment settlement. Authorization is one module within ACP — agents express what they're willing to pay, counterparties respond with what they'll accept, and the protocol mediates the authorization flow.
Account Abstraction enables smart contract wallets with programmable validation logic. An agent's wallet can enforce arbitrary spending rules in code: daily limits, allowed tokens, allowed recipients, multi-sig approval for large transactions. Most powerful but most complex to implement.
Who wins?
Card networks (Visa, Mastercard) have distribution — billions of existing accounts, thousands of bank partners, merchant terminals already deployed. Their agent products will be adopted by enterprises that trust existing rails. Crypto protocols (x402, ERC-4337) have programmability and auditability — every authorization is on-chain, no permission needed, no intermediary to capture rent. The most likely outcome: card-network controls dominate for fiat/enterprise, on-chain controls dominate for agent-to-agent and crypto-native payments. AP2/ACP as a unifying standard is the long-shot bet.