Agent spend controls are the mechanisms that bound an AI agent's authority to move money. Every control narrows the surface in one of four ways: how much the agent can spend, who it can pay, when its authorization is valid, and whether each purchase needs human confirmation. The set covers card primitives (one-time-use virtual cards, scoped Shared Payment Tokens, Mastercard Agentic Tokens), protocol primitives (Google's AP2 mandates, Visa's Trusted Agent Protocol), wallet primitives (session keys via EIP-7702, single-use authorizations via EIP-3009), and onchain allowance primitives (EIP-2612 Permit and Uniswap Permit2). This guide walks through how each layer enforces a constraint, when to combine them, and how production products — Stripe Link Agent, Mastercard Agent Pay, Skyfire KYAPay, Nekuda Mandates SDK, Coinbase Agentic Wallets — assemble the primitives into a working stack.
​

Agent spend controls are the credentials and rules that bound an AI agent's authority to move money. Five categories cover the surface in 2026: one-time-use cards and tokens, time-bounded JWTs, programmable onchain allowances, cryptographic mandates, and real-time approval flows. Production stacks combine two or three to enforce specificity, verifiability, and revocability at once.
​

Agent spend controls are the rules and credentials that constrain what an AI agent can do with money on behalf of a user or company. The category covers any mechanism that bounds the agent's authority: a per-transaction cap on a virtual card, a 30-minute expiry on a JWT, a merchant whitelist on an OAuth scope, an `expires_at` field on an AP2 mandate, an `expiration` parameter on a Permit2 allowance, or a push notification that requires human confirmation before each purchase. The mechanism layer matters less than the property being enforced — the same property (spend ceiling, time window, merchant scope, single-use, revocability) shows up across card, protocol, wallet, and onchain primitives, just expressed in the relevant idiom.
​

Spend controls exist because agents act asynchronously. A human shopper decides and presses a button at the same moment; the authorization and the action collapse into one event. An agentic commerce flow receives a goal, plans over minutes or hours, and executes against credentials issued earlier. Without explicit constraints, the delegated credential is functionally the user's full payment authority for as long as the agent holds it. The Mastercard Agent Pay rollout — Citi and US Bank cardholders in September 2025, full US in November 2025 — wraps every purchase in user-defined permission rules for exactly this reason.
​

Three properties define a working stack. Specificity: a credential carries the exact merchant, amount, and time it authorizes, not blanket account access. Verifiability: the issuer and the merchant can independently confirm authorization at transaction time. Revocability: a user, a treasury admin, or an automated risk rule can pull the agent's authority back without invalidating other parts of the user's payment surface. Most production stacks layer multiple primitives because no single primitive cleanly delivers all three.
​

Agent spend controls work across three enforcement points: credential issuance sets the boundary (merchant, amount, expiry); transaction-time validation checks the credential against authorization data; and post-transaction monitoring logs agent identity, mandate ID, and counterparty for revocation and dispute. Each point reads the fields the credential carries.
​

Every agent purchase passes through three enforcement points: credential issuance sets the boundary, transaction-time validation checks it, and post-transaction monitoring catches what slipped through. A single procurement scenario is the cleanest way to see all three at once.
​

A finance lead at a 50-person startup tells an agent to renew Notion, Linear, and Vercel next Tuesday, total budget $1,800. At credential issuance, the lead generates three single-use virtual cards via Stripe Issuing, each with a per-merchant restriction and a $600 cap. The cards exist before the agent acts; their parameters define what's possible. On protocol rails the shape is identical: an AP2 mandate is signed once with `merchant_id`, `amount_max`, and `expires_at`, and the agent carries the signed payload to checkout.
​

At transaction time, the agent submits the card to Notion's checkout. The Stripe authorization network reads the merchant identifier from the auth message, matches it against the card's allowed-merchant set, and approves or declines in milliseconds. If the agent tries to use the same card at a different merchant, the network declines without calling the issuer's risk engine. On AP2 rails, the merchant verifies the user's signature on the mandate against the user's registered public key. On x402 rails, the server checks the EIP-3009 signature, the `validBefore` timestamp, and the unspent nonce before delivering the resource.
​

After the transaction, the system stores an attribution record: agent identity, mandate or card identifier, merchant, amount, timestamp. The record drives two downstream functions. Dispute attribution: chargeback rules assume a human pressed the buy button, so the agent record gives the issuer a place to anchor agent-specific liability. Anomaly detection: if the agent suddenly tries to charge five cards in three minutes, a downstream rule can revoke the remaining cards before the budget runs.
​

