How do you set spending limits for an AI agent?

Where can a spending limit actually live?

Five layers, weakest first.

The prompt. You write "never spend more than 200 dollars" into the system message. Nothing checks it. The model treats the instruction as context, and over a long enough run, as context it can be argued out of.

The agent's own code. A function totals the basket before it calls the payment API. This is real enforcement, and it holds for exactly as long as every route to that API runs through that function.

The mandate. The user signs a statement of what the agent may do, and the payment side compares the purchase against it before authorising. The agent has stopped being the party that decides.

The credential. The card the agent holds is not the user's card. It is a token minted with a spend ceiling, a merchant scope and an expiry attached, and the network declines anything outside them.

The rail. The payment system caps the delegated spender itself, regardless of what the four layers above it agreed.

The useful property of the lower layers is that the party enforcing the limit is not the party being limited.

Why is a limit in the prompt not a limit?

Because you have asked the thing being constrained to apply the constraint. There is no step at which anything else checks the instruction was honoured, and the system you asked is one that produces plausible continuations.

The version of this I have actually watched fail is duller than a jailbreak. On my own pipeline earlier this month I reviewed a safety configuration naming forty-five checks. Seventeen resolved to nothing: the names sat in the config file, the functions were not in the codebase, and the suite reported green, because a check that is missing is not a check that fails. One banned-word list shipped without the two most obvious words in its own category. The test fixture had them, the shipped file did not, and every test still passed.

No component in that run was lying to me. Each one reported accurately on what it could see, and the limit had simply never been wired to anything, which is what makes this class of failure survive review. The review reads the same file the limit was declared in.

So the check worth running is mechanical. Name the component that returns an error when the limit is breached, then trigger that error deliberately. If you cannot make it fire, you have not established that it exists.

What does a signed mandate constrain?

Google published the Agent Payments Protocol on 16 September 2025 with more than sixty payments and technology partners behind it (Google Cloud, CMSWire). Its answer to the authority problem is the mandate, a cryptographically signed record of what the user agreed to, which travels with the transaction.

For a delegated task the user signs an Intent Mandate up front. Google's own description says it specifies "price limits, timing, and other conditions", and its worked example is a trip booking with a total budget of 700 dollars. When the agent later assembles a basket, a Cart Mandate pins those items at that price, so the merchant sees a signed approval of an exact amount rather than an agent's account of its own authority.

What a mandate adds over in-agent code is a check performed by somebody else. The merchant and the payment network can each verify the signature and test the cart against the constraints without taking the agent's word for anything. The limit becomes evidence.

Its scope is narrow. A mandate covers one delegated task, which is not the same thing as a monthly budget across every agent you run (how AP2 differs from ACP).

What can the payment credential enforce?

At this layer the limit stops depending on protocol adoption. It depends on the card network, which declines transactions for a living.

Visa's Intelligent Commerce puts the controls in the credential. Visa describes agentic commerce enabled through "spending limits, approval workflows, authentication requirements and trusted identity signals", with the agent handed a tokenised credential rather than a card number, and the platform confirming the agent is inside the consumer's instructions before that credential reaches the merchant (Visa, VentureBeat).

Mastercard announced Agent Pay on 29 April 2025, naming Microsoft, IBM, Braintree and Checkout.com. Its Agentic Tokens build on the tokenisation already running contactless and card-on-file payments, and Mastercard's own claim for them is that consumers "will have complete control over what the agent is allowed to purchase on their behalf", alongside agent registration and verification (Mastercard, PYMNTS). The press release does not publish the control set, so what a cap can express in practice is a question for whoever issues you a token.

The operational gain here is revocation. When a token belongs to one agent, you can stop that agent spending without reissuing the card or disturbing any other integration. A limit you can withdraw in one place at three in the morning beats a stricter limit spread across four systems.

What do the rails cap underneath all of this?

There is usually a ceiling below whatever you negotiated, set by the payment system, and it does not ask your permission.

India's UPI Circle is the clearest live example of delegated spending with hard caps. A primary user delegates payment authority to a secondary user, and under NPCI's rules that secondary user is capped at 5,000 rupees per transaction and 15,000 rupees a month, whether the delegation is full or partial (Razorpay, Ujjivan Small Finance Bank).

Those numbers were written for a family member without a bank account rather than for software. India has been reported as preparing a Unified Agent Protocol to extend delegated UPI payments to AI agents under rules the user sets, possibly presented at the Global Fintech Fest running in Mumbai from 8 to 11 September 2026 (Free Press Journal, IBTimes; dates per Global Fintech Fest and Vajiram & Ravi). NPCI has published no limits for it and has not confirmed the framework, so the shape is reported rather than settled.

The general point holds whatever India announces. Find out what the rail already refuses before you design a budget on top of it, because a 200,000 rupee mandate on a rail that stops at 5,000 rupees a payment is not a 200,000 rupee mandate.

What should you do first?

Write down where each limit lives, one line each, before writing any code.

Most agent budgets I have seen described exist in two places at once and are enforced in neither: a number in a prompt, a number in a config file, and nothing that returns an error when either is breached. Naming the enforcing component for each limit takes an afternoon, and it usually deletes half of them, because half turn out to be the same number written twice.

Then push each limit as far down the stack as it will go. If the credential can hold it, the credential should hold it, because that layer keeps working when the agent is wrong, compromised, or running code you never reviewed. Everything above the credential is a control you are asking the agent to apply to itself (and who carries the loss when it gets it wrong).