Why architecture matters here
The architectural argument for tokenization is scope arithmetic. Systems that store, process, or transmit PANs fall inside the PCI DSS cardholder-data environment, and everything inside that boundary carries audit, segmentation, and hardening obligations. An agent runtime is the worst possible resident: it logs promiscuously (transcripts, tool traces, checkpoints), it persists state across sessions, and its inputs are adversarial by default. Put a PAN in an agent's context once and it can surface in an event log, an artifact store, a fine-tuning corpus. Tokenize at the edge and the entire agent stack drops out of scope: a token bound to one merchant, one channel, and a spend ceiling is worthless in a dumped transcript.
The second argument is blast-radius shaping. A stolen PAN works everywhere until reissued — and reissue kills every legitimate credential-on-file with it. A stolen network token fails outside its domain restrictions and dies individually: suspend the one token, the card and every other token on it keep working. For agents this maps exactly onto the authorization problem AP2's mandates address — the user did not hand the agent their card, they granted a scoped spending capability, and a domain-restricted token is that capability made concrete at the payment layer. Authorization semantics and credential semantics finally agree, which is precisely what raw PANs can never offer: a PAN is an unscoped bearer secret in a world that wants capabilities.
The architecture: every piece explained
The token service provider (TSP) — operated by the card networks, sometimes fronted by wallets or PSPs — owns issuance: it verifies the card with the issuer (identity-and-verification checks, sometimes a step-up OTP), mints a surrogate PAN from a dedicated token BIN range, and records the token-to-PAN mapping in the token vault, the one store that can translate back, guarded by HSM-held keys inside the network's own CDE. Alongside issuance, the TSP maintains domain restriction controls per token: merchant binding, channel binding (e-commerce only, this wallet only), and increasingly amount and frequency profiles — the enforcement hooks an agent platform leans on.
The cryptogram service supplies the per-transaction proof: a TAVV-style cryptogram derived from token-scoped key material, single-use, verified by the network at authorization time — possession of the token alone authorizes nothing. In the agent layer, the mandate binding ties the token reference into the AP2 object graph: the intent mandate (what the user asked for), the cart mandate (what is being bought), and the payment credential travel as one signed bundle, so the issuer's risk engine can see agentic transaction, user-present mandate, token domain matches merchant instead of a bare card-not-present auth. The lifecycle engine handles the verbs — provision, activate, suspend, resume, rotate, delete — driven by both sides: issuers push updates when cards are reissued (the token survives; the vault remaps it to the new PAN), and the agent platform revokes when a mandate expires or a runtime is compromised. PSP tokens layer on top for merchants who never want to see even a network token; the principle is identical one level up.
End-to-end flow
End to end: enrollment first. The user adds a card to the agent platform's wallet; the platform calls the TSP, the issuer approves (with a step-up challenge if risk demands), and the vault mints token 4802 90… bound to domain agent-platform channel, merchant-class scoped. The agent receives only an opaque reference — not the token PAN, and never the real PAN, which no system outside the issuer and vault ever stored.
Purchase time: the user has a standing intent mandate — up to $120/month on office supplies. The agent negotiates a cart with a merchant, the cart mandate is signed, and the platform's payment orchestrator asks the TSP for a cryptogram against the token, presenting the mandate context. The merchant's PSP submits token + cryptogram + mandate references through the acquirer to the network; the network verifies the cryptogram, checks domain restrictions (merchant category matches, channel matches), swaps the token for the PAN inside its own boundary, and forwards to the issuer — whose risk engine sees a cryptographically attested agentic purchase inside an authorized envelope and approves. The response returns along the same path; the receipt mandate is written with the token reference, never a card number. Months later the card is reissued after a compromise elsewhere: the issuer pushes the new PAN to the vault, the token remaps silently, and the agent's standing mandate keeps working — no re-enrollment, no failed subscription run. When the user revokes the mandate, the lifecycle engine suspends the token the same hour; anything replayed from old logs dies at the domain check.