You Already Know How to Delegate Spending. Now Write the Mandate for an Agent.

You already let people spend your company's money without losing control, every day, and you barely think about it.

A new hire gets a corporate card with a monthly limit. A procurement manager can raise a purchase order, but anything over a threshold needs a second signature. Travel goes on the card; a new supplier goes through onboarding first. And at the end of the quarter, finance can pull up every line and ask who bought what, why, and under which policy. Nobody calls this "autonomous spend." We call it delegation, and enterprises have been doing it for a century.

An AI agent is a new kind of delegate. Once you stop treating "AI that spends money" as a novel category and start treating it as an unusually fast, unusually literal junior employee, the policy almost writes itself, because you already have the instruments. Most of the work is mapping the controls you have onto a machine, and being straight about the two or three places where the mapping breaks.

What you're actually handing over

When you give a person a card, you don't give them your money. You give them a bounded claim on it: this much, at these kinds of places, for these purposes, reviewable later. The 2026 payments stack does the same thing for agents, and it helps to understand the plumbing for one paragraph, just so you know what your policy is riding on.

Every mainstream design deliberately keeps the raw card number away from the agent. Mastercard's Agent Pay and Visa Intelligent Commerce issue a tokenized credential bound to a specific agent and a specific scope. Stripe and OpenAI's Agentic Commerce Protocol uses a Shared Payment Token that's valid for one merchant and one cart, then dies. Google's AP2 represents the whole authorization as three signed mandates (Intent, then Cart, then Payment), each a W3C Verifiable Credential, so there's a record of who authorized what that nobody can later deny. In April 2026 Google donated AP2 to the FIDO Alliance and Mastercard contributed its Verifiable Intent framework. I find that encouraging, because it means this is consolidating into shared standards rather than a dozen walled gardens.

If you want the deeper why and what of those protocols, we wrote the primer separately in the moment AI was allowed to spend money by itself. This piece covers the operator's job that comes after you've read it, which is writing the mandate the agent actually carries. So let's map the instruments you already own.

The four instruments, translated

Start with the allow list of payees. It's the most important instrument and almost nobody leads with it. When you onboard a supplier, you're mostly not deciding how much they can be paid. You're deciding that they can be paid at all. That decision (the approved vendor list, the merchant category, the "we do not send money to counterparties we haven't vetted" rule) is your primary control surface. For an agent it should be the same: an explicit list of merchants or merchant categories it may transact with, and a hard stop plus escalation for anything new. Teams underweight this one because it feels less like a "spending control" than a number does. It is the spending control.

Then the limits, per transaction and cumulative. Think of the card limit and the monthly cap together. A single per transaction ceiling is easy and does half the job. The failures that hurt are rarely one big charge; they're a loop of small, individually plausible ones that add up. So set a cap per purchase and a cap per session or per period. Coinbase's Agentic Wallets, launched in February 2026, ship exactly this pairing. An operator sets a total session cap and a per transaction limit when creating the wallet and can tighten either on the fly. That's the corporate card with a monthly cap, rebuilt for a runtime that can fire a hundred requests a second.

Context and approval tiers are your dual sign off over a threshold. Your expense policy doesn't route everything the same way. Recurring spend that fits the policy clears automatically, while an exception or an unusual amount goes to a manager or to finance. Encode the same tiering. Recurring purchases with low risk and clear scope run inside the mandate. Anything odd (a new merchant, an amount outside the norm, a request that arrived without the business context that should come with it) goes to a human. AP2 makes this concrete with its human present flow, where a person signs the Cart Mandate before money moves.

Last, the replayable audit, the expense report finance can actually reconstruct. Logs existing somewhere doesn't get you far. What you want is to replay the decision: which mandate authorized this, under which policy version, triggered by what. The chain of signed mandates gives you cryptographic proof of origin almost for free, a real gain over a screenshot of an approval email. Use it. If you can't reconstruct a purchase end to end, you don't have delegation, you have hope with a receipt.

Delegation always meant trust with a boundary written down. The agent just makes you write it down more precisely than you ever did for a person.

You already run all four for humans. If this were the whole story, you'd copy your expense policy into a config file and go home.

Where the analogy breaks

It isn't the whole story, and the gaps are where most of the work sits.

"The agent never touches the raw card number" protects the credential, not the decision. Every vendor deck leads with this line, and it's true and it matters, since a scoped token can't be replayed at a random merchant the way a stolen PAN can. But read it carefully. Tokenization secures how the money moves and says nothing about whether the purchase was the right one. When a hallucinating agent buys the wrong thing inside its limits, from an allowed merchant, the token was used exactly as designed. The security control did its job perfectly and you still bought the wrong thing. Mixing up credential protection with decision governance is the most expensive misread in this space.

Spend caps are a speed limit with no steering. A per transaction and session cap stops a runaway loop, which is useful, so keep it. Against an agent hit by prompt injection that spends right up to the limit at an attacker's merchant, it does nothing. And prompt injection is still unsolved; it's number one on the OWASP LLM Top 10 in 2026, with the same report citing a sharp year on year surge in attacks. With a spending agent, a successful injection turns into a fraudulent transaction rather than a bad answer. That's why the allow list of payees, not the amount cap, is your steering wheel. A poisoned web page can convince an agent to spend, but it can't add a new payee to a list only you control.

An amount limit slows the crash. The allow list is the steering. Most policies overinvest in the first and forget the second.

Spend with no human present belongs to a service account, not a shopping cart. The demos tend to look away from this. Most of an agent's value is preauthorized autonomy: buy the tickets the instant they drop, autoscale the licenses at 3 a.m., with no human awake to confirm. AP2's v0.2, added when it moved to FIDO, formalizes exactly this "Human Not Present" flow, where the agent generates the Cart Mandate itself once the conditions of the signed Intent Mandate are precisely met. That's powerful, and it removes the one checkpoint every governance slide leans on, the human tap. So stop picturing a customer with a shopping cart and picture a service account with production database credentials. You already know how to govern one of those: narrow scope, short lived tokens, tight logging, alerts on anomalies, and a very short list of people who can grant it. The moment you remove the human, apply that discipline instead of the retail checkout one.

A reality check for the slide deck

Before you architect a governance cathedral, one sobering data point. OpenAI killed its flagship Instant Checkout in ChatGPT in March 2026, roughly five months after launching it, without much noise. Reporting suggests only about a dozen Shopify merchants ever went live and sales were near zero. Users happily researched in ChatGPT and then bought on the storefronts they already trusted. The Agentic Commerce Protocol underneath survives; the consumer product did not.

I don't read that as proof agentic payments are vapor. Mastercard shipped Agent Pay for Machines for autonomous machine to machine spend in June 2026, and this is clearly where enterprise operations are heading. It's a lesson about sequencing. The cryptographic trust layer got built faster than the demand, the tax and fraud plumbing, and the inventory sync that make a working buyer, so governance shipped ahead of the use case. Design your mandate seriously, but scope your first agent to a real, bounded job with an obvious ROI (a known set of suppliers, a capped budget, a process you already understand) rather than a general purpose spender chasing a market that isn't there yet.

A policy you can actually write down

This is the checklist we hand teams. It's deliberately boring, because a mandate you can read in a minute is one people will actually check against.

Before an agent moves a cent, the mandate must answer:

  WHO can it pay      -> explicit merchant / category allow-list;
                         novel payee = hard stop + human escalation
  HOW MUCH            -> per-transaction cap AND session/period cap,
                         both, always
  UNDER WHAT CONTEXT  -> required trigger, cost center, budget owner;
                         missing context = no transaction (fail safe)
  WHO CONFIRMS        -> tiered: in-policy auto, exceptions to a human;
                         human-not-present = treat as a service account
  CAN YOU REPLAY IT   -> mandate + policy version reconstructable
                         end to end, or it doesn't ship
  WHAT'S THE BLAST    -> assume prompt injection succeeds; the allow-list,
    RADIUS               not the amount cap, is what contains it

If you can't fill in all six for a given agent, it isn't ready to hold a payment credential. You'd hold a new hire to the same bar before handing over the card. Here it's just written out, because the delegate is software.

Who pays when the agent buys the wrong thing

There's one gap the instruments don't close, and I'd rather name it. When an agent makes a bad purchase (wrong thing, right limits, valid mandate), who eats the loss?

Under EU PSD2, the payment service provider is generally on the hook to reimburse "unauthorized" transactions. But a signed mandate proves an instruction existed. It doesn't prove the instruction was reasonable, or that the agent understood it, or that consent was informed. Lawyers already describe "blackbox moments" where nobody can cleanly say whether a bad agent payment was unauthorized or user negligence. Strong Customer Authentication still assumes a human is present to authenticate, which is precisely what a mandate without a human present removes. The EU AI Act becomes fully applicable on 2 August 2026 and doesn't squarely resolve payment liability either; if you're mapping your broader obligations, our EU AI Act readiness checklist is the place to start.

Auditability is being oversold as accountability, mostly without anyone saying so. A JWT that can't be repudiated will not, on its own, win a chargeback dispute in front of a regulator who wants to know why the decision was reasonable. I'm not arguing against agentic spend here. I'm arguing for keeping a human in the loop wherever the amount, the merchant, or the consequences are new, and for reading up on the economic language these agents actually transact in before you wire one into your finance stack.

Onboard it like a new hire

You already own the card limit, the approved vendor list, the dual sign off, and the quarterly audit, and they translate to an agent almost line for line. Where people slip is remembering which instrument does which job. The amount cap slows a crash and the allow list steers. The token protects the credential, but only a human tier protects the decision. And once you remove the human, you're running a service account with your money behind it, whatever the checkout screen looks like.

Write the mandate like you'd onboard a new employee you don't fully know yet. Narrow scope, a real budget, a short leash, and receipts you can actually read. Get that right and an agent becomes one of the most useful hires you'll make this year. Get it wrong and it's the one who maxed out the card while everyone admired how it never saw the number.

If you're figuring out where the human line should sit for your own agents, that's a conversation we have most weeks. Bring your messiest use case.

Updated on 12 October 2026.