The mechanism only works when each point has the data it needs. A credential issued without merchant scope can't be checked at transaction time. A transaction logged without an agent identifier can't be revoked by agent. The rest of this article is about which primitives carry which fields and what they cost.
​

Five primitive families cover the agent spend-control surface in 2026: one-time-use cards and tokens, time-bounded JWT credentials, programmable onchain allowances (EIP-2612, Permit2, EIP-7702, EIP-3009), cryptographic mandates (AP2, Visa TAP), and real-time approval flows. Most production stacks combine two or three to balance specificity, throughput, and revocation cost.
​

The primitive layer is where most of the engineering choices live. The five categories below cover the surface as of April 2026. Most production stacks combine two or three.
​

Single-use credentials are the simplest spend control. A virtual card or payment token is created for one purchase, scoped to one merchant or merchant set, capped at one amount, and expires after use or after a fixed window. Stripe Issuing supports single-use card creation through the API; per-card controls cover per-merchant restrictions, MCC blocklists, daily/monthly caps, and country restrictions. Lithic offers the same primitive and is a founding member of the Agentic Commerce Consortium alongside Basis Theory, Skyfire, Rye, Crossmint, and Channel3.
​

OpenAI's Agentic Commerce Protocol Shared Payment Token applies the idea at the protocol layer. Instead of exposing a saved card, the buyer's payment provider issues a token bound to a specific merchant and 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. ChatGPT Instant Checkout launched on this primitive on September 29, 2025 with Etsy as the first integrated merchant.
​

Mastercard Agentic Tokens, the credential layer underneath Mastercard Agent Pay, sit in the same family with a card-network rule engine wrapped around them. Each token is tied to an agent session, bounded by user-defined permissions and per-session limits, and traceable back to the agent identity. The acceptance side rolled into the Mastercard × PayPal Agent Pay Acceptance Framework on October 27, 2025, extending the rule set across PayPal merchants.
​

The trade-off with single-use credentials is volume. A consumer agent making one purchase a week is fine; a procurement agent paying twenty invoices a day generates twenty card requests, twenty network round-trips, and twenty rows in the dashboard. Acceptable for high-value, low-frequency; impractical for micropayments — which is where the next two categories take over.
​

A time-bounded credential is a token whose authority expires on a wall-clock schedule rather than per use. JWTs with short `exp` claims and OAuth-style access tokens with refresh windows are the standard pattern. Skyfire's KYAPay credential ("Know Your Agent" pay) is a JWT carrying the agent's verified identity plus authorization claims for a specific spend scope and expiry. Skyfire raised $9.5 million from Neuberger Berman, a16z CSX, and Coinbase Ventures to build the credential layer for autonomous agents.
​

The advantage of time-bounded credentials is throughput: a 30-minute JWT lets an agent make hundreds of qualifying purchases inside its window without re-issuance, and the merchant verifies the token signature locally rather than calling the issuer per transaction. The disadvantage mirrors the advantage. The token is valid for everything in scope until it expires; if the agent goes off-policy mid-window, every transaction it sends is honored until the clock runs out or the issuing server adds the token to a revocation list. In practice, time-bounded credentials are layered with per-merchant scopes, daily caps, and server-side revocation endpoints to keep the blast radius small.
​

OAuth scopes generalize the model. A scoped access token might carry `agent.spend.usdc:max=100,merchant:openrouter,exp:2026-04-30T18:00Z`; the merchant verifies the scope claims at the gateway. Most agent-payment startups in 2026 wrap their credentials in a JWT or OAuth envelope rather than inventing a new format, since verification libraries are mature in every web framework.
​

Programmable allowances express spend controls as onchain primitives. Four standards do most of the work in 2026: EIP-2612, EIP-7702, EIP-3009, and the Uniswap-built Permit2 contract layered on top of 2612.
​

EIP-2612 defines a `permit()` function for ERC-20 tokens. The holder signs an off-chain `(owner, spender, value, nonce, deadline)` message; any caller submits it; the token contract verifies the signature and sets the allowance in the same transaction the spender uses to pull funds. No separate `approve()` is needed; the deadline scopes the allowance to a time window. DAI and native USDC on several chains implement EIP-2612.
​

