Tokenization for AI agents is the set of mechanisms that replace raw payment credentials with scoped, ephemeral tokens an agent can hold without ever seeing the underlying card number, private key, or bank account. The pattern is older than agentic commerce — Apple Pay, Google Pay, and Mastercard Digital Enablement Service have used network tokens for a decade — but the agent context tightens the requirement on three axes: a token must be bound to a specific merchant, capped at a specific amount, and expire on a defined window. Five categories carry the load in 2026: virtual card tokens (Stripe Issuing, Lithic, Marqeta, Highnote), network tokens (Mastercard Agentic Tokens, Visa-tokenized credentials), Shared Payment Tokens (the OpenAI ACP SPT), custodial agent wallet keys (Stripe Link Agent, Coinbase Agentic Wallets), and onchain stablecoin authorizations (EIP-3009, Permit2). This piece walks through how each category issues its tokens, how scoping fields travel through authorization, how identity layers like Visa TAP attach to the token at the HTTP layer, and how the trade-offs shake out per category.
​

Tokenization for AI agents is the practice of issuing scoped, ephemeral payment credentials that an agent presents in place of a raw card number, private key, or bank credential. Each token carries explicit fields for merchant, amount, expiry, and single-use status. The token resolves to the underlying instrument only at the issuer or settlement layer, never at the agent.
​

The category covers any credential format whose authority is narrower than the underlying instrument. A Mastercard MDES network token resolves only for purchases that match the user-set scope. A Stripe-issued SPT resolves only for the merchant and amount the buyer's wallet authorized. A signed EIP-3009 authorization resolves only for the single (from, to, value) tuple the user signed. The shared property: the underlying instrument never leaves the issuer; the token does.
​

The pattern is older than agentic commerce. Mastercard's MDES has replaced PANs with tokenized representations since the early 2010s for Apple Pay, Google Pay, and click-to-pay. What changed for agents is the granularity. Apple Pay tokens were tied to a device; agent tokens are tied to a session, an agent identity, and a single transaction or short window. Three properties define a working agent token: specificity (merchant, amount, time bounded), verifiability (issuer and merchant can independently confirm authorization), and revocability (the user can pull the token without affecting the underlying instrument).
​

Tokenization is the credential-layer answer to the agent-trust problem. Adjacent layers cover the rest: agent spend controls define the policies the tokens enforce, agent wallets are where the tokens live in custody, identity protocols like Visa TAP sign agent identity into the request, and AP2 mandates wrap the user's authorization around the token in a signed payload.
​

Agent tokenization works in four steps: token issuance binds a credential to a merchant, amount, and expiry; identity attestation attaches the agent and user identity through TAP, AP2, or KYAPay; the agent presents the token at checkout where the merchant validates the scope fields; and the issuer resolves the token to the underlying instrument.
​

Step one is issuance. The user, the user's wallet, or the user's treasury asks an issuer to mint a token with explicit scoping fields. On a card rail the request lands at Stripe Issuing, Lithic, Marqeta, or Highnote with parameters like `spending_controls.allowed_merchants` and `spending_controls.spending_limits`. On a network rail it lands at Mastercard MDES or Visa Token Service with an agent identifier and a session-scope object. On a stablecoin rail the user signs `(from, to, value, validBefore, nonce)` per EIP-3009 off-chain, and any caller submits it on-chain.
​

Step two is identity attestation. Most production stacks attach a separate proof of who is using the token. Visa TAP signs the agent operator's identity into HTTP request headers via RFC 9421 HTTP Message Signatures. Skyfire's KYAPay JWT bundles agent identity with spend authorization in a single Bearer credential. AP2 mandates sign the user's authorization for the specific transaction, so the merchant has cryptographic evidence that this user authorized this agent to charge this token at this merchant for this amount.
​

Step three is presentation and validation. The agent presents the token at checkout, and the merchant — or a facilitator service in the case of x402 — checks the token's scope fields against the request. A virtual card with `allowed_merchants: ["mer_notion"]` declines automatically when presented elsewhere. An EIP-3009 authorization is checked by the token contract: time window, unspent nonce, and signature must all validate before the transfer executes. A Mastercard Agentic Token is validated against its session, limit, and merchant scope inside Mastercard's authorization rail.
​

