Spend Controls for AI Agents: Caps, MCC Locks, and Approval Ladders

An AI agent that can spend money is only as safe as the controls wrapped around it. Spend controls for AI agents are the difference between an agent that quietly renews a server and an agent that empties an account. We build both sides of that line at Meow, and we have a firm view on where it should sit.

The view is simple. The agent should start with zero ability to move money. Every dollar it can spend should be a capability you turned on, with a cap, a category, and a human on the other end of anything that matters. This post lays out the primitives and hands you a config you can copy.

Why the Dashboard Model Breaks When the Agent Is the Operator

For twenty years, spend controls assumed a person. A finance manager sets a card limit in a dashboard, hands the card to an employee, and trusts the employee to behave. The control is a fence. The person is expected to stay inside it and to bring judgment the fence never encodes.

An agent does not carry that judgment. It has a prompt, a set of tools, and a context window that can be poisoned. It can be talked into things. It can loop. It can misread one instruction and place the same order forty times before anyone glances at the screen. The employee model assumed a slow, self-correcting operator. The agent is fast and does not self-correct unless you force it to.

So the dashboard control that worked for a person becomes the only thing standing between an automated operator and your balance. That raises the bar. The fence has to be higher, tighter, and enforced somewhere the operator cannot reach. Configuring a limit in a UI and hoping the model respects it is a suggestion, not a control.

The Primitives of Spend Controls for AI Agents

There are six primitives worth knowing. Get these right and most of the risk drains out of the problem.

Per-agent spend caps: Every agent gets its own daily cap and its own per-transaction cap. The daily cap bounds the damage over time. The per-transaction cap bounds a single mistake. An agent cleared to spend two thousand dollars a month with a two hundred dollar per-transaction ceiling cannot move your payroll to a stranger, no matter what its context window has been convinced of.

MCC restrictions and merchant whitelists: A merchant category code (MCC) is a four-digit label the card networks attach to every merchant. Software, airlines, restaurants, and cash-adjacent businesses each carry their own codes. Lock a card to a set of MCCs and it declines everywhere else. Tighter still is a merchant whitelist, where the card works at the specific merchants you named and nowhere else.

Approval ladders and thresholds: Not every action deserves the same friction. Small, in-category spend can clear on its own. Anything above a set amount, or outside the allowed categories, routes to a human for a yes or a no. The ladder maps dollar amounts and risk to the level of human involvement required, so routine work stays fast and unusual work stops for review.

Isolation between agents: One agent's permissions should never bleed into another's. Each agent gets its own credentials, its own caps, and its own scope. If one is compromised or starts misbehaving, you freeze that one without touching the rest of your operation.

Network-level enforcement: A cap that lives only in your application logic can be sidestepped by anything that talks to the payment rail directly. A cap enforced at the card network declines the transaction before it settles, regardless of what is asked for it. This is the line between control and hope.

Audit log: Every agent action, every approval, every decline, recorded with the agent's identity, the amount, the merchant, and the outcome. When something looks off, you want to answer which agent, when, and how much in seconds, not reconstruct it from a stack of statements.

Enforce at the Network, Not in the Prompt

This is a load-bearing idea, so I will say it plainly. You cannot enforce a spend control by asking the model to follow it.

Prompts are instructions, not permissions. A system prompt that says never spend more than two hundred dollars is guidance the model can be pushed past. A confused or adversarial input can override it. Prompt injection is a real class of attack, and the entire point of an injection is to make the model ignore the rule you thought you had set.

Real enforcement sits below the model. The cap, the category lock, and the approval threshold live on the payment rail, at the card network and the issuer. When the agent tries to spend, the network checks the rule and approves or declines. The model does not get a vote. It can ask. The rail decides.

That inversion is the whole game. Trust the model to be useful, and do not trust it to be safe. Put the safety somewhere the model cannot edit.

MCCs help here because they are standardized and applied at the network, not by the agent. The codes follow an international standard, ISO 18245, and the card networks publish their own mappings on top of it. The US government maintains a public list you can read to see how granular the categories get IRS Merchant Category Codes, because the codes are standard and enforced on the rail, an MCC lock is carried out by the same infrastructure that clears the payment.

How Meow's Agent Spend Model Works

Here is how we built it.

By default, a Meow agent can move zero dollars. It can read balances and prepare actions, but it cannot send a wire, run an ACH, or issue a card until you say so. Nothing is on until you turn it on.

The account holder turns on each capability explicitly. Wires on or off. ACH on or off. Card issuance with a daily cap and a per-transaction cap that you set. Each toggle is a deliberate act by a human, not a default you have to remember to switch off.

Every agent-initiated action that needs a person goes to a person. Approvals reach you through Claude, SMS, Telegram, or the Meow dashboard, whichever you actually use. The agent proposes. You approve or decline from wherever you are.

The model never sees your account and routing numbers. Those credentials stay out of the context window entirely, so a leaked prompt or a compromised session cannot exfiltrate them. The agent works through a scoped interface, not through your raw banking details.

Caps are enforced at the network level. When a card is capped at two thousand dollars a month and locked to software categories, that limits lives on the rail. A transaction that breaks it declines at the network, before it settles, no matter what the agent believed it was doing. On top of that, every transaction runs through the partner bank's BSA/AML and OFAC screening, the same as any other payment on the platform.

