Mastercard added Token Spend Controls for Agent Pay and virtual card tokens. What limits can be set on an agent's payment token, who sets them, how are they enforced, and what do I still have to build myself as an AI agent developer?

What should I check, step by step?

1. Ask your issuer or card-issuing platform whether it supports Mastercard Token Spend Controls for the tokens your agents use, which rule types it exposes, and whether the cardholder or your platform can set them through its app or API. The release notes make support optional for issuers.

2. Set the tightest token rule that fits the task: single use with a short expiry for one purchase; a per-transaction limit plus an absolute lifetime limit for a recurring job; weekly or monthly limits only where the job really repeats.
3. Lock the token to where the agent should buy: a merchant ID allowlist for a known seller, or merchant category codes and geography for a class of sellers. Block lists are useful for categories the agent should never pay, such as gambling or cash-like transactions.
4. Find out from the issuer how daily, weekly and monthly windows are counted (time zone, calendar boundaries) and how foreign-currency amounts count against a limit. The release notes say calendar week and calendar month but don't define the day boundary or currency handling.
5. Keep the rule-changing step away from the agent. Rules are created and updated after cardholder authentication; if the agent can reach that authentication (an emailed code, a signed-in banking session), it can widen its own token.
6. Check each purchase against your own policy before the agent pays: task, quote, merchant, running total across every card and rail the agent uses. The token can't see your other tokens, your stablecoin wallet or your budget for the task.
7. Handle declines on purpose. A token-rule decline means the purchase is outside what was set; the agent should stop and report it, not retry, split the charge or switch to another payment method.
8. Record which token, rule set and limit each purchase ran under, so a dispute or audit can match the charge to what was allowed at the time.

What limits can Mastercard Token Spend Controls put on an Agent Pay or virtual card token?

Mastercard's MDES Customer Service release notes for July 2026 introduce Token Spend Controls APIs. Issuers enabled for the Mastercard Virtual Card Token (MVCT) and Mastercard Agent Pay programs can define token-level spending rules, and Mastercard evaluates each tokenized transaction against them and declines those that violate them. The notes list the MTF test date as July 29, 2026 and production as August 5, 2026, with the functionality available globally.

• Spend-limit controls: Daily Spend Limit; Weekly Spend Limit (a calendar week); Monthly Spend Limit (a calendar month); Transaction Limit (one transaction); Single Use Control (one-time use with an expiration date; after the first successful non-zero transaction the token can't be used again); and Absolute Spend Limit (a cumulative cap the token can't exceed over its lifetime).
• List-based controls, as allow lists or block lists: Acceptor Business Code (merchant category code), Merchant ID, Transaction Category Code, Transaction Type and Geography. The notes describe them as usage control beyond card or account-level settings, so one card account can carry differently restricted tokens for different agents or tasks.

Who can set Mastercard Token Spend Controls on an AI agent's token, and does every issuer support them?

The four APIs are search, create, update and delete token spend controls, and they sit in MDES Customer Service, which is for issuers and their customer service. In Mastercard's flow the cardholder logs in to the issuer's app, and the issuer creates, updates or deletes rules after cardholder authentication. An agent developer doesn't call these APIs directly; they come to you, if at all, through the issuer or the card-issuing platform you work with.

• The impact section says issuers can optionally support the new APIs once they are in production. So the same Agent Pay token can have rich network-side limits at one issuer and none at another. Ask before you rely on it.
• Enforcement is on the network side: the rule is evaluated against each tokenized transaction and a violating one is declined. That's the strongest place for a hard cap, because instructions the agent reads, or a bug in your own code, can't move it. New error codes cover a rule that doesn't exist for the token, a token that can't be found and a rule that already exists.

What doesn't a card-network token spending limit protect against when an AI agent pays?

It limits amounts and places, not purchases. A charge for the wrong item at an allowed merchant under the limit passes every rule. Records of what the customer actually asked for are a different layer; Mastercard's own Agent Pay work points to its Verifiable Intent for that, and protocols like AP2 carry signed mandates.

• It sees one token. An agent that pays with several cards, a stablecoin wallet and an x402 client has a separate limit on each and no shared budget unless you keep one. Your own check, before the agent pays, is where a task or fleet budget lives.
• It protects the rules only as well as the authentication that changes them. If the agent can complete the cardholder's authentication, it can ask for a wider token. Keep that step with a person, on a channel the agent can't read.