Step four is settlement. The issuer resolves the token to the underlying instrument — the saved card, the user's bank account, the user's USDC balance — and books the transaction. The agent never sees the resolved credential; the merchant sees only the token. The audit trail records agent identifier, token identifier, merchant, amount, and timestamp, which makes scoped revocation and per-agent dispute attribution possible.
​

Five token categories cover agent payments in 2026: virtual card tokens from card-issuing platforms, network tokens from card networks, Shared Payment Tokens defined in the OpenAI ACP, custodial wallet keys held by agent-wallet products, and onchain stablecoin authorizations under EIP-3009 and Permit2. Most production agents combine two or three depending on rail.
​

A virtual card token is a card credential generated through an issuing API, scoped at issuance to a merchant set, an amount, and an expiry. Stripe Issuing exposes single-use card creation through its Issuing API; controls cover allowed merchants, MCC blocklists, daily and monthly caps, and country restrictions. Each card is a real PAN routed through Stripe's BIN sponsor relationships, so the resulting token works at any merchant accepting the underlying network.
​

Lithic, founded as Privacy.com, is the second large card-issuing platform shipping agent-targeted features and a founding member of the Agentic Commerce Consortium alongside Basis Theory, Skyfire, Rye, Crossmint, and Channel3. Its API exposes the same single-use primitive plus per-card auth velocity caps, real-time webhooks on every authorization event, and card creation latencies in the tens of milliseconds. Marqeta and Highnote occupy the same category for enterprise issuers.
​

The dominant agent pattern is per-vendor virtual cards. A B2B procurement agent renewing Notion, Linear, and Vercel mints three cards — each restricted to one merchant identifier, capped at the budgeted amount, expiring at month-end. Agent spend controls covers the broader policy surface. The trade-off is volume: a procurement agent paying twenty invoices a day generates twenty card requests. Acceptable at $200-$2,000 per transaction; impractical for $0.30 inference calls, which is where the stablecoin-authorization category takes over.
​

A network token is a tokenized credential issued by the card network itself rather than by an issuing-API platform sitting in front of the network. Mastercard Agentic Tokens and Visa's tokenized credentials inside Visa Intelligent Commerce are the named primitives in 2026; both extend long-running network tokenization frameworks (MDES at Mastercard, Visa Token Service at Visa) with two new fields specific to agent payments — an agent identifier and a session-scope object.
​

Mastercard unveiled Agent Pay on April 29, 2025 with Microsoft, IBM, Braintree, and Checkout.com as launch partners. Each Agentic Token binds a tokenized payment credential to a specific agent identity with per-session and per-merchant limits. The pilot ran with Citi and US Bank cardholders in September 2025; the full US rollout completed in November 2025. Deeper coverage lives in Mastercard Agent Pay explained.
​

Visa's analogue is the tokenized credential inside Visa Intelligent Commerce, with the Trusted Agent Protocol identity layer wrapped around it. Where Mastercard puts the agent identifier inside the token, Visa's design separates the layers: the credential remains a normal Visa Token Service token, and TAP signs the agent identity into the HTTP headers carrying the request. Both designs end up with the same property — per-agent attribution — but differ at the wire format. The Visa Intelligent Commerce program runs through pilots with Skyfire, Nekuda, PayOS, and Ramp, with rollout across Asia Pacific and LatAm announced after the EU and UK launches.
​

The strategic difference between network tokens and virtual-card tokens is who issues the credential. Network-issued tokens ride the existing card rail with no merchant integration burden — the processor sees a tokenized credential structured like any other, and the network resolves it at the authorization layer. Virtual cards from Stripe Issuing or Lithic require BIN sponsor relationships but give developers full programmatic control over per-card scope fields. Most production stacks use both: virtual cards for B2B procurement, network tokens for consumer agent surfaces.
​

A Shared Payment Token (SPT) is the credential primitive defined in the OpenAI Agentic Commerce Protocol. The SPT is a token issued by the buyer's payment provider — typically Stripe in 2026 — that is scoped to one merchant and one maximum amount, with a short expiry. The agent passes the token to the merchant; the merchant runs it through its normal processor; a second attempt fails because the token has resolved.
​

The SPT solves a specific problem in the ChatGPT shopping flow. The user's saved cards live with the buyer's payment provider (Stripe in the launched pattern); the merchant runs its own processor. ACP needed a credential that crossed the buyer-merchant boundary without exposing the user's actual card to the merchant or to OpenAI. The SPT is that bridge — bound to the merchant, capped at the amount the user confirmed, expiring after use.
​

