How to Set Per-Agent Spending Limits for an AI Agent (MCP, Cards, Wallets): Field by Field

Short answer: Setting a spending limit for an AI agent means making three decisions, in order: (1) where the cap actually lives — a card network, an onchain wallet, a provider's API/CLI, or a policy layer in front of the MCP tool the agent calls; (2) whether it's a per-transaction ceiling, a rolling-window total (daily/weekly/monthly), or both, since most providers that support both also enforce an ordering rule between them; and (3) what happens on breach — a hard decline at authorization time, or a routed-to-human approval step. Below is the exact field or flag each provider documents for this, with its unit and its enforcement point, plus the parts of the setup that are easy to get wrong.

Last updated: 2026-09-30. Facts below are drawn from the Agent Spending Controls Crosswalk (CC BY 4.0), a 43-row dataset we publish and re-verify against each provider's own docs. Every evidence URL in this article was re-fetched and every quote re-checked mechanically on 2026-09-30 — see the sources-check file linked at the end.

Step 1: choose where the limit is enforced

A "spending limit" is checked at a different layer depending on the rail:

  • Card network, at authorization. Stripe Issuing, Privacy.com, Lithic, and AgentCard issue virtual cards whose limits are checked by the card network before settlement — the transaction never moves money. It only covers card-rail spend: an agent holding a separate wallet key isn't touched by a card limit. Crossmint's docs draw this line explicitly: "Card limits hold at Visa and Mastercard, wallet limits hold onchain" (docs.crossmint.com/agents/overview, accessed 2026-09-30).
  • Onchain, via a precompile. Tempo's Account Keychain enforces per-key token limits at the protocol layer, inside KeyRestrictions/TokenLimit structs (tempo.xyz, accessed 2026-09-30) — the hardest layer to bypass, but scoped only to the chain/token the key covers.
  • Provider API or CLI, server-side. AP2's BudgetEvaluator, Circle's agent-wallet CLI, and Payman's dashboard policies check the cap in the provider's backend. Flexible, but only as trustworthy as that backend — an evaluator bug can mean the check silently doesn't run (see the AP2 gotchas below).
  • MCP-tool layer, in front of execution. A policy check between "the agent decided to pay" and "the call fires," independent of the underlying rail. Coinbase's CDP Agentic Wallet MCP integration sets a per-call and per-session cap in its wallet UI, and its FAQ states "Agents respect these limits but can't change them" (docs.cdp.coinbase.com, accessed 2026-09-30).

None of these four is strictly better — they stop different failure modes. The practical answer is usually to stack at least two: a hard cap at the rail (card or onchain) as the floor, plus a policy layer above it for allowlists and approval routing.

Step 2: set the cap — exact fields by provider

This is the part most guides skip. Below is the field or flag each provider documents, as published on their own site.

Provider Per-transaction field Per-period field (period options) Unit Enforced where
Stripe Issuing spending_controls[spending_limits][0][interval]=per_authorization spending_controls.spending_limits[].amount + .interval (per_authorization plus date-based intervals) Smallest currency unit of the card currency Card network, at authorization
Privacy.com spend_limit with spend_limit_duration=TRANSACTION spend_limit + spend_limit_duration (ANNUALLY, FOREVER, MONTHLY, TRANSACTION) Cents Card network, at authorization
Lithic (cards) — (spend_limit_duration=TRANSACTION is the closest per-tx equivalent) spend_limit + spend_limit_duration (ANNUALLY, FOREVER, MONTHLY, TRANSACTION) Cents (industry convention; not restated on this page) Card network, at authorization
Lithic (accounts) — Account-level limits (daily, monthly, lifetime) Not stated in this excerpt Card network, at authorization
Lithic (Velocity Limit rule) — limit_amount (max total spend in the period; also limit_count for a transaction-count cap), scope CARD or ACCOUNT Cents Card network, at authorization (Lithic-hosted Auth Rules engine)
AgentCard — cards set-limit CLI command sets a multi-use card's total limit Cents Provider API
Coinbase CDP (Agentic Wallet MCP) "Max per call" (wallet UI; no documented API field name) "Max per session" (wallet UI) Not stated (USD examples: $0.05 / $5.00) MCP/wallet-UI policy
Circle (Agent Wallets CLI) No separate per-tx flag; --daily is the shortest tier --daily / --weekly / --monthly (circle wallet limit set) USDC (major units) Provider CLI, Circle's wallet backend
Tempo (--max-spend CLI flag) --max-spend (per request) — (per-request only at this layer) Not stated (examples in dollars) Client-side CLI
Tempo (Account Keychain, protocol) TokenLimit.amount with period=0 TokenLimit.amount with period in seconds (recurring) TIP20 token units Onchain, via the Account Keychain precompile
Payman (Dashboard Policies) "Per Transaction" — "Maximum amount allowed per single payment" "Daily Limit" / "Monthly Limit" Not stated (currency-agnostic in the docs) Payman's policy engine ("financial firewall")
Skyfire (KYA-PAY token) amt claim — "JSON string representing token amount in currency units" — (per-token cap only; mnr caps request count, not amount, under pay_per_use) Currency units (not minor units) API server-side, validated by the seller service before settlement
AP2 (Agent Payments Protocol) amount_range.max — "Maximum allowed amount in minor (cents) unit of currency" budget.max — "Maximum amount for the budget" amount_range.max: minor units (cents). budget.max: major units — the reference SDK's BudgetEvaluator multiplies it by 100 internally API server-side (BudgetEvaluator/AmountRangeEvaluator in the reference SDK)
x402 (upto scheme) amount in PaymentRequirements — the client-authorized maximum for a metered request — (per-request ceiling; no rolling-window field documented) Not stated in the spec file API server-side, enforced by the facilitator at settlement