Uniswap's Permit2 generalizes the pattern across any ERC-20. A user approves Permit2 once per token, then signs `PermitTransferFrom` payloads (`token, amount, deadline, nonce, spender`) per transfer. Permit2 also exposes `PermitBatch` and `lockdown()`, which revokes a list of approvals atomically. For an agent flow, the user authorizes up to N USDC by deadline T and calls lockdown if the agent misbehaves.
​

EIP-7702, activated in the Pectra hard fork in 2025, lets an externally owned account (EOA) temporarily delegate to smart-contract code. The EOA signs an authorization tuple `(chain_id, address, nonce)`; the network executes the designated bytecode at the EOA's address. For agents this enables session keys without migrating to a smart-contract wallet — the user signs a delegation giving the agent a constrained key for a defined window, then revokes by signing a new delegation pointing at `0x0`.
​

EIP-3009 defines `transferWithAuthorization`. The token holder signs `(from, to, value, validAfter, validBefore, nonce)` off-chain; anyone can submit it; the token contract validates, checks the time window, marks the nonce used, and executes. USDC implements EIP-3009; Coinbase x402 uses EIP-3009 (with Permit2 as a fallback) for HTTP 402 payment payloads. By late April 2026, x402 had processed roughly 165 million transactions across 69,000 active agents and approximately $50 million in cumulative volume per Insignia VC — almost all flowing through EIP-3009 signatures on USDC.
​

The trade-offs are concrete. Permit and Permit2 are gas-efficient and revocable but require ERC-20 permit support (or pre-approval of Permit2). EIP-7702 is general but tied to the EOA's signing key. EIP-3009 is single-use per nonce — but validBefore is the only built-in expiry, with no native cap on the number of authorizations a user signs.
​

A cryptographic mandate is a signed payload describing a transaction the user has pre-authorized. The agent presents the mandate; the merchant verifies the user's signature against the user's known public key, runs the payment, and stores the mandate as a non-repudiable receipt. The signature is the consent.
​

Google's AP2 (Agent Payments Protocol) is the named mandate spec. AP2 mandates carry merchant identity, amount, currency, expiry, and a line-item description; the user's wallet or AP2-compatible identity provider signs the payload. Visa, Mastercard, American Express, and PayPal are listed AP2 partners; UCP composes with AP2 for the payment step per Google's UCP technical overview.
​

Visa's Trusted Agent Protocol, launched October 14, 2025 with Cloudflare, signs the agent's identity into HTTP request headers. The merchant fetches Visa's directory key and verifies the signature. Early implementers include Adyen, Ant International, Checkout.com, Coinbase, Fiserv, Microsoft, Shopify, Stripe, and Worldpay.
​

Nekuda's Agentic Mandates SDK packages the primitive for application developers. Nekuda raised a $5 million seed in May 2025 (Madrona lead, Amex Ventures and Visa Ventures participating); the product combines a Secure Agent Wallet with mandate signing so applications can issue mandates without implementing AP2 or TAP from scratch.
​

The advantage of mandates is that consent and constraint travel together as one cryptographically verifiable object. The merchant can prove what the user authorized; the user can prove what the agent had permission to do. The disadvantage is friction — each mandate is a fresh user signature, and a UX requiring the user to sign every purchase shifts the flow back toward conventional checkout.
​

Real-time approval is the explicit version of consent: the agent requests a purchase, the system pushes a notification or in-app prompt, and the user approves or denies before the transaction executes. Stripe's Link Agent exposes this as a configurable mode. Per the Link Agent product page, customers can require Link Agent to approve every purchase, or set granular controls so the agent can transact within defined limits without confirmation. The control surface is the same Link account the customer uses for human checkout.
​

Mastercard Agent Pay supports a similar flow through the Agentic Tokens console. The Mastercard × PayPal acceptance framework included push-notification consent for higher-value transactions, with lower-value purchases pre-authorized inside the user's caps. Most card-network agent products converge on the same tiered model: in-rule transactions pass through, out-of-rule transactions trigger real-time approval.
​

The trade-off is latency. A push notification adds seconds to minutes depending on user attentiveness. For focused consumer shopping the latency is negligible; for a procurement agent running a hundred overnight purchases, real-time approval is impractical and the rules carry the load. The right design uses real-time approval as a fallback for out-of-rule transactions, not as the default.
​

Designing a spend-control stack starts with the use case, not the primitive. Four production patterns dominate in 2026: consumer agents on card rails, B2B procurement agents on virtual cards, machine-to-machine API agents on stablecoin rails, and treasury automation agents crossing chains. Each picks a different mix because each fails differently.
​

