AI Agent Spending Controls: What to Set First

On August 11, Mercury launched Spend — a business banking product that, among other things, issues a new class of virtual card built specifically for AI agents. A human sets the budget, the category, and the rules; the agent gets a card and the ability to complete purchases end-to-end within those limits, fully autonomously. Try to spend outside the policy — wrong category, over the cap, wrong vendor — and the transaction is declined at the point of sale, automatically, no human in the loop needed to catch it. The agent cannot raise its own limit. It's a small product launch, but it marks something real: AI agents have quietly crossed from advising on purchases to executing them, and the financial infrastructure is now catching up to make that safe — or not, depending on who's setting it up.

The timing is not flattering. A 2026 Cloud Security Alliance survey found that 65% of enterprises running AI agents experienced at least one agent-related incident in the past 12 months, and 35% reported a direct financial loss from one. Those numbers were generated by agents operating without anything like Mercury's guardrails — reading emails, updating records, calling APIs, sometimes with standing credentials and no spending ceiling at all. Give that same agent an actual corporate card next, and the blast radius of a bad decision stops being a corrupted spreadsheet and starts being real money leaving your account.

Two Kinds of Spending, Two Different Risks

It's worth separating what "AI agent spending" actually covers, because the two categories fail differently:

• Transactional spending — an agent buying things on your behalf: renewing a SaaS subscription, booking a vendor, ordering supplies, paying an invoice. This is what Mercury Spend is built for, and it fails loud: a wrong purchase, a duplicate payment, a vendor that shouldn't have been paid.
• Operational spending — the token and API cost of running the agent itself. Ramp reports customers' average monthly token spend is up 13x since January 2025. This fails quiet: nobody notices until the bill arrives, because there's no point-of-sale decline to stop it.

Most businesses adopting agentic AI right now have controls for neither, or controls for one and not the other. A procurement agent with a hard spending cap can still rack up an unbounded API bill doing the reasoning that leads to each purchase decision.

The Control Framework, Before Go-Live

None of this is an argument against letting agents transact — 60-70% of end-to-end transactional procurement is headed toward full or near-full automation, and the efficiency case is real. It's an argument for sequencing the guardrails before the authority, not after an incident forces the issue:

1. 1Give the agent a hard spending ceiling that it cannot modify, at the card or account level, not just as a rule the agent is instructed to follow — instruction-based limits are a suggestion; account-level limits are a wall
2. 2Scope by vendor and category, not just by dollar amount — a $500 cap that can go to any vendor is a much bigger hole than a $500 cap restricted to three pre-approved SaaS renewals
3. 3Separate operational (token/API) budgets from transactional budgets, and alert on both independently — a token-spend spike is often the earliest signal something in the agent's reasoning has gone wrong, well before it reaches an actual purchase
4. 4Log every transaction with the reasoning that led to it, not just the amount and vendor — when a decline or a dispute happens, you need to know why the agent tried to make that purchase, not only that it tried
5. 5Route anything outside the pre-approved envelope to a human by default — new vendor, unusual amount, first-time category — rather than allowing it through on a confidence score alone

A Realistic Scenario

A regional property management company deployed an AI agent to handle recurring vendor payments — landscaping, pest control, minor repairs — across 40 properties, using a shared virtual card with a monthly cap and instructions to "only pay approved vendors." Three weeks in, the agent paid a vendor invoice twice after a billing system glitch generated a duplicate, because nothing at the card level distinguished a first payment from a repeat one — the instruction to avoid duplicates existed only as a line in its prompt, not as an actual control. Wizeb rebuilt the setup with vendor-scoped sub-limits, a hard rule blocking any transaction matching an amount and vendor paid in the prior 14 days, and a decision log surfaced to the property manager weekly. The agent still pays 90%+ of recurring vendor invoices with zero human touch — the difference is that the guardrails live in the infrastructure, not in the agent's good behavior.

How Wizeb Approaches This

When we build an AI agent that touches money — purchasing, invoice payment, vendor management — the spending controls are part of the initial architecture, not a follow-up project after something goes wrong. That means hard account-level limits instead of prompt-based instructions, separate monitoring for operational and transactional spend, and a decision log for every autonomous action that touches a dollar. If you're evaluating an agent that will have any purchasing authority — or you already have one running without a real spending ceiling — that's worth a conversation before it needs to be a postmortem. Start at wizeb.com/services/ai-agents.

Three Questions Before an AI Agent Gets a Card

1. 1Is the spending limit enforced at the account or card level, or only as an instruction the agent is trusted to follow?
2. 2Do you have separate visibility into operational (token/API) spend versus transactional spend, or would a runaway API bill and a bad purchase both just show up as "the AI cost more than expected" at month end?
3. 3If the agent made a purchase you didn't expect, could you see the reasoning that led to it — or only the amount and the vendor?