The procurement review was a Thursday in April 2026. An agent had been processing supplier payments for six weeks: each transaction under five hundred pounds, within a single spend category, running on a cap that a developer had set in the configuration file at launch. No exceptions. No complaints from finance. The item on the agenda was expanding the scope to a second spend category.
The question that ended the meeting came from the head of group treasury. "Who signed this off?"
The answer was that a developer had set the cap after a conversation with the product owner, and nothing had been recorded formally. That answer was accurate and commercially unacceptable. The agent had been spending company money for six weeks on the authority of no one in particular.
What the payment layer looks like now
Stripe launched its Machine Payments Protocol on 18 March 2026: an open standard for agents to request, authorise, and settle payments against any service or endpoint that supports it. Coinbase followed on 11 June with "Coinbase for Agents", embedding stablecoin settlement directly into HTTP requests via its x402 protocol. By July, Stripe reported 160 million autonomous transactions had cleared through the protocol. Visa, Mastercard, Shopify, Anthropic, and OpenAI are among the integrators.
This is not prototype infrastructure. An agent can hold a funding source, initiate a payment, and settle it without human intervention at any step. The payment problem, to be direct about it, is solved.
A spending cap is not a delegation
A spending cap in a configuration file is a technical constraint. It defines what the agent can transact per payment, or in total. It does not record who decided the agent should have spending authority at all; it does not say when that decision was made, what category it covers, whether it carries a review date, or whether the person who made it had the standing to make it.
The engineering response is usually that a hard cap is sufficient control for low-value transactions. There is something to this. A five-hundred-pound limit does constrain the damage from a single bad payment. But procurement governance is not primarily about limiting harm from one transaction. It is about maintaining a record of authority.
A buyer with a delegated purchasing authority carries an approval trail. The delegation was made by a named person, at a named date, recorded in the firm's system of record, scoped to specific categories and approved suppliers, and subject to review on a defined schedule. Every transaction the buyer makes is attached to that delegation. Internal audit can pull it. External audit can pull it. A new finance director who wants to understand last year's commitments can pull it.
For most of the agent deployments we have walked into, none of that exists. The spending cap was set by whoever opened the configuration file. There is no system of record, no expiry date, no named owner. If someone asks who authorised the agent to spend, the answer traces back to an informal conversation that was never written down.
The situation compounds when the agent's underlying model changes, or when the product owner who had the original conversation leaves the firm. A human buyer's delegation record survives both events. An agent's spending cap is simply inherited by the new configuration, unreviewed, because it was never formally granted in the first place.
What the approval chain requires
The firms getting ahead of this are treating agent spending authority the way they treat human spending authority. The agent receives a principal identity in the same access management system that governs employees. Spending authority is delegated to that principal by a named human authoriser, recorded with a timestamp, a spend scope, and an expiry date. The payment rail settles the transaction; the authorisation record, held separately, answers the governance question.
The scope matters as much as the cap. An agent authorised to pay within one spend category should not be able to route expenditure to a different category without a new delegation. An agent authorised to spend in sterling should not be able to commit in another currency without one. Those boundaries are a sentence each in a delegation record; they do not exist in a configuration variable.
The review schedule matters for the same reason. Human spending authority is reviewed on a defined cadence because circumstances change: a buyer moves to a different team, a supplier changes terms, a category is recategorised. An agent with no review schedule carries authority that was current when it was set and may not be current now. Defining expiry and review is not additional governance overhead. It is the thing that makes the authority a real record rather than a number that has outlasted the conversation that produced it.
The objection is that this adds governance process before the value is proven. That objection holds right up until someone who matters asks who approved it. After that, the conversation is about remediation.
“The objection is that this adds governance process before the value is proven. That objection holds right up until someone who matters asks who approved it.”
Stripe solved the payment infrastructure problem. Coinbase solved a different version of it. Neither solved the authorisation problem, because the authorisation problem is not in the payment layer. It is in the governance layer, and most organisations have not yet extended that layer to non-human actors.
The agent in April had been spending correctly for six weeks. The concern was whether anyone with the standing to say yes had actually said yes. In a firm where nobody has designed that workflow, the answer is always no.