ChatGPT Instant Checkout launched on this primitive on September 29, 2025 with Etsy, available to ChatGPT Free, Plus, and Pro tiers in the US. OpenAI retired Instant Checkout in March 2026, but the ACP specification and the SPT primitive persist. Other implementers — Stripe customers building agent surfaces, agent-platform startups in the Agentic Commerce Consortium — continue to issue SPTs against the spec. The pattern travels because it is the cleanest credential answer wherever the buyer's payment provider differs from the merchant's processor. The trade-off is the same as any single-use credential: clean per-transaction attribution but a per-token issuance cost that rules out high-frequency micropayments.
​

A custodial agent wallet key is a credential the wallet provider holds on the user's behalf, with the agent authorized to spend within the wallet's policy framework. Stripe's Link Agent and Coinbase Agentic Wallets are the two named products; both expose the custody primitive plus a session-key issuance API that hands the agent a scoped subkey rather than the underlying private key.
​

Stripe's Link Agent product runs as the consumer surface on top of the Stripe Link wallet, which has more than 250 million users globally per Stripe Sessions 2026. The Link Agent token is not the user's saved card; it is a scoped permission inside the Link account that authorizes an agent to transact within configured limits. Link Agent's product page documents the configurable mode where customers require approval for every purchase or set granular controls so the agent transacts within defined limits. Settlement still happens through the user's saved Link card or a stablecoin endpoint via x402.
​

Coinbase Agentic Wallets, launched February 2026, expose a wallet API designed for agent custody on EVM chains. The SDK supports session keys (a scoped delegation modeled on EIP-7702), per-token allowances enforced at the smart-contract layer, and an activity log capturing every transaction with timestamp, signer, and counterparty. The session key is the token in this design — a private key the agent can sign with, but constrained at the contract layer to the authorized scope. Coinbase's broader Agent.market, launched April 2026, uses the wallet primitive for agent-to-agent stablecoin payments via x402.
​

The defining property is custody. The wallet provider holds the underlying private key or card credential; the agent holds a scoped delegation. Where virtual cards and SPTs answer "what can the agent spend," wallet keys answer "what can the agent sign." The two often compose: a Coinbase Agentic Wallet session key plus a Permit2 allowance plus a server-side spend ceiling is the typical machine-to-machine stack.
​

Onchain stablecoin authorizations are signed off-chain messages that a token contract validates and executes. EIP-3009 defines `transferWithAuthorization`: the token holder signs `(from, to, value, validAfter, validBefore, nonce)` off-chain, anyone submits the signature, and the contract validates the time window, marks the nonce used, and executes the transfer. Uniswap's Permit2 generalizes the pattern across any ERC-20 with batched approvals and a `lockdown()` function for atomic revocation.
​

USDC implements EIP-3009 natively across its supported chains. Coinbase's x402 protocol uses EIP-3009 (with Permit2 as a fallback) for HTTP 402 payment payloads — the agent constructs the signed message in response to the merchant's `PAYMENT-REQUIRED` header and returns it via `PAYMENT-SIGNATURE`. Per Insignia VC analysis as of late April 2026, x402 had processed roughly 165 million transactions across 69,000 active agents and approximately $50 million in cumulative volume — almost all flowing through EIP-3009 signatures on USDC, with average transaction value under $0.31.
​

EIP-2612 is the older Permit standard — `permit(owner, spender, value, deadline)` signed off-chain, validated and applied in the same transaction the spender uses to pull funds. DAI and native USDC on several chains implement EIP-2612 directly. Permit2 layers on top with batched approvals and atomic revocation. EIP-7702, activated in the Pectra hard fork in 2025, lets an externally owned account (EOA) temporarily delegate to smart-contract code, which is the primitive most session-key implementations use to scope an agent's signing authority.
​

This is the only category with no ongoing issuer relationship. The user signs locally; the agent submits anywhere; the token contract verifies. That property is what makes the category economical at sub-cent values. The trade-off is revocation latency: spending the nonce manually (EIP-3009), calling `lockdown()` (Permit2), or signing a new EIP-7702 delegation pointing at `0x0`. None are as fast as deactivating a virtual card through an issuer dashboard, which is why high-value B2B agent flows still lean toward card-token categories. The total stablecoin market sits at roughly $318 billion per DeFiLlama as of April 2026, with USDT at ~$189.5 billion and USDC at ~$77.3 billion — the two tokens carrying the bulk of agent-rail authorization volume because they have the broadest contract support and deepest cash-out liquidity.
​