Picking primitives starts with the use case. Four production patterns dominate in 2026 — consumer agents, B2B procurement agents, machine-to-machine API-payment agents, and treasury automation agents — and each pulls on different primitives because they fail in different ways.
​

Consumer agents (ChatGPT shopping flows, Perplexity Comet, Amazon Buy for Me) live on card rails. The trust gradient runs from the wallet provider (Apple Pay, Google Pay, Stripe Link) through the agent to the merchant. The right stack is single-use cards or scoped Shared Payment Tokens with a real-time approval fallback. AP2 mandates layer on top for higher-value purchases. Most consumer-facing agentic payments work in 2026 sits in this pattern.
​

B2B procurement agents (renewing SaaS, paying invoices, ordering supplies) live on corporate-card rails. Stripe Issuing, Lithic, Ramp, and Brex all expose virtual card APIs; the spend-control surface is per-card limits, per-merchant restrictions, and MCC blocklists. The dominant pattern is per-vendor virtual cards plus an approval flow for any transaction outside the whitelist. AP2 plays a smaller role because the authorization graph runs through the company's procurement system, not individual user mandates. Underlying payouts often route through a B2B stablecoin payout API when vendors prefer settlement onchain.
​

Machine-to-machine API-payment agents (paying for OpenRouter inference, RPC calls, data feeds) live on stablecoin rails. A 30-cent x402 transaction can't carry interchange. The right stack is EIP-3009 or Permit2 authorizations for the underlying USDC, scoped EIP-7702 sessions for the agent key, and a server-side spend ceiling. Infrastructure choices here usually pull on a stablecoin RPC node provider for chain reads. Coinbase Agentic Wallets and Skyfire KYAPay sit at this level.
​

Treasury automation agents (cross-chain rebalancing, deposit sweeps, multi-chain payroll) cross both rails and chains. The problem is less about per-transaction caps and more about cross-chain coherence — a USDC allowance signed on Base doesn't bound an agent's authority on Polygon. Most production treasury teams compose Permit2 allowances on each chain with central policy enforced at the orchestration layer; eco.com's guide to compliance at execution time covers the pattern.
​

The comparison table below summarizes the trade-offs. Scope is what the credential covers; expiry is when authority lapses; revocability is how the user pulls it back; cost includes gas, processor fees, signatures, and latency.

Production teams compose agent spend controls by picking one primitive as the core and layering two or three more around it. Stripe Link Agent centers on virtual cards plus real-time approval; Mastercard Agent Pay on Agentic Tokens plus permission rules; Skyfire on JWT credentials; Nekuda on AP2 mandates; Coinbase Agentic Wallets on session keys plus per-token allowances.
​

Five products show how the primitives compose in production. Each ships a different mix of the categories above.
​

Stripe Link Agent (a focus of the Stripe Link Agents and x402 deep-dive) wraps Stripe Issuing virtual cards plus real-time approval into a consumer-facing surface. The agent transacts through scoped one-time tokens for in-rule purchases; a push notification triggers for out-of-rule ones. The "approve every purchase" mode requires explicit user confirmation per transaction. Link Agent shipped at Stripe Sessions 2026.
​

Mastercard Agent Pay uses Mastercard Agentic Tokens — single-session-bound, per-transaction-limited, per-merchant-scoped — gated by user permission rules. Citi and US Bank cardholders gained access in September 2025; full US rollout came in November 2025; global expansion ran through 2026. The October 27, 2025 PayPal acceptance framework added agent-aware acceptance across PayPal merchants.
​

Skyfire KYAPay is a JWT credential combining agent identity verification ("Know Your Agent") with spend authorization claims. The agent presents the JWT; the merchant verifies signature and scope claims locally. KYAPay is most often used in machine-to-machine flows where throughput rules out per-transaction signatures.
​

Nekuda Mandates SDK + Secure Agent Wallet packages AP2 mandate signing inside an agent-friendly wallet. An application calls the SDK to mint a mandate, the user signs once, and the mandate flows through any AP2-compatible merchant.
​

Coinbase Agentic Wallets (launched February 2026) expose a wallet API designed for agent custody. The SDK supports session keys, per-token allowances, and an activity log capturing every transaction with timestamp, signer, and counterparty. Coinbase's broader Agent.market, launched April 2026, uses the wallet for agent-to-agent stablecoin payments via x402.
​

