Intelai
Agentic Commerce Solves Checkout, Not Spending Authority
The Agentic Commerce Protocol gets the token right: a permission that carries its own limit. Federal money needs something a limit cannot supply.
Stripe and OpenAI published the Agentic Commerce Protocol as an open specification. It does one thing well: it lets an AI agent complete a retail checkout without ever holding the card number.
The interesting part is not the checkout. It is the token the agent gets instead of the card.
An agent asks a payment provider to delegate a credential. What comes back is bounded: an amount, a currency, an expiration, and one merchant. Whoever holds that token cannot spend past the amount, and cannot spend it anywhere else.
The limit travels with the permission.
That is the right shape for a control over an autonomous system. It is also the shape a purchase cannot take once the money has been appropriated.
The protocol is narrower than the coverage
The specification (opens in a new tab) defines four parties and two interfaces. A buyer talks to an agent. The agent talks to the seller through Agentic Checkout. The agent talks to a payment provider through Delegate Payment. The seller still sets the price, still calculates tax and shipping, and remains the merchant of record. The payment provider mints the token and enforces the allowance.
That is a retail purchase. It is not a subscription portfolio, a refunds queue, or accounts payable.
It is easy to read the launch coverage and come away thinking agents now upgrade licenses and issue refunds on their own. The specification does not say that, and building against the coverage rather than the spec is how a demo becomes a finding.
What the token gets right
Almost every payments integration I have seen starts with one API key that carries every right the account has. The key sits in an environment variable, gets rotated after something goes wrong, and grants whatever the account can do. The limit, if there is one, lives in application code that somebody else can edit.
ACP is built the other way around. The allowance is set by the payment provider at token issuance: currency, ceiling, expiry, merchant. The merchant is fixed, so the token is single-vendor by construction and cannot be replayed at a different store. Risk signals ride along with the request instead of arriving after the charge.
None of that is novel cryptography. It is the unglamorous work of putting the limit in the artifact instead of in the instructions. An agent can be talked past a system prompt. It cannot be talked past a token that will not authorize the charge.
That property is worth copying, and it is the one most internal agent projects skip. They write the ceiling into the prompt, log the action after the fact, and call it a control.
A purchase is not an obligation
Here is where the protocol meets federal money, and where it stops.
A card transaction authorizes a payment. An obligation commits an appropriation before the money moves. They are different acts, done by different people, and the second one is where the law lives.
The Antideficiency Act, at 31 U.S.C. § 1341, makes it a violation to obligate funds in advance of an appropriation or in excess of one. An obligation is incurred by an authorized official. An agent is not an authorized official, and no configuration option changes that. A token with a five hundred dollar ceiling is a spending limit. A spending limit is not a delegation of authority, and it does not bind the government. Only a warranted contracting officer does that.
Then there is segregation of duties. In a commercial purchase, the person who wants the thing, approves the spend, and pays is often one person spending their own money in one browser tab, and the collapse of those steps is the whole convenience. In a federal purchase they are three roles held by three people on three different calendar entries. Splitting them is a control, not a formality.
An agent that initiates, approves, and executes the same transaction is a finding in any audit. ACP does not create that problem. It makes the problem easy to build without noticing.
The part I would specify anyway
Three things are worth taking from the protocol, and none of them requires Stripe.
A per-action token, issued by whoever holds the authority to issue it, bounded before the action starts. For spending, the approval should produce a scoped authorization with an amount, a vendor, and an expiry, and the agent should present it at the moment of purchase. Not a standing limit the agent has promised to respect.
A ceiling that refuses instead of warning. If the approval is a notification that arrives after the work is finished, the ceiling is decoration.
A record of the authorization, not the payment. ACP carries risk signals because the payment provider needs them. An auditor needs a different artifact: who approved this, under what authority, and what the agent was permitted to do when it acted. If that record lives in the payment provider's console, on the provider's retention schedule, you do not have it.
The last one is where pilots find the gap. The charge clears, the invoice matches, and nobody can reconstruct why the spend was allowed.
An agent that can buy something is a convenience. An agent that can commit something is a legal event. Build for the second one and the first comes along for free.
The protocol is good work. Read it for the delegated token and the allowance constraints, because that is the pattern to copy. Do not read it as permission to hand an agent a spending limit and declare the control finished. Your auditor will ask who approved the obligation, and the token will not answer.