Every agent token carries the same four scoping fields in different idioms. Merchant scope binds the token to allowed merchants. Amount scope caps the value the token authorizes. Expiry binds the token to a time window. Single-use marks whether the token is consumed after one transaction. The four fields are how the credential narrows the underlying instrument.
​

Merchant scope prevents a token authorized for one merchant from being used at another. On Stripe Issuing the relevant fields are `spending_controls.allowed_categories` (and `blocked_categories`) plus per-merchant blocking, scoped via MCC. On Mastercard Agentic Tokens it lives inside the session-scope object and resolves at the network's authorization layer. On an SPT the merchant is bound at issuance; ACP ties one SPT to one merchant by design. On EIP-3009 the `to` address inside the signed payload is the binding — a different recipient produces a different signature.
​

Amount scope caps the value the token can authorize. On a virtual card the field is `spending_controls.spending_limits.amount`. On an SPT the amount is bound at issuance — the buyer's wallet generates the SPT for an exact amount, and the merchant's processor either matches or fails. On EIP-3009 the `value` field is the cap and the floor at once. Permit2 differs slightly — a single approval can back multiple `PermitTransferFrom` transfers up to the cumulative cap.
​

Expiry binds the token to a wall-clock window. On Stripe Issuing it is the card expiration plus any active spending-limit interval. On a JWT credential like Skyfire's KYAPay it is the `exp` claim. On Mastercard Agentic Tokens the session lifetime — typically minutes to hours — sets the window. On EIP-3009 it is `validBefore`/`validAfter`. On Permit2 it is the `expiration` field per allowance and the `deadline` per `PermitTransferFrom`.
​

Single-use is the property that the token is consumed after one transaction. Single-use virtual cards are the simplest expression. EIP-3009 is structurally single-use because the nonce can be spent only once. SPTs are single-use by protocol design. Network tokens and time-bounded JWTs are not — they remain valid until the session closes or the JWT expires, suitable for high-throughput flows where single-use issuance overhead is too expensive.
​

The combination defines the token's blast radius. A single-use virtual card scoped to one merchant for $50 expiring in five minutes has near-zero blast radius. A token without merchant scope, amount cap, or expiry — i.e., a saved card — has unbounded blast radius, which is why no production agent stack hands one to the agent directly.
​

AI agents need their own tokens because they act asynchronously and cannot be shown a saved card without inheriting full payment authority. A scoped, ephemeral token gives the agent enough authority to complete a specific task and no more, while preserving the issuer's ability to attribute disputes and revoke per-agent rather than per-card.
​

A human shopper decides and presses a button at the same instant — authorization and action collapse into one event. An agent receives a goal, plans over minutes or hours, and executes against credentials issued earlier. Without an ephemeral, scoped token, the agent's saved-card credential is functionally the user's full payment authority for as long as the agent holds it. Tokenization is the credential-layer fix: the scope fields encode what the user actually authorized, and the issuer's resolution step refuses to honor anything outside that scope.
​

The dispute attribution problem is the second reason. If one saved card backs three agents and one starts triggering chargebacks, the issuer has no way to revoke that agent's access without revoking the card. Every transaction looks identical at the network layer. Agent-bound tokens (Mastercard Agentic Tokens, per-agent virtual cards, Coinbase Agentic Wallet session keys) carry the agent identifier into the audit record, so revocation, fraud rules, and consent attestations scope to a specific agent. The same logic underpins Visa TAP's HTTP-header signing — the identity claim travels with the request even when the underlying credential is a normal Visa token.
​

The third reason is regulatory. PSD2 in the EU, PCI DSS globally, and most issuer fraud policies assume the entity presenting a card is the cardholder or a delegate under a specific authorization. Agentic commerce stretches that assumption. Tokenization gives every agent transaction a distinct credential and a distinct audit trail, which lets issuers reason about agent traffic without rewriting the underlying compliance framework. Mastercard's September 2025 agentic-commerce framework — the Agent Toolkit and the FIDO Alliance verifiable-credential collaboration — sits on top of exactly this attribution.
​

