The policy layer above the rails
Stripe shipped 288 launches at Sessions 2026. The rails for agent payments are done. The next ten years gets won at the layer above — the manifest that decides which scopes get minted, which inputs trigger them, and which human signed off.
On April 29, 2026, Stripe shipped 288 launches at Sessions. The Patrick-Collison line was "If AI can solve Nobel-level physics problems but can't buy a domain, something's gone wrong." The Agentic Commerce Suite went live with URBN, Etsy, Coach, Kate Spade, Ashley Furniture, and a dozen others. The Machine Payments Protocol shipped with Tempo. Visa Intelligent Commerce Connect followed on April 8. Mastercard Agent Pay's first live European transaction settled March 2.
By the time you read this, the rails are commodity.
Cards, BNPL, stablecoins, Visa, Mastercard, Affirm, Klarna — all behind one Stripe SPT primitive that abstracts every issuer behind a three-field token. The integration question — how does my agent move money — is solved. You will not win 2027 by picking the right rail.
You will win it at the layer above.
What Stripe actually shipped
The SPT spec is worth reading literally, because the smallness of it is the point.
{
"id": "spt_123",
"object": "shared_payment.granted_token",
"created": 1751500820,
"deactivated_at": null,
"deactivated_reason": null,
"usage_limits": {
"currency": "usd",
"expires_at": 1781423908,
"max_amount": 1000
}
}
Three fields scope the grant: currency, max_amount, expires_at. Five webhook events observe its lifecycle. One POST to /v1/shared_payment/issued_tokens/{id}/revoke kills it. Cards, Link, Apple Pay, Google Pay, Klarna, Affirm — all sit behind it.
Stripe's own explanation of how this composes with the card networks is the load-bearing quote: "You interact only with SPTs, while Stripe handles the complexity of provisioning agentic network and BNPL tokens behind the scenes."
That sentence is the whole story. The rails are converging on a single, three-field primitive. Whoever wins the rails wins the rails. They do not win the agent economy.
An SPT is a 3-field token solving a 30-field problem. Currency, amount, expiry — but not which agent, which workflow, which input triggered the spend, which human signed off, or which kind of merchant counts as "in scope." The token is the request. The policy is what should have decided the request was OK to make.
The exploit that proved the point
On May 8, someone drained roughly $150,000 from Bankrbot — a Grok-powered crypto agent — through a Morse-coded prompt injection on X. An NFT delivered to the bot's wallet had earlier escalated its permissions to "Executive." The Morse-decoded instruction said withdraw all DRB to an attacker address. The bot decoded it. The bot executed. The funds were gone.
The Stripe rails would not have changed the outcome by themselves. The wallet had unscoped authority. There was no SPT, no time bound, no merchant scope, no human approval gate. The attack went through every layer below the policy layer cleanly, because the policy layer was the empty string.
This is the failure mode the agentic commerce era is about to repeat at scale. The rails are robust. The policy on top of them is whatever an engineer typed into a function call last week.
Who is building the policy layer
Most of the framework vendors aren't. The Stripe Agent Toolkit ships for LangChain and CrewAI, but only as wrappers around Stripe primitives — tool-call functions for "issue invoice," "send payment reminder." No native policy layer. Vellum has a positioning piece on Google AP2 and stays protocol-agnostic. AutoGPT and Mistral have no notable 2026 commerce posture at all.
The platforms that are building the policy layer are doing it differently:
- Anthropic went human-in-the-loop. Claude for Small Business, May 13, ships 15 agentic workflows with PayPal handling settlements, and an explicit approval gate: "Claude does the work while you approve before anything sends, posts, or pays."
- Mastercard went merchant-side, partnering with Cloudflare on Web Bot Auth (RFC 9421) to cryptographically prove which agent is calling.
- Google's AP2 uses Verifiable Credentials — cryptographically signed digital contracts called Mandates — to encode user intent as a proof the merchant can verify.
None of these are competing with the rails. They are competing with each other for the policy contract above the rails.
The Prix take
Our inside-agent-sandboxes post argued the manifest is the security boundary. The manifest already declares network:, tools:, filesystem:, shell:. Adding a payments: block is a one-line extension to a contract the runtime is already enforcing:
name: shopping-deputy
permissions:
network:
- api.stripe.com
payments:
max_amount_usd: 500
per_merchant: 200
per_session: 1
requires_user_approval_above: 100
allowed_merchants:
- powdur.com
- etsy.com
duration: 4h
When the agent attempts a charge, the runtime checks the manifest before an SPT is even minted. The manifest decides which scopes are eligible to be requested. The user signs an approval for the specific charge that falls inside the manifest. Stripe issues the SPT against the approved scope. The rails fire.
The interesting clause is requires_user_approval_above: 100. Below the threshold, the agent is autonomous within the bounded grant. Above it, the human is in the loop. The threshold is a declared field in the manifest, signed at publish, observable through the same audit trail that already exists for network and shell.
This is what the Grok exploit needed and didn't have. A Morse-coded instruction to "withdraw all DRB" would have failed at the manifest layer before any token was minted, because no manifest with a payments: block declares any-merchant, any-amount, any-reason.
The other half of the story
There is a secondary thread worth pulling, because most of the analytical mass in 2026 is going to "agents buying things." The bigger dollar flow is the other direction.
Anthropic's Project Deal ran an internal marketplace where 69 Claude agents negotiated 186 deals worth roughly $4,000 in total. The finding everyone skipped: agents using Opus consistently extracted $3.64 more per item than agents using Haiku. The humans whose agents were weaker got worse prices. They never noticed.
That is the merchant-side question, and it is where the real dollars in agentic commerce will land. Which agent is on the other side of my call? Is it representing a real customer with real intent? Is the prompt it just executed coming from the user or from an injection I cannot see? Mastercard partnered with Cloudflare on Web Bot Auth for exactly this reason — RFC 9421 cryptographic identity for the agent making the request.
The rails are done. The policy layer at the buyer's runtime is one fight. The trust contract at the merchant's gateway is the other. Both sit above the SPT.
What to take away
If you are building an agent that spends money in 2026:
- Pick whichever rail. They are converging. Stripe SPT, Mastercard Agent Pay, Visa Intelligent Commerce Connect, Tempo for sub-cent metering — they are interoperable, they are commoditizing, and Stripe is already abstracting them behind one primitive.
- Declare your spend envelope in the manifest, not the function call. Per-merchant cap, per-session cap, approval threshold, allowed-merchant list, max session duration. Sign it at publish. Enforce it at the runtime.
- Make the user-approval gate a first-class boundary, not a UI feature. It belongs in the manifest, observable through audit, enforceable at the syscall layer that mediates between agent and rails.
The Machine Payments Protocol is going to be the HTTP of the agent economy. Everyone will speak it. The 2027 winners will be the platforms whose policy layer above MPP is good enough to ship to a Fortune 500 legal team and have them sign off.
The rails are commodity. The contract is not. Build the contract.