Spend Controls for AI Agents: Virtual Cards, Limits and Reconciliation Patterns for Corporate Spend
Giving an AI agent the ability to spend money is not a new kind of risk. It is an old one, delegated spending, arriving faster and with less supervision than most finance teams are used to. An agent working through a task may need to buy a software licence, a dataset or a service, and the question for the finance and platform leaders who allow it is simple to state and hard to answer: which controls make that spend safe? Our position is that the answer is mostly a set of familiar corporate-card controls, applied per task rather than per person, with reconciliation designed in from the start. This article sets out that framework without reference to any vendor's product.
The evidence behind the framework is thin and US-led, so we separate what is reported from what is our analysis as we go.
What the market evidence does and does not say
The reporting we hold points in one direction. A US finance-operations platform has been reported to have raised $1.85bn at a $60bn valuation, to have shipped a card for AI agents and to have applied for a US national trust bank charter. Two other firms are reported to be seeking bank-type charters as well, according to a fintech newsletter. Separately, reporting describes accounts payable and finance operations as the first place delegated payments are likely to become practical, because approvals, supplier records and audit trails already exist.
Read carefully, that supports two modest statements. Capital is flowing to platforms that productise controls over agent spending. And the first sensible use cases sit in finance operations. It does not tell us how many organisations let agents spend today, how much they spend or how well any particular control works. The funding and charter facts are third-party reporting, the evidence is US-led, and we have not seen UK adoption data. We would treat it as a reason to design controls now, not as proof that a market has formed.
We name no vendor here because the framework does not depend on one. The controls below can be built on any card-issuing or embedded finance stack that exposes the right hooks.
Start with the principle: delegated authority with a boundary
A corporate card works because an organisation gives an individual a limited amount of authority, with rules, and records what they did with it. An agent needs the same arrangement with two differences.
First, an agent can act much faster and more often than a person. A control that relies on someone noticing a problem next week will not work when an agent can spend in seconds.
Second, an agent's intent is harder to inspect. A person can explain why they bought something. An agent's reasons are in prompts, tool calls and outputs, which a finance team may not be set up to read.
The principle that follows is that the boundary must be enforced by the payment system, not by the agent's good behaviour. If a limit lives in the agent's instructions, it is a request. If it lives in the card, it is a control.
The framework: six controls
What follows is our analysis, a way of organising the controls rather than a description of any product.
1. One virtual card per task
The first control is to issue a virtual card for a defined task, not to give an agent a long-lived card number. A card scoped to one job has a clear purpose, a clear budget and a clear end. When the task finishes or fails, the card closes.
This pattern has practical advantages. If a card number is exposed or misused, the damage is limited to that task's budget. Spend on the card maps directly to the task, which makes reconciliation simple. And you can see, at a glance, which tasks are costing what.
The trade-off is operational. Issuing and closing cards at task frequency needs an issuing platform that handles many cards cheaply and reliably, and a clear owner for the mapping between task and card. Where tasks are very frequent and very small, a card per task may be heavy, and a card per workflow or per agent with tighter limits may be the better compromise.
2. Limits that are layered, not single
A single limit is a blunt instrument. A more useful design layers several:
- Amount per transaction. A ceiling on any one payment.
- Total per task. The budget for the job, after which the card stops working.
- Count and velocity. A cap on the number of payments in a period, which catches loops where an agent repeats a purchase.
- Time window. A validity period, so that a card left open cannot be used later.
Choose the numbers from your own data and your own risk appetite. We do not offer typical values, because the evidence we hold does not support any, and a number borrowed from another organisation is not a control.
3. Merchant and category restrictions
Limits stop the amount. Restrictions stop the destination. An agent buying a software subscription has no reason to pay a travel merchant or a gambling site. Restricting a card to named merchants, or to categories of merchant, shrinks the space in which a mistake or a manipulated agent can do harm.
This control matters more because agents can be manipulated. If an agent reads untrusted content while working, that content may try to redirect it. A card that can only pay approved merchants turns a possible fraud into a declined transaction.
Allow-lists are safer than block-lists, though they take more maintenance. For a bounded task, an allow-list of one or two merchants is easy to specify.
4. Approval routing
Some spend should not go through automatically. The design question is where the threshold sits and who decides above it.
A workable approach is tiered. Low-value, in-policy spend within the task budget goes through automatically. Spend above a threshold, to a new merchant or outside the task's normal pattern is held for approval by a named person or team. The approval request should carry enough detail to be decided quickly: what the agent wants to buy, from whom, for how much and for what task.
Two points matter in practice. The approver must be a person or function with authority, not a shared inbox. And the hold must be enforced by the payment system, so that an unapproved payment is simply not authorised.
For UK organisations this connects to accountability. The FCA has been described in recent reporting as applying existing frameworks, such as the Consumer Duty and senior-manager accountability, to AI rather than creating agent-specific rules. Those frameworks apply to regulated firms, and whether and how they apply to your organisation is a matter for compliance advice. As a design principle, though, naming who is accountable for the policy that lets an agent spend is sound practice whoever you are.
5. Reconciliation designed in
Reconciliation is where agent spend tends to become a problem later, so it should be designed first. The aim is for every payment to be matched, automatically and without a person hunting through statements, to a task, a policy and an outcome.
A good record contains, for each payment: the task identifier, the agent, the policy version that allowed it, the amount and merchant, the approval trail if any, and the result of the purchase. With a card per task, much of this comes from the card itself. With shared cards, it has to be added through metadata and matching.
Automated reconciliation can then do three things. It can match payments to expected spend and flag differences. It can flag payments with no matching task. And it can close the loop with accounting, so the cost lands in the right place. A reconciliation agent can help with the matching, but we would keep a human review of exceptions. An agent checking another agent's spending is useful, but it is a second control, not a substitute for the first.
6. A stop button and an audit trail
The last control is the ability to halt spending quickly and to explain afterwards what happened. Someone needs the authority and the means to freeze an agent's cards immediately, without a change request. And the logs from the previous section need to be kept, protected and retrievable, so that a review can reconstruct events.
Test the stop button before you need it. A control that nobody has ever used is a control nobody knows works.
Building it on an embedded-finance stack
Most of these controls depend on capabilities that a modern card-issuing or embedded-finance stack exposes: issuing virtual cards through an interface, setting limits and merchant rules on each card, receiving a real-time request to approve or decline each payment, and streaming events to your own systems.
The architectural point is where the decision logic lives. We would put the policy, meaning which agent may spend what, where and with whose approval, in your own system, and have the card platform enforce it through limits and real-time decisions. That keeps the policy portable if you change issuer, and lets you change the policy without changing the card setup.
Four design choices deserve attention.
Make the task the unit. Create a task record first, then the card, then link them. It makes every later step easier.
Use real-time decisions for exceptions. Static limits handle the common cases. A real-time check lets you apply logic that a static rule cannot, such as holding spend that departs from a task's normal pattern.
Keep identity and spend together. Each card should be traceable to the agent and the human or function accountable for it.
Plan for failure. Decide what happens if the decisioning service is unavailable: decline by default, or allow within a small limit. For agent spend, declining by default is usually safer.
Where to start
You do not need all six controls to begin. We would start with a bounded use case in finance operations, which is where the evidence suggests delegated payments are likely to appear first.
Pick one low-risk task type with a known budget. Issue a card per task with an amount ceiling, a time window and a restriction to specific merchants. Hold anything above a threshold for named approval. Record each payment against its task. Run it with a small fixed budget for a defined period, and review every payment at the end. Set a stop rule in advance, for example any unexplained payment, any limit breach or a reconciliation break above a tolerance you agree beforehand.
That pilot will tell you more about the controls you need than any general framework, including this one.
Where Innovify fits
Innovify is a technology partner with deep expertise in banking, financial services, fintech and insurance. We help mid to large businesses build AI-native products, modernise their technology stack and launch fintech products, and we design compliance in from day one.
Controls for agent spend sit where card and wallet infrastructure meets agentic payments. Our Agentic Commerce & Payments work looks at how delegated payments are authorised, limited and recorded, and Innovify AI Labs lets enterprise teams run several proofs of concept in parallel, test with real users and finish with a business case ready for funding. If you want to test an agent spend policy against a fixed budget before it touches production money, talk to us about what a first pilot would look like.
FAQ
How do you control spending by an AI agent?
You control it with limits enforced by the payment system, not by the agent's instructions. The core controls are a virtual card per task, layered limits on amount, count and time, merchant restrictions, approval routing for exceptions and reconciliation of every payment to a task.
What is a virtual card per task?
A virtual card per task is a card number issued for one defined job, with its own budget, time window and merchant rules, then closed when the job ends. It limits the damage from misuse and makes each payment easy to match to its purpose. For very frequent, very small tasks, a card per workflow may be more practical.
What limits should I set on an AI agent's card?
Layer several limits: a ceiling per transaction, a budget per task, a cap on the number of payments in a period and a validity window. The right values depend on your own data and risk appetite. We do not give typical figures because the evidence we hold does not support any.
Can an AI agent reconcile its own spending?
An agent can help with matching, but it should not be the only check. Reconciliation works best when each payment carries a task identifier and policy version, so matching is largely automatic. A person should still review exceptions, because an agent checking an agent is a second control, not a replacement.
Is this regulated in the UK?
It depends on your organisation and how the arrangement is structured, so take compliance advice. The FCA has been described as applying existing frameworks, such as the Consumer Duty and senior-manager accountability, to AI rather than writing agent-specific rules. Whether those apply to you is a question for your compliance team.
Where should a team start with agent spend controls?
Start with one low-risk task type in finance operations, a fixed small budget, a card per task and named approval above a threshold. Record each payment against its task and review all of them at the end. Agree a stop rule in advance.
Conclusion
Controlling agent spend is mostly a matter of applying familiar corporate-card discipline at task level and enforcing it in the payment system. A virtual card per task, layered limits, merchant restrictions, approval routing and designed-in reconciliation, backed by a tested stop button, cover most of the ground. The market evidence says capital is flowing to platforms that sell these controls, but it does not say how well they work or how widely they are used. A small, bounded pilot with a stop rule is the sensible way to find out.
