Agentic commerce, and what breaks in it
Agentic commerce is commerce where the buyer is software acting for a person or a business. An agent researches, chooses and pays, and nobody is at the checkout. Almost everything that made the previous arrangement safe assumed somebody was.
What actually changes
The authority is delegated, and thin. A person told an agent to do something, once, in words. Everything the agent then buys traces back to that instruction, and the instruction did not enumerate merchants, amounts or a stopping condition. The gap between what was meant and what the agent is technically able to spend is the whole problem.
The pace is wrong for review. A person notices an odd charge in a day or two. An agent can make a hundred payments in the time it takes to notice the first, so any control that works by someone looking at a statement has already failed.
The failure modes are new. A retry loop that pays four times for one thing. A quote whose ceiling gets signed instead of its price. A mandate that was scoped to one merchant being spent at another. None of these has a card-rail equivalent, so none of them is in a card fraud model.
The anomalies invert. Machine speed, odd hours, tiny amounts, counterparties discovered seconds ago: every one of those is a fraud signal for a human buyer and a Tuesday for an agent. A model trained on people will flag the ordinary and miss the catastrophic.
$320.00, procurement-agent to supplier.example.com, on AP2.
The rails
Two protocols are doing most of the work, and they solve different halves.
Payment negotiated over HTTP 402: the server quotes what it wants, the client pays and retries the request with a signed payment payload.
Introduced by Coinbase in 2025 as an open HTTP payment scheme.
Agent Payments Protocol: the user's authority travels with the payment as signed mandates, so a merchant can tell what the human actually approved.
Published by Google with payment-network and merchant partners in 2025.
Neither rail decides whether a payment is a good idea. x402 makes a payment negotiable over HTTP; AP2 makes the user’s authority legible to a merchant. Whether this agent should spend this much, here, now, is a question both leave open, which is the question Spend7 answers.
What a control layer has to do
- 1. Sit outside the agent. A budget the agent can read is a budget the agent can reason its way around. Caps belong in a service the agent calls, not in the context it was given.
- 2. Decide before settlement. After the money moves there is nothing left to decide, only to dispute. The check has to be in front of the payment, in the path, fast enough to stay there.
- 3. Know this agent, not agents in general. $400 is alarming for one agent and routine for another. The baseline has to be per agent, and when there is not enough history to have one, it has to say so rather than treat an unknown as a normal.
- 4. Read the protocol. The most checkable failures are the ones the rail itself makes visible: a cart mandate that overran its intent mandate is not a judgement call, it is an invariant that broke.
- 5. Leave a record. Written before the payment settles, not reconstructed after it goes wrong.
Questions
- What is agentic commerce?
- Commerce where the buyer is software acting for a person or a business: an agent that researches, chooses and pays without a human at the checkout. It needs new payment rails because the existing ones assume a person is present, and new controls because the assumptions that made card fraud detection work do not hold when the buyer is a program.
- What are x402 and AP2?
- The two rails agentic payments are converging on. x402 negotiates payment over HTTP 402: the server quotes what it wants, the client pays and retries with a signed payload. AP2 carries the user's authority as signed mandates so a merchant can tell what a human actually approved. They solve different halves of the problem and Spend7 checks both.
- Why can't existing fraud tools handle agent payments?
- They model how people buy. Agents transact at machine speed, at any hour, in amounts and patterns that look anomalous for a human and are routine for a program, while the failures that should alarm you, like a retry loop or a mandate that outgrew its scope, have no equivalent on a card rail for those tools to have learned.
- What does Spend7 actually do?
- It scores a payment intent before the money moves and returns allow, flag or deny with the reasons. It holds the spend caps so they live outside anything the agent controls, it checks the rail-specific invariants on x402 and AP2, and it records every decision so a disputed payment has an evidence trail.