Two rows deliberately have no documented field name: Visa Intelligent Commerce and Mastercard Agent Pay both describe spend limits in marketing language ("agent permissions and spending limits are defined upfront to bound authority" — Mastercard, Wayback snapshot 2026-09-18) without a public API reference naming the parameter, as of 2026-09-30.

One gotcha worth flagging before you copy any of the above into code: AP2's budget.max and amount_range.max are not in the same unit, despite sitting in the same mandate schema. amount_range.max's schema text states "minor (cents) unit of currency" directly; budget.max's schema text gives no unit at all, and the reference SDK computes budget_max_cents = int(self.constraint.max * 100) — meaning budget.max must be supplied in major units, the opposite of what the sibling field's name suggests. This is a documented, unresolved discrepancy — see our AP2 mandate gotchas piece.

Circle's ordering rule is worth quoting directly: limits "must be monotonic: per-tx ≤ daily ≤ weekly ≤ monthly" (Circle agent-wallet-policy skill, accessed 2026-09-30) — the CLI rejects a per-transaction cap set above the daily cap.

Step 3: add approvals and allowlists

A hard cap answers "how much" — not "who" or "what happens right at the edge." Three providers document both:

  • Circle requires a human-entered one-time code to raise or reset a limit at all: "Setting or resetting limits requires OTP confirmation in an interactive terminal session" — the agent itself never sees that code. It also documents recipient allowlists and contract blocklists: "Set transfer limits, recipient allowlists, and contract blocklists per agent wallet" (developers.circle.com/agent-stack/agent-wallets, accessed 2026-09-30).
  • Payman documents a distinct "Threshold" control, separate from the daily/monthly caps: "Amount above which manual approval is needed" (Payman Dashboard Policies, Wayback snapshot 2025-11-18) — the payment is routed to a human, not blocked outright.
  • AP2 builds approval into the protocol: a user's "approval signs a Cart Mandate. This is a critical step that creates a secure, unchangeable record of the exact items and price" (Google Cloud, AP2 launch post, accessed 2026-09-30).

Merchant/category allowlisting shows up on the card side too: Privacy.com's card type enum includes MERCHANT_LOCKED and SINGLE_USE; Lithic's Authorization Rules include a MERCHANT_LOCK rule type and a CONDITIONAL_ACTION rule keyed on merchant category code (MCC) — "by defining rules based on high-signal attributes like MCC, country, currency, and risk score, you can enforce business-specific authorization logic" (docs.lithic.com/docs/authorization-rules-v2, accessed 2026-09-30). Stripe Issuing exposes the same idea as allowed_categories/blocked_categories.

A limit on all of this: an allowlist or approval rule is only as good as the layer evaluating it. AP2's reference SDK evaluates a constraint only if it's present in the array the caller submits — a withheld constraint produces no violation, because there's no evaluator to run against it. Confirm a constraint is actually sent on every call, not just configured once upstream.

Step 4: test the limit before you trust it

