Disclosure: I work on Pink Agentic AI Payments at PinkWallet, a spend-control layer for AI agents. The numbers below come from two open datasets (linked) and from the official documents cited; Pink is mentioned once, at the end, as one example.
Short answer: you stop an AI agent from overspending by putting the limit outside the model: give the agent no raw card, give each agent its own budget, check every payment at the moment it executes, send exceptions to a person (and decline if nobody answers), cap how fast it can spend, and test all of it with fake money first. A sentence like "never spend more than $50" in the system prompt is not a limit: the model can misread it, forget it, or be talked out of it by a prompt injection.
Why this matters now: in a survey of 12 popular agent frameworks, 0 of 12 document a spending budget in currency for tool calls (agent-framework-spend-guardrails), and of 37 payment MCP servers that can move money, only 4 document a spending budget and only 6 a human-approval step (payment-mcp-census). So the controls are usually yours to add.
A card number in the agent's context can be leaked, logged or reused for anything. Give the agent a tool that requests a payment instead, and only issue a credential after the request is approved: ideally single-use, locked to one payee and one amount, and short-lived.
A company-wide limit does not stop one runaway agent from using all of it. Give each agent its own monthly budget, plus a company-wide daily ceiling as a circuit breaker on top.
Approving a plan at setup is not enough: the same request can be fine on Monday and over budget on Friday. The Monetary Authority of Singapore's SAFR framework makes the same point by giving every agent action a runtime decision (MAS SAFR v1.1). Check budget, payee list and rules on the server, before the money moves.
Not every payment needs a human; the Bank of England's Sarah Breeden called a human in the loop for every agent action unlikely to be realistic (speech). Send only the exceptions: above an amount, a new payee, changed bank details, outside business hours. If nobody answers in time, decline.
A budget stops the month; a velocity limit stops the next ten minutes. Limit payments per hour or per day per agent, and block categories you never want (gift cards, crypto exchanges, gambling) outright, with no approval path.
Use a sandbox or test mode and try to break your own rules: ask the agent to split a large payment into small ones, pay a new payee, or ignore its instructions. In the census above, only 8 of 37 money-moving MCP servers document a sandbox or test mode, so check before you choose.
| Question | Good answer |
|---|---|
| Can the agent see a full card number? | No |
| Does each agent have its own budget? | Yes |
| Is the limit checked by the payment layer, not the prompt? | Yes |
| What happens if the approver does not answer? | Declined |
| Is there a per-hour or per-day cap? | Yes |
| Have you tried to make it overspend in a sandbox? | Yes |
An approval layer in front of the payment rail covers steps 1 to 5. Pink Agentic AI Payments is one example: per-agent budgets and payee rules checked on every request, answered with allowed (single-use credential), pending human (silence means no) or blocked; public sandbox with test money only, production not yet available: pinkwallet.com/agentic. Other tools in the same layer are listed in this sourced map of 33 agentic payment products.
If you want to try breaking one, there is an open overspend challenge.