Spending limits for AI agents: soft, hard and signed

The question every agent payment answers

If you're building a product in which an AI agent buys something on behalf of your customer, whether that's a hotel room, a software licence or a box of printer paper, you'll sooner or later be asked the same question by your customer, your finance team and probably your lawyer as well: what stops the agent from spending more than it should? Over the past year, almost every large name in payments has published an answer to that question, from Mastercard and Visa to American Express, Google, OpenAI with Stripe, and Coinbase, while business-spend companies such as Ramp and Mercury started handing out cards that are meant for agents only.

At first sight, these answers all look alike, because every one of them lets you set some kind of budget. Once you read the documentation, though, you notice that they put that budget in very different places, and I think that place might matter more than the size of the limit itself. A limit that lives inside the agent can be talked out of it, while a limit that lives on the card network can't, no matter what the agent was told by a web page it happened to read.

Not every bank is convinced yet, either. On JPMorgan's third-quarter earnings call this month, Jamie Dimon said the bank won't allow "just any outside agent to come inside the company", because "you don't want rogue agents". Most of what's described below is, in one way or another, an attempt to prevent an agent from going rogue.

Four places a limit can live

To compare all these systems, it helps to look at where the limit actually sits, and I count four places, going from soft to hard.

The first is the agent's own instructions, where you simply tell it not to spend more than a certain amount. That works most of the time, but it's also the easiest place to break, because the agent reads everything it comes across, including text that someone wrote to change its mind. The second is the platform or wallet the agent runs in, which can refuse a payment above a certain amount before it leaves your system. The third is the payment credential itself, a card or token with the limit attached to it, which the card network or the issuer checks whenever the agent tries to pay. The fourth works a bit differently, because it doesn't limit how much the agent spends so much as what it buys, by keeping a signed record of what the customer actually asked for and checking the purchase against it.

The card networks put the cap on the card

The clearest example of the third layer comes from Mastercard. In August, Mastercard put what it calls Token Spend Controls into production, which lets the bank that issued the card set spending rules on the tokens used by Mastercard Agent Pay and its virtual card tokens, after the cardholder has authenticated. The list of rules is quite extensive: a maximum per transaction, a daily, weekly and monthly limit, a lifetime cap the token can never go above, a single-use setting after which the token stops working, and lists of merchants, merchant categories and countries that are allowed or blocked. According to Mastercard's own release notes, it evaluates every tokenized transaction against these rules and declines the ones that break them, which means the agent never even gets a say in the matter.

Visa describes something similar for its Intelligent Commerce programme, with spending limits, approval workflows and authentication requirements built into the credential, although Visa's own product page still says the product is being deployed and that the final version may not contain every feature described. Ramp's agent cards, which are in early access, are a concrete example of it: every card is a single-use Visa token, scoped at the network level, locked to one merchant and capped per transaction.

Proving what the customer asked for

A limit on the amount doesn't help much if the agent spends exactly the right amount on the wrong thing, and that's precisely the gap the fourth layer tries to close. On 13 October, American Express presented its Intent Intelligence Framework, in which the customer's instructions and constraints, such as the merchant, a maximum budget and product preferences, are recorded first and then approved by the customer. That approval produces an Intent ID and a token holding the constraints, which the agent then uses to get a payment credential at checkout, so the agent never sees the actual card number. Amex's own example is a customer who asks for white Nike sneakers in size 9, where the agent tries to buy Adidas instead, and Amex could block that payment before it goes through. Amex hasn't said when or for whom this will be available, though.

Google's Agent Payments Protocol (AP2), first announced in September 2025, is built on the same idea, using signed records that it calls mandates. A Checkout Mandate records what is being bought and a Payment Mandate authorises the payment with a specific card or account, and both come in two stages. The open version holds the user's constraints and goals, such as a budget and the payment methods the agent may use, before there's anything in the cart, which is what lets an agent complete a purchase on its own once those conditions are met. The closed version then authorises one specific, final checkout. Because these records are signed and tamper-evident, they form a trail you can follow back when a customer disputes a payment.

Checkout inside a chat: one-time allowances

