Autonomous AI agents are executing real transactions. Booking travel, procuring software licenses, spinning up cloud infrastructure, paying contractors. The agent acts; the bill arrives later.
That gap between action and accountability is where engineering teams are getting burned.
If you're building agentic workflows—or deploying them internally—you need a spend governance layer. Not as an afterthought. As a first-class requirement.
Here's how to think about it.
Why Agents Need Different Controls Than Humans
When a human employee makes a purchase, there are natural friction points: they pause, they second-guess, they might ask their manager. That friction is annoying, but it's also a control.
Agents don't pause. They execute. A bug in a prompt, a misunderstood instruction, or an edge case in a workflow can result in hundreds of API calls, dozens of subscriptions, or a runaway cloud spend event—before any human notices.
The controls that work for human employees don't translate to agents. You need machine-readable limits enforced at the payment layer, not in the prompt.
The Three Layers of Agent Spend Control
1. Per-Transaction Caps
The most granular control: set a maximum dollar amount that any single transaction can authorize.
If your agent's job is to book economy flights, a $2,000 per-transaction cap makes sense. If it's purchasing SaaS tools with monthly subscriptions, maybe $500. The number isn't magic—it's calibrated to what the agent should plausibly spend in one action.
Per-transaction caps catch runaway single purchases. They don't catch an agent making 500 small purchases in a row.
Implementation approach:
- Issue each agent a card with a hard per-transaction limit
- Set limits that are 10-20% above the realistic maximum expected transaction
- Alert on transactions that approach but don't exceed the cap—this pattern can indicate the agent is gaming limits
2. Daily and Monthly Budgets
Rolling budgets are the second layer. They catch what per-transaction caps miss: volume attacks.
A daily budget of $1,000 means that even if an agent executes 200 transactions correctly sized at $4.99 each, it stops at 200. The card declines. The workflow pauses. A human reviews.
Monthly budgets handle slower drift—an agent that's consistently spending slightly more than expected, adding up over weeks to a meaningful overrun.
Implementation approach:
- Set daily budgets based on expected daily spend × 2x safety margin
- Set monthly budgets based on quarterly planning allocations
- Build alerting at 50%, 80%, and 95% of budget consumed—not just at 100%
- Budget resets should be explicit events, not automatic rollovers that agents can exploit
3. Merchant Category Restrictions (MCCs)
This is the most underused control, and often the most valuable.
Every merchant has a category code. A travel agent has a different MCC than a software vendor, which has a different MCC than a cryptocurrency exchange. Payment rails understand these categories, even if your application layer doesn't.
If your agent is supposed to book hotels, it should only be able to transact with merchants coded as hotels, airlines, and car rentals. Full stop. An agent booking hotels has no business at a crypto exchange or a wire transfer service.
MCC restrictions enforce intent at the payment layer. They're hard to exploit, because they're enforced by the card network, not by your application logic.
Implementation approach:
- Define an allowlist of MCCs that match the agent's intended use case
- Block everything outside the allowlist by default
- Log all declined transactions—a pattern of declines in unexpected categories is a signal the agent is trying to do something outside its scope
Tying It Together: Defense in Depth
None of these controls is sufficient alone. The right architecture layers all three:
| Control | What It Catches | What It Misses |
|---|---|---|
| Per-transaction cap | Single large purchases | High-volume small purchases |
| Daily/monthly budget | Volume attacks, drift | Large one-time purchases within budget |
| MCC restrictions | Out-of-scope spending | In-scope overspending |
Together, they create overlapping coverage. An agent would need to simultaneously stay under per-transaction limits, stay under budget, and find in-scope merchants to cause meaningful damage—a much harder constraint to satisfy accidentally.
The Card Issuance Pattern
The practical implementation of all of this is card issuance. Issue each agent (or class of agents) its own payment card with controls baked in at creation time.
This is distinct from giving agents access to a shared corporate card. A shared card gives all agents the same limit, the same categories, and the same budget—meaning a single rogue agent can exhaust controls for the entire fleet.
Per-agent cards give you:
- Isolation: one agent's spending can't affect another's limits
- Attribution: every transaction is tied to a specific agent identity
- Revocation: shut down a specific agent's card without affecting others
Agent-native spend management platforms like Spur are built around exactly this pattern—issuing cards per agent, with per-transaction caps, rolling budgets, and MCC restrictions configurable at the card level.
What to Build vs. What to Buy
If you're at an early stage and agent spend is low-volume and low-stakes, you can approximate these controls with:
- Prepaid cards with manual top-ups (acts as a budget cap)
- Manual review of transaction receipts
- Prompt-level instructions to avoid certain categories
This breaks at scale. Prompt-level instructions are not enforcement—they're suggestions. An agent that misinterprets context will ignore them. Prepaid cards with manual top-ups create operational overhead that compounds as agent count grows.
The inflection point is typically around 5-10 agents or $5,000/month in agent-initiated spend. At that threshold, the cost of a proper spend management layer is smaller than the cost of the first incident it prevents.
Checklist: Agent Spend Governance
Before deploying any agent that can execute financial transactions:
- [ ] Per-transaction cap set and tested
- [ ] Daily budget configured with alerting at 50/80/95%
- [ ] Monthly budget set against planning allocation
- [ ] MCC allowlist defined and enforced
- [ ] Per-agent card issuance (not shared card)
- [ ] Transaction logs accessible for audit
- [ ] Runbook for "agent exceeds budget" scenario
- [ ] Card revocation tested end-to-end
The agents are already running. The spend controls need to catch up.
Spur builds agent-native corporate cards with built-in spend controls. Learn more →
Top comments (0)