We connect agents through an MCP endpoint, live today for Claude, ChatGPT, Cursor, and Gemini. The Model Context Protocol is the open standard that lets those clients call the tools we expose, always inside the permissions you set.

A Concrete Config: A 2,000 Dollar Software Card

Abstract controls are easy to nod along to. Here is one you can actually set up.

Say you want an agent that manages your SaaS subscriptions and cloud bills. Nothing else. Here is the config.

The card: One virtual card, issued to a single agent, with a two thousand dollar monthly cap and a five hundred dollar per-transaction cap. The monthly cap bounds the total. The per-transaction cap means one bad call costs at most five hundred dollars, not two thousand.

The category lock: Lock the card to software and cloud MCCs. Codes such as 5734 (computer software stores) and 7372 (computer programming and data processing services) are in. Everything else declines. The agent could be talked into buying something odd, and the network would still refuse because the merchant is not in an allowed category.

The approval rang: Anything above five hundred dollars, or any attempt to charge a merchant outside the allowed categories, pauses and pings you on Telegram. You approve the annual plan that exceeds the per-transaction cap. You decline the charge you never expected.

The isolation: This agent gets this card and nothing else. It cannot touch wires, it cannot run ACH, and it cannot see the balance of any other account. Spin up a second agent for ad spend and it gets its own card, its own caps, and its own category lock.

That is a complete, safe agentic spend setup in four decisions. Total exposure if everything goes wrong: two thousand dollars a month, capped, categorized, and logged.

Rolling Out Agent Spend Without Getting Burned

A few rules we would give any team turning this on.

Start narrow: Give the agent one card, one category, and a low cap. Widen only after you have watched it behave for a cycle. Raising a limit is easy. Explaining a charge you did not expect is not.

Set the per-transaction cap below the daily cap: A daily cap on its own still lets one transaction swallow the whole day's budget. The per-transaction ceiling is what turns a single mistake into a small mistake.

Keep the destructive rails off: Most agents doing useful work only need to buy things on a card. They do not need to send wires. Leave wires and ACH off unless a specific job requires them, and switch them off again when the job is done.

Read the log weekly: The audit trail only helps if someone looks. Five minutes a week reading what your agents actually spent will teach you more about your setup than any amount of planning up front.

Frequently Asked Questions

What are spend controls for AI agents? Spend controls for AI agents are the caps, category locks, approval rules, and enforcement mechanisms that bound what an autonomous agent can spend. The core primitives are per-agent daily and per-transaction caps, MCC restrictions or merchant whitelists, approval thresholds that route large or unusual actions to a human, isolation between agents, network-level enforcement of every limit, and a full audit log.

Why can I not just tell the agent its spending limit in the prompt? Because a prompt is an instruction, not a control. A model can be confused, looped, or deliberately manipulated through prompt injection into ignoring a rule in its system prompt. Real spend controls are enforced below the model, at the card network and issuer, where the model cannot edit them. Keep the useful work in the model and put the safety on the rail.

What is an MCC and how does it restrict agent spending? A merchant category code (MCC) is a four-digit code the card networks assign to every merchant to describe what it sells, following the ISO 18245 standard. Locking a card to a set of MCCs, for example software and cloud categories, means the card approves transactions in those categories and declines everywhere else. The check happens at the network on every transaction, so the agent cannot route around it.

What is an approval ladder? An approval ladder maps the size and risk of an action to the amount of human involvement it needs. Small, in-category spend clears on its own. Spend above a threshold, or outside the allowed categories, pauses and routes to a human for approval. It lets an agent stay useful for routine work while keeping a person in the loop for anything that carries real risk.

Can an AI agent access my account and routing numbers? On Meow, no. The model never sees your account and routing numbers, because those credentials stay out of the context window. The agent operates through a scoped interface with only the capabilities you turned on, so a leaked prompt or a compromised session cannot pull out your banking details.

How much can an agent spend if something goes wrong? No more than the caps you set. With a two thousand dollar monthly cap and a five hundred dollar per-transaction cap on a category-locked card, the most a runaway or compromised agent can spend is two thousand dollars in a month, only at merchants in the allowed categories, with anything above five hundred dollars held for your approval. The caps are enforced at the network, so they hold regardless of what the agent tried to do.

What happens when an agent hits a limit or tries a blocked action? The transaction declines at the network, before it settles. On Meow, an action that needs a person, such as a charge above the per-transaction cap or a wire you left off, routes to you through Claude, SMS, Telegram, or the dashboard for a yes or a no. Every attempt, approved or declined, is written to the audit log.

A Note on Meow

Some people look at zero spending power by default and read it as a limitation. We read it as the design. An agent that starts with no ability to move money and earns each capability through an explicit human toggle is not a hobbled agent, it is a safe one. Meow gives you unlimited virtual and physical cards, custom spend limits, and MCC restrictions, and it enforces every one of them at the network rather than asking the model to behave. The account holder keeps control of the money. The agent gets to be useful inside the lines you drew.

Give Your Agent a Card, Not the Keys

An agent should be able to pay for the software it runs on without being able to touch the rest of your money. That is a config decision, and it comes down to four choices: a cap, a category, a threshold, and isolation. Set those and let the agent work. Open an account at meow.com.

Meow Technologies is a financial technology company, not a bank or FDIC-insured depository institution. Banking services are provided by Grasshopper Bank, N.A.; Member FDIC. The FDIC's deposit insurance coverage only protects against the failure of an FDIC-insured bank.