For checkouts inside ChatGPT, OpenAI published a Delegated Payment Spec, and Stripe's Shared Payment Token was the first implementation of it. In this set-up, the agent's platform creates a token for a single seller, with a currency, a maximum amount and an expiry date, the token can be used only once, and it can be revoked at any moment, after which the seller can no longer use it to take a payment. Stripe's documentation also says it may use Mastercard Agent Pay or Visa Intelligent Commerce tokens behind the scenes.

What I'd keep in mind as a product team is who sets the maximum here. According to Stripe's documentation, it's the agent's platform that sets the usage limits when it creates the token, usually at the total of the checkout, rather than the customer setting a budget of their own. That's a perfectly reasonable design for a single purchase, but it does mean the customer's budget has to be enforced somewhere else, which brings you back to the question of where.

Paying per request: x402 and agent wallets

Card payments are built for amounts of a few euros or dollars and up, while many agents pay for something much smaller, such as one request to a data service. x402, an open protocol from Coinbase, lets a server answer a request with the HTTP status 402 Payment Required, after which the agent pays in stablecoins and gets the response. Chainalysis counted more than 138 million payments over x402 on Coinbase's Base network, and more than 87% of them were between $0.0001 and $0.10.

At those amounts, a limit per payment doesn't tell you much, which is why Coinbase's Agentic Wallet works with a maximum per call and a maximum per session, both set by the person who funds the wallet in the wallet's own interface. According to Coinbase's documentation, agents respect these limits and can't change them, and they can only pay for x402 services rather than send money to any address they like.

A card of its own: Ramp and Mercury agent cards

For a company that wants to let an agent buy something today, a card that belongs to that agent alone is probably the most practical option. Mercury launched agent cards in August as part of Mercury Spend, and what I like about its design is how clearly it separates what the agent can do from what only a person can do. Through Mercury's API, an agent can retrieve the details of a card assigned to it, but it can't create an agent card, change its limit or unfreeze it, and when you freeze or cancel the card it takes effect right away, without the agent being able to undo it. Ramp's agent cards, described above, work along the same lines, with one card per agent and per transaction.

When you put all of these systems side by side, the difference that stands out most is not the size of the limit but who gets to set it, and whether the agent can change it afterwards.

What a cap can't see

All of these limits do one job very well: they put a ceiling on the damage. What they can't do is judge whether a purchase makes sense. An agent that buys the wrong software licence within its budget has stayed within every rule, and a card limit won't notice.

That's also where the soft layers turn out to be weaker than they look. In a paper published this year, two researchers built a shopping agent on Google's AP2 and showed that simple prompts hidden in what the agent reads could reliably change its behaviour, for example by pushing a certain brand to the top of its results or getting it to give away the user's data. The signed records and network limits still hold in that situation, but the agent's own judgment doesn't, which is exactly why the hard limits have to sit outside of it.

Questions to ask your payment partner

If you're building a product in which an agent pays, these are the questions I'd take into the first conversation with a payment partner, in roughly this order.

1. Who sets the limit: your customer, your platform or the agent itself? If the agent can set or change its own limit, it isn't really a limit.
2. Where is it enforced? Ask whether it's checked by the card network or the issuer, by the partner's platform, or only by the agent's instructions.
3. Which kinds of limit exist: per transaction, per day, week or month, a lifetime cap, single use, and a list of allowed merchants or categories?
4. Is there a record of what the customer asked for, and is the purchase checked against it, or only against the amount?
5. How fast can you stop the agent, and can the agent undo that? You should be able to freeze or revoke a credential in seconds, without the agent being able to reverse it.
6. What ends up in the log for each payment: which agent paid, on whose instructions, and within which limit?
7. Is it live, in preview or still being deployed? Several of the systems above are in early access or preview, so check what you can actually use today.

If a partner can answer the first two questions clearly, the rest of the conversation tends to go a lot more smoothly as well.

This article is for information and education only and is not financial, legal or investment advice.

This article is information and commentary. It is not investment advice, not a personal recommendation and not investment research, it takes no account of your circumstances, and it must not be relied on as a reason to trade. Any figure shown is historical or simulated and is not an indication of future results.

All reports →