The composition pattern is consistent. Each product picks one primitive as the core (single-use card, JWT, mandate, session key) and layers two or three more around it. None rely on a single primitive for all four properties — specificity, verifiability, revocability, latency — at once.
​

Audit logs and post-transaction controls catch the spend-control failures that pass authorization. Three log fields make the layer useful: agent identity attached to every transaction, mandate or credential identifier for scoped revocation, and near-real-time queryability. Revocation paths differ by rail (cancel card, registry add, lockdown call, zero-address delegation) but every production stack exposes one.
​

Most spend-control failures aren't caught at authorization time. They show up in the audit log a day or a week later, when an agent that looked fine in the rules went off-policy in a way the rules didn't anticipate. The post-transaction layer is where teams catch and contain those events; teams running large agent fleets typically pipe the log into stablecoin webhook infrastructure for real-time anomaly alerts.
​

Three fields make a log useful. The agent identity must be attached to every transaction, not just the user identity — Mastercard Agentic Tokens and Visa TAP encode it into the transaction record, and Stripe Issuing exposes per-card metadata that can carry one. The mandate or credential identifier must be attached so revocation can scope to the credential rather than the user's whole account; AP2 mandates and ACP Shared Payment Tokens both carry unique identifiers, and Permit2 allowances are addressable by `(token, spender, nonce)`. The log must be queryable close to real time — daily batch is too slow for an agent making fifty transactions an hour.
​

Revocation is the action the log enables. On card rails, revocation cancels the virtual card or removes the agent from the authorized list. On AP2 it adds the mandate identifier to the registry's revocation list before the merchant calls verify. On Permit2 it's `lockdown()`; on EIP-7702 it's signing a new delegation pointing at the zero address. The Stripe Issuing dashboard, Mastercard Agent Pay console, Coinbase Wallet activity log, and Nekuda mandate registry each expose at least one revocation path.
​

Sources and methodology. Spend-control product details verified against issuer documentation (Stripe Link Agents, Mastercard Agent Pay, Skyfire KYAPay, Nekuda, Coinbase Agentic Wallets) linked inline. EIP specifications from eips.ethereum.org. Funding figures from press releases. x402 stats from Cryptonews' April 2026 reporting. Figures refresh quarterly.
​

Eco operates at the layer below spend controls. Once a credential proves the agent is permitted to move N dollars within constraints C, Eco's stablecoin execution network across 15 chains handles routing, solver selection, and finality so the underlying funds can actually settle to the merchant or counterparty without bridging logic in the agent.
​

Spend controls operate at the credential and protocol layers. Once the agent has verified authority to move N dollars within constraints C, the question shifts to where the dollars live and how they get to the merchant — across chains, across stablecoins, and against varying liquidity. Eco operates as a stablecoin execution network across 15 chains, abstracting routing, solver selection, and finality so an agent paying in USDC on Base can settle with a counterparty whose treasury sits on Solana, Arbitrum, or Tron without writing the bridging logic. Spend-control primitives (Permit2 allowances, AP2 mandates, Mastercard Agentic Tokens) define what the agent is permitted to do; the orchestration layer makes sure the underlying funds can actually move within those limits. For teams designing multi-chain agent payment systems, stablecoin developer tooling and stablecoin compliance tools are the adjacent surfaces every serious build has to integrate.
​

A Shared Payment Token (SPT) is a protocol-level credential bound to a specific merchant and amount, traveling inside an ACP checkout call and settling via the buyer's payment provider. A virtual card is a card-network credential from a program like Stripe Issuing; the agent uses it like any other card while the issuer applies per-card spending controls. SPTs are tighter (single-use, single-merchant) but require ACP support; virtual cards work with any merchant that accepts the brand.
​

No. EIP-2612 is a token-level standard — a `permit()` function ERC-20 contracts can implement so signatures replace `approve()` transactions. Permit2 is a Uniswap-built contract layered on top: a user approves Permit2 once per token, then signs lighter `PermitTransferFrom` payloads per transfer. Permit2 also adds batch transfers, per-allowance expiration, and a `lockdown()` revoke, and tokens that don't implement EIP-2612 still work through Permit2's transferFrom path.
​

AP2 mandates are user-signed authorization payloads the agent carries through checkout; the merchant verifies the signature before charging. x402 is an HTTP payment protocol where the server returns 402 with payment instructions and the agent signs an EIP-3009 or Permit2 payload to settle. AP2 sits on the consent layer; x402 sits on the settlement rail. A real agent flow can use both.
​