Tokenization for agents trades flexibility for control along four axes: revocation latency, refund mechanics, custody complexity, and dispute attribution. Single-use tokens have the cleanest revocation but highest issuance cost. Time-bounded tokens have the highest throughput but require server-side revocation lists. Onchain authorizations have the lowest fees but the longest revocation paths. No category dominates; production stacks compose two or three.
​

Revocation latency varies by category. A virtual card deactivated through a Stripe Issuing or Lithic dashboard is invalid network-wide within seconds. A Mastercard Agentic Token revoked through the issuing bank's app propagates through the directory within minutes. A time-bounded JWT remains valid until the issuing server adds it to a revocation list. An EIP-3009 authorization remains valid until the user spends the nonce manually, calls `lockdown()` on Permit2, or signs a replacing EIP-7702 delegation pointing at `0x0`. Card-issuer revocation is the fastest path; onchain revocation is the slowest.
​

Refund mechanics differ by rail. Card-rail tokens inherit the network's chargeback and refund flow — the merchant issues a refund through the same processor that ran the authorization. Onchain stablecoin authorizations have no native refund equivalent; a merchant refunding USDC has to construct and broadcast a separate transfer, with no chargeback path. For high-value transactions where dispute rights matter, card-rail tokens dominate. For machine-to-machine API payments where refunds are rare, the missing mechanism is acceptable.
​

Custody and dispute attribution round out the trade-offs. Virtual cards and network tokens require an issuer relationship, a BIN sponsor, and PCI DSS-compliant infrastructure. Onchain authorizations require only that the user sign locally and the smart contract support the EIP, which is why machine-to-machine stacks gravitate there. Card networks have decades of chargeback infrastructure; tokens carrying agent identifiers extend that infrastructure to per-agent attribution. Onchain transactions are non-repudiable but lack a chargeback equivalent — recovering funds requires either the merchant's voluntary refund or legal action. Card-rail tokens carry recourse; onchain authorizations carry finality.
​

The table below summarizes the trade-offs across the five categories.

Card-rail categories trade higher per-transaction cost for native dispute and refund paths; stablecoin authorizations trade those rights for sub-cent costs and unbounded throughput; custodial wallet keys split the difference by holding underlying credentials in custody but exposing session-scoped delegation to the agent. Most production stacks pick one category as the primary credential and layer one of the others as a fallback. Coverage of the composition patterns lives in agent spend controls.
​

Eco operates a stablecoin orchestration network across 15 chains, complementing tokenization rather than overlapping with it. Tokenization defines the credential the agent holds; Eco defines how the dollars actually settle when an agent paying USDC on one chain transacts with a counterparty whose treasury sits on another. The two layers compose without conflict.
​

Tokenization narrows the credential the agent presents; it does not move money on its own. The actual transfer settles on a rail underneath — a card authorization for card tokens, the merchant's processor for SPTs, the relevant ERC-20 contract for EIP-3009 authorizations. For agents and merchants settling in stablecoins, Eco handles the cross-chain orchestration that tokenization leaves open: an EIP-3009 authorization signed against USDC on Base can land in a counterparty's treasury on Solana or Tron, with Eco's solver network choosing the route, the bridge, and the finality guarantees. The same logic applies to Coinbase Agentic Wallets running multi-chain balances and to Stripe Link Agents using x402 for stablecoin endpoints behind their card-rail front. Eco uses Hyperlane and CCTP for the underlying transport. Tokenization layers and stablecoin orchestration networks solve different problems, and the production stacks emerging in 2026 use both.
​

For broader context on how tokenization composes with the surrounding agent commerce stack, the following pieces in this knowledge base cover the adjacent layers:

Sources and methodology. Token format details verified against primary sources: Stripe Issuing API documentation, Lithic platform documentation, Mastercard MDES technical reference, Mastercard's April 29, 2025 Agent Pay announcement, the Stripe-OpenAI Instant Checkout launch announcement, EIP-3009, and the Uniswap Permit2 repository. x402 transaction figures from Insignia VC's late-April 2026 analysis. Stablecoin supply figures from DeFiLlama as of April 2026 and refresh quarterly. Partner lists reflect launch announcements; production deployment characterizations reflect public processor and platform integrations as of Q1 2026.
​