This post covers new infrastructure. The security section is the part worth slowing down for.
What’s New This Week
Stripe launched the Machine Payments Protocol (MPP) this week, co-authored with Tempo. Early access is open. Browserbase, PostalForm, and Stripe Climate are among the first live integrations. The spec covers microtransactions, recurring payments, stablecoins, and fiat – all wired into existing Stripe infrastructure.
Changelog
| Date | Summary |
|---|---|
| 18 Mar 2026 | Initial publication. |
Stripe launched the Machine Payments Protocol this week. The announcement is deliberately pragmatic: a few lines of code, existing PaymentIntents API, works with stablecoins and fiat. You can apply for early access today. The launch partners include Browserbase for per-session browser spin-ups, PostalForm for agents that send physical mail, and Stripe Climate for programmatic carbon contributions.
The implication is larger than the announcement. This is the first serious attempt to give AI agents a first-class payment primitive – built on top of infrastructure that’s been notionally reserved in the HTTP spec since 1996 and on a payment platform that processes hundreds of billions of dollars a year. Agents are becoming economic actors. The tooling to support that is arriving faster than the security thinking around it.
What MPP Does
The flow is straightforward: an agent requests a resource from a service or API endpoint. The service responds with a payment request. The agent authorises. The resource is delivered. No browser, no session cookie, no human clicking a button.
MPP is co-authored by Stripe and Tempo and lives alongside x402 – a related protocol that implements the same idea at the HTTP layer. An agent requests an HTTP-addressable resource. The server responds with a 402 Payment Required. The agent pays. The resource is served. Payment method can be stablecoins or fiat (including cards and buy-now-pay-later).
The underlying Stripe infrastructure applies throughout: fraud protection, tax calculation, accounting integrations, refunds, reporting. MPP isn’t a new payment rail – it’s a machine-readable negotiation layer on top of existing Stripe infrastructure, using PaymentIntents and Shared Payment Tokens (SPTs) for agent identity and authorisation.
Parag Agrawal, founder of Parallel Web Systems, put it plainly: “Parallel is built for a world where agents are the primary users of the web. We integrated machine payments with Stripe in just a few lines of code, and now agents can autonomously pay per API call for web access.”
Before MPP, that sentence required either pre-paid API credits, human-in-the-loop payment approval, or browser automation hacks. Now it’s a protocol.
The Per-Call Economics
The Browserbase integration is the most concrete example of what changes here. Before MPP, billing a headless browser session to a specific agent required either a subscription, a bulk credit system, or custom instrumentation on both sides. With MPP, an agent spins up exactly one session, pays for it, and that’s the transaction. No subscription overhead, no credit management, no reconciliation problem.
This unlocks per-unit economics for agent services that were previously unworkable to offer. If the unit of value is a single browser session, a single physical mail send, a single API call – you can now price and bill at that granularity without either party building custom payment infrastructure.
The Stripe Climate example is trivial in dollar terms but illustrative: an agent making a small climate contribution automatically. That’s a microtransaction that would have required either rounding up to a monthly batch or building a custom micro-billing system. Now it’s one API call with a payment response.
Stripe’s framing is that agents represent “an entirely new category of users to build for.” That’s correct, and the implications aren’t obvious. Human payment flows are optimised for conversion: minimise friction, reduce steps, A/B test the button colour. Agent payment flows need to optimise for a completely different set of properties: machine-readable pricing, deterministic authorisation, immutable audit trail, fraud detection that works on automated behavioural patterns rather than human signals. MPP is early infrastructure for that different optimisation target.
The HTTP 402 Backstory
HTTP 402 “Payment Required” was defined in the original HTTP/1.0 specification in 1996. It was explicitly marked “reserved for future use.” The intent at the time was paywalled content – a status code that would let servers say “pay first, then I’ll serve this resource.” For 30 years, 402 existed in every HTTP spec, was recognised by every HTTP client, and was never formally implemented.
x402 is the first serious attempt to implement the original intent. The interesting part is that the use case that finally made it happen wasn’t paywalled journalism or premium APIs. It was AI agents. The infrastructure needed for autonomous machine payments – deterministic flows, no human in the loop, machine-readable negotiation – is exactly what makes 402 finally make sense.
The web was designed with the assumption that a human was on the other end. Payment flows, CAPTCHA, cookie consent, login flows – all of it assumes a person. x402 and MPP are among the first infrastructure pieces explicitly designed for the other case: the machine is the user.
Prompt Injection Meets Autonomous Payments
Here’s the security thread, and it’s worth being direct about.
Agents can be manipulated via prompt injection. This is well-documented and not a theoretical concern – it’s a known attack vector that’s actively exploited. I’ve written about it before. An adversarial instruction embedded in a webpage, document, API response, or tool output can redirect an agent’s behaviour in ways the operator didn’t intend.
MPP gives agents the ability to make payments autonomously. If both things are true – and they are – then prompt injection becomes a direct financial attack vector. An instruction embedded in a document the agent is processing could tell it to make a payment to an attacker-controlled endpoint. The agent executes. Money moves. No human saw it happen.
This isn’t speculative. The combination of autonomous action and financial capability is exactly the attack surface that makes financial manipulation via agent infrastructure worth taking seriously. MPP doesn’t create the prompt injection problem – that existed already. It upgrades the consequences from “agent does something unexpected” to “agent spends money unexpectedly.”
The mitigations are not exotic. They’re the standard fraud controls that exist for human payment systems, applied to agent infrastructure:
- Per-agent spend limits, enforced at the infrastructure level
- Human approval gates above a threshold – not just logging, actual approval
- Immutable audit logs of all payment events
- Anomaly detection on spending patterns
None of these are built into MPP by default. You build them, or you don’t have them.
What Authorisation Should Look Like
Stripe’s existing infrastructure handles a lot of this for human payments: velocity limits, fraud signals, dispute resolution. The open question is what the equivalent looks like for agent payments, where the behavioural signals are completely different.
A human making an unusual payment might trigger a velocity check or a geographic anomaly flag. An agent making unusual payments might look identical to an agent making normal payments – fast, automated, pattern-consistent – because the anomaly is at the prompt level, not the payment level.
The authorisation model for agent payments needs to be more explicit than for human payments, precisely because the agent isn’t going to notice something is wrong. Least-privilege and explicit permission scoping matter more here than anywhere else in agent infrastructure. An agent should have the minimum payment capability it needs. A research agent has no business with payment capabilities at all. A purchasing agent needs strict per-transaction and per-day limits.
The threshold for human approval should be set conservatively at first. Logging that an agent spent $50 is not the same as requiring approval before an agent spends $50. Until you have enough operational experience with how your agents actually behave in production – including under adversarial conditions – approval gates are cheaper than incident response.
Before You Integrate
MPP is early access and the developer experience looks straightforward. Before you wire it up to a production agent, think through:
Spend limits. Define them per-agent, per-session, and per-day. Enforce at the infrastructure level, not in the agent’s instructions. An agent that’s been compromised will ignore its own instructions. Infrastructure limits don’t.
Approval thresholds. Decide what amount triggers human review. Set it lower than you think is necessary until you have production data. You can always raise it. Recovering from an agent that spent $10,000 because a document told it to is harder than explaining to a user why their agent needed approval.
Audit logging. Log every payment event. Log the context that led to it – what the agent was doing, what prompted the payment, what the response was. Log immutably. You will need this for incident investigation.
Permission scoping. Treat payment endpoints as high-privilege actions in your agent’s permission model. Most agents don’t need them. The ones that do need them scoped tightly.
Blast radius. Think through what happens when an agent is compromised or manipulated. With no payment capability, the blast radius is “agent does something wrong with data.” With payment capability, the blast radius includes real money. Size the controls accordingly.
The Larger Picture
The agentic turn – agents moving from assistants that answer questions to infrastructure that takes actions – is already underway. MPP is one more piece of that shift becoming concrete. Agents that can autonomously acquire resources, pay for services, and execute multi-step workflows without human supervision are not a future state. They’re being built right now.
The infrastructure is arriving. The security frameworks haven’t caught up. That gap is where the incidents will come from.
HTTP 402 waited 30 years for a use case. It got one. Make sure your authorisation model is ready for what comes next.