Should an AI Agent Ever Be Allowed to Spend Money?

Should an AI Agent Ever Be Allowed to Spend Money?

Yes, within a cap it cannot raise, on instruments that can be revoked, with a record of who authorised what. The dangerous version is not an agent with a budget. It is an agent with your saved card and no ceiling, which is what most quick experiments actually build.

This question has moved from theoretical to practical fast. The payment industry has spent the last year building the plumbing for agents to buy things, and the tooling to constrain them now exists.

So the real question is not whether it is possible. It is what a sane authorisation looks like, and what you are on the hook for when it goes wrong.

What Has Actually Been Built for This?

Two open protocols, from the two obvious camps, both addressing the same gap: proving an agent had permission rather than just possession of a credential.

Google publishes the Agent Payments Protocol, which describes itself as "an open protocol for the emerging Agent Economy." Standardisation work continues inside the FIDO Alliance, in its Agentic Authentication and Payments Technical Working Groups.

Separately, Stripe and OpenAI publish the Agentic Commerce Protocol under the Apache 2.0 licence, which defines "a common language for how agents and businesses transact". Its stated aim on the payments side is to let a business "securely pass payment credentials from your buyers to AI agents, without exposing underlying payment credentials," with Stripe's Shared Payment Token as the first compatible implementation.

Read the specifications rather than the summaries. Protocols moving this quickly are described inaccurately all over the internet, and the details are the entire point.

What Does a Payment Authorisation for an Agent Look Like?

A signed statement of what the agent may do, that travels with the transaction. In the Agent Payments Protocol these are called mandates, and the specification describes two.

A Checkout Mandate "captures the reference to the specific items and purchase details negotiated between the agent and the merchant" and is shared with the merchant. It has an open stage, which captures the user's constraints before anything is finalised, and a closed stage, which authorises one specific finalised checkout.

A Payment Mandate "authorizes a payment against a specific payment instrument" and goes to credential providers, networks and processors. Its open version captures "constraints on payment (e.g., budget, allowed instruments)," and its closed version authorises a specific amount tied to that checkout.

That two stage split is the interesting design choice. You are not approving a purchase. You are approving a shape of purchase, and then the specific one that fits it.

Who Is Accountable When an Agent Buys the Wrong Thing?

Whoever signed the mandate, which is precisely why the mandates are signed. The specification describes them as "tamper-evident, cryptographically signed digital objects" that provide "a non-repudiable, cryptographic audit trail for every transaction, aiding in dispute resolution."

Notice what that solves and what it does not. It settles whether the agent was authorised. It does not settle whether authorising it was sensible.

If you signed a mandate allowing a thousand pounds a month of software purchases and your agent spent it on the wrong software, that is not a disputed transaction. That is a bad decision with a perfect paper trail. The protocol gives you evidence, not judgement.

How Do You Cap an Agent Today, Without Any Protocol?

Issue it a card with spending controls, which is boring, available now, and sufficient for most cases. Stripe Issuing is a clear example of the shape of control that exists.

Its documentation lets you set spending limits per authorisation or per month, restrict or allow merchant categories, restrict merchant countries, and set controls at either the card or the cardholder level. Where limits overlap, the documentation states that "the most restrictive spending control applies."

It also applies defaults, which is worth knowing before you rely on your own configuration. If you set no spending limits at all, "a default spending limit of 500 USD per day applies to the newly created card." And regardless of what you configure, "an unconfigurable default spending limit of 10000 USD also applies to each authorization."

Two details matter operationally. Spending aggregation is best effort, with the documentation noting "a delay of up to 30 seconds between spend occurrence and spend aggregation." And spending limits alone do not block categories; the documentation is explicit that they "should be used with either allowed_categories or blocked_categories to restrict spending to specific business types."

What Should the Cap Actually Be?

Small enough that the worst case is annoying rather than serious. The test we use is simple: if the agent spent the entire limit today, on the wrong thing, would you need to tell anyone?

If the answer is yes, the limit is too high for an unsupervised agent. That is not a statement about model quality. It is a statement about how much unreviewed authority any process should hold, human or otherwise.

We also prefer a per transaction cap over a monthly one as the first line of defence. A monthly ceiling stops a catastrophe. A per transaction ceiling stops the specific failure that actually happens, which is one wrong purchase of the wrong size.

Which Purchases Are Genuinely Safe to Delegate?

The repetitive, bounded, reversible ones. Topping up a metered service you already use. Renewing a licence at a known price. Buying a domain from a fixed list. Paying a per unit API bill you already monitor.

What those have in common is that the decision was already made by a human and the agent is only executing it. Nobody is asking the model to exercise commercial judgement.

The unsafe category is anything involving a choice between vendors, anything with a contract attached, anything recurring that nobody will notice, and anything where the cheapest option is not obviously the right one. Those are judgement calls, and an agent making them is not saving you work. It is deferring the work to whoever audits the statement.

Is a Human Approval Step Enough?

Only if the human can actually evaluate what they are approving. An approval prompt that says "the agent wants to spend 240 pounds, allow?" trains people to click yes.

A useful approval shows the merchant, the exact amount, what triggered it, what it is replacing, and what happens if it is declined. It also arrives rarely enough that it still gets read. Approval fatigue is the standard failure mode of every human in the loop design, and it is why we argue for fewer, better checkpoints in keeping a human in the loop properly.

The stronger pattern is to make approval unnecessary for the safe cases and mandatory for everything else. Agent buys within the allowlist and under the cap: no approval, full logging. Anything outside either boundary: refuse, and raise it to a person as a request rather than a confirmation.

What Should You Never Give an Agent?

Your own card, your own login, and anything shared. This is the same argument as least privilege everywhere else, applied to money, and the reasons are practical rather than ideological.

A dedicated instrument can be capped, watched and cancelled without disrupting anything else. A shared one cannot. When something goes wrong with a shared credential, your options are to freeze a card the whole company depends on, or to let the problem continue while you work out what happened.

The same goes for accounts. An agent with its own credentials produces a log you can read, and can be switched off in one place. An agent borrowing a person's session produces a log that blames that person. Our piece on giving an agent only the access it needs covers the general version of this.

So What Would We Actually Set Up?

A dedicated virtual card with a per transaction cap and a monthly cap. An allowlist of merchant categories, because limits alone do not restrict where money goes. A separate account for the agent, never a person's. A log of every attempted purchase, including the declined ones, since declines are where you learn what the agent is trying to do.

Then a weekly five minute review of that log for the first month. Not because the agent is untrustworthy, but because you will discover the agent is trying to buy things you never considered, and that is cheap information.

Adopt the payment protocols when the merchants you buy from support them, and not before. They will make delegation cleaner and disputes easier. They are not a prerequisite for doing this safely today, and the accountability question they answer is one you still have to think about yourself, as we argued in who is accountable when an automation gets it wrong.

If you are weighing up handing an agent a budget and want a second opinion on the guardrails first, we are happy to think it through with you at phoenix.studio.