Two checks are worth doing before you ship an agent against a real cap, regardless of provider:

  1. Send a transaction just above the cap and confirm it's declined, not just logged. Card-network and onchain enforcement (Stripe, Privacy.com, Lithic, Tempo's Account Keychain) reject the authorization itself. Provider-API enforcement (AP2, Circle, Payman) depends on that backend running the check on the exact code path your agent uses — a cap set in a dashboard doesn't help if the API call bypasses that policy engine.
  2. Confirm which unit the number you typed actually means. AP2 is the documented case: amount_range.max is minor units (cents), but budget.max is major units the evaluator multiplies by 100 internally — set budget.max as if it matched amount_range.max and the effective ceiling is 100x too high. Read the field's own documented unit; don't assume it matches a similarly named sibling.

Where a rolling-window and per-transaction cap coexist (Circle, Stripe, Privacy.com, Lithic), test the boundary case: a transaction at exactly the per-transaction cap, on a day the rolling total is already close to the daily/monthly cap — that's where an off-by-one or unenforced ordering rule surfaces.

Gotchas

  • "Not documented" is common at the marketing layer. Coinbase CDP's TEE/enclave enforcement claims, Visa Intelligent Commerce, and Mastercard Agent Pay all describe spend limits in prose without a public field-level schema. A blog post mentioning "spending limits" isn't the same as an API reference naming the parameter.
  • x402's amount field is phase-dependent in the upto scheme. The same JSON field means "client-authorized maximum" at verification time and "actual amount to charge" at settlement — "the settled amount MUST be less than or equal to the authorized maximum" (x402 upto scheme spec, accessed 2026-09-30).
  • x402's maxAmountRequired (the exact scheme) is a price the resource server sets, not a payer-side budget — the transaction must equal that exact value. A payer-side cap has to live in the client or wallet, not this field.
  • AP2's unit mismatch is a live, unresolved discrepancy, not a one-off — see Step 2 and the crosswalk's Gotchas section.
  • Circle's OTP requirement is deliberate agent-exclusion, not a bug: raising a limit needs a human at an interactive terminal, specifically so an agent can't raise its own ceiling.

Everything above covers the caps, allowlists, and approvals a provider documents in its own reference material — not how much an agent may spend across providers, which is a policy question above any single vendor's API. See our spending controls guide and policy template for that layer.

Pink Agentic AI Payment (early access) enforces per-agent spending caps, allowlists and approval thresholds at the MCP layer, before a payment executes.

FAQ

How do I set per-agent spending limits for an AI agent that pays through MCP? There's no single MCP-standard field — each MCP-connected provider documents its own. Coinbase's CDP Agentic Wallet MCP integration sets a "Max per call" and "Max per session" cap in its wallet UI, and its docs state the agent "can't change them." Stripe Issuing, Privacy.com, and Lithic can also sit behind an MCP tool, but the limit itself lives in their card API (spending_controls, spend_limit) — MCP is just the calling interface.

How do I give an AI agent its own wallet and spending limits? Three documented patterns: Coinbase's CDP Agentic Wallet gives an agent a dedicated wallet with a UI-configured per-call/per-session cap. Circle's Agent Wallets CLI issues a wallet with --daily/--weekly/--monthly USDC limits via circle wallet limit set, enforced with a monotonic ordering rule and an OTP requirement to change them. Tempo's Account Keychain enforces the limit onchain, at the protocol layer, via a TokenLimit struct scoped to the agent's access key.

Which payment MCP servers have built-in spending controls? Coinbase's CDP Agentic Wallet documents MCP-specific per-call and per-session limits directly. Stripe Issuing, Privacy.com, and Lithic document MCP servers or MCP-compatible integrations sitting in front of their existing card-level controls — the control lives at the card-API layer, with MCP as the calling interface. We did not find a documented MCP server, as of 2026-09-30, enforcing a cap purely at the MCP protocol layer independent of an underlying card or wallet API.

Do these limits stop overspend, or just alert someone after the fact? Card-network or onchain enforcement (Stripe, Privacy.com, Lithic, AgentCard, Tempo) declines the authorization before funds move — a hard stop. Provider-API or wallet-UI enforcement (AP2, Circle, Payman, Coinbase CDP) is only as reliable as that specific code path being the one your agent calls — test it directly (Step 4) rather than assume a dashboard setting is enforced everywhere.

Related reading

This guide is published by PinkWallet, which is building Pink Agentic AI Payment (early access). We are not neutral in this space, which is why every factual claim links to a primary source.