Cloudflare and Stripe just let agents buy domains and ship code. Here is the API.

On April 30, Cloudflare quietly published a blog post and a docs page that nobody outside the agentic AI crowd noticed for about 24 hours. The headline buried a real shift. AI agents can now provision a Cloudflare account, register a domain, attach a Stripe payment method, deploy a Worker, and hand you back a live URL. With a single CLI command. With no human in the loop after you accept terms and add a card.

Stripe Projects is the open beta side. The Cloudflare Agents SDK is the runtime side. The protocol underneath is called Machine Payments Protocol (MPP), co authored by Tempo Labs and Stripe, with x402 (HTTP 402 Payment Required) doing the actual money plumbing. The whole thing went live this week.

This is the first time the major infra players have published a real specification for "agent buys thing, deploys thing, pays for thing" without manual intervention. The spec is short. The implications are not.

TL;DR

Capability	Who provides it	What it costs
Agent provisions Cloudflare account	Cloudflare Agents SDK	Free in beta
Agent registers domain	Cloudflare Registrar via MPP	At cost, $100/month default cap
Agent attaches payment	Stripe Projects	Card on file at parent Stripe account
Agent deploys Worker, Pages, R2	Workers platform	Per usage, agent metered
Spending guardrail	Per provider cap, default $100/month	Caller controls

1. The protocol in one paragraph

Three components. Discovery is a REST/JSON catalog where each provider publishes what an agent can buy from them and at what price. Authorization uses identity attestation plus OAuth, so the agent calls under a delegated identity scoped to your Stripe project. Payment uses tokenization through Stripe with a default $100/month per provider spending cap, which you can raise or lower per project.

That is the whole protocol. The cleverness is that x402 turns "you owe money for this API call" into a normal HTTP response status. The agent sees a 402, looks up the price, decides if it can pay, and either pays or asks for a higher cap. No new wire format. No new auth scheme. Just HTTP.

2. The CLI command that started it

stripe projects init my-side-project

That command does five things in sequence:

1. Creates a Stripe Project (a sandboxed sub account scoped to one agent run)
2. Provisions API credentials and an OAuth token for the agent
3. Connects the project to your Stripe account's payment methods
4. Sets a default monthly spend cap (you override with --cap 200)
5. Outputs a .stripe-project.json that the Cloudflare Agents SDK reads

After that, an agent calls Cloudflare with the OAuth token, gets a workers account, registers myproject.dev, deploys a Worker, and emits the live URL. End to end, in the demos, around 90 seconds.

3. The code an agent runs

Here is roughly what the Cloudflare Agents SDK invocation looks like for an agent that builds and deploys a small TypeScript service. I have stripped error handling so the shape is visible.

import { CloudflareAgent } from "@cloudflare/agents-sdk";
import { StripeProjectAuth } from "@stripe/agents";

const auth = await StripeProjectAuth.fromEnv();
const cf = new CloudflareAgent({ auth });

// 1. Get or create an account
const account = await cf.accounts.ensure({ name: "demo-account" });

// 2. Buy a domain (this hits MPP under the hood, returns 402 first call)
const domain = await cf.registrar.purchase({
  name: "my-side-project.dev",
  budgetUsd: 12, // hard ceiling for this call
});

// 3. Deploy a Worker with the source
await cf.workers.deploy({
  account: account.id,
  name: "hello",
  script: `
    export default {
      async fetch(request) {
        return new Response("hi from an agent");
      }
    };
  `,
  routes: [{ pattern: `${domain.name}/*`, zone_id: domain.zone_id }],
});

// 4. Tell the human
console.log(`live at https://${domain.name}/`);

Three points worth pulling out.

The budgetUsd parameter is per call. The Stripe Project's monthly cap is the global ceiling. So you have two layers: a per request budget (so the agent cannot accidentally spend $50 on a single domain it should not have bought) and a per provider cap (so the agent cannot spend more than $100 in a month total at Cloudflare). Both are enforced server side on Stripe's end. The agent cannot bypass them by editing client code.

The OAuth token from StripeProjectAuth.fromEnv() is scoped to the project. If you revoke the project, the token dies. There is no way for the agent to reach into your main Stripe account or your other projects.

The MPP 402 flow is invisible in the snippet above. Behind the scenes, the SDK retries the registrar call with a payment authorization header after seeing the 402. You can hook into that with a onPayment callback if you want a confirmation step. Most agents will not.

4. Where the safety story is real and where it is not

Real:

• The $100 default cap is server enforced. Agent cannot raise it from inside the agent runtime.
• OAuth scoping is per project, not per Stripe account. Compromise of a single agent run does not reach your other money.
• The budgetUsd per call is a hard ceiling, not a hint.
• Stripe ledger logs every cent. You see exactly which agent run spent what.

Not real:

• The agent can still loop. A buggy agent that calls domain.purchase in a retry loop will hit the cap, but it will hit it fast. The cap stops the bleeding, not the bug.
• The agent decides what to deploy. If the prompt was "build me a phishing kit", the agent will buy a domain and deploy a phishing kit. Cloudflare and Stripe screen for known abuse patterns, but the threat model is "agent acting on a legitimate user's behalf for an illegitimate purpose" and that is not solved.
• The "stripe projects init" gives the agent a card. You authorized that card. If you give the agent a card that is also your personal card, the agent can spend up to the cap on stuff you would not have bought.

The mitigation pattern that works today: create a Stripe Project per agent run, attach a virtual card with a $100 balance, give the agent the project, and burn the project when the run finishes. You can script this in 10 lines.

5. What this changes in practice

Three things become possible that were not yesterday.

Agents that can finish. Most coding agents today produce a PR or a local file and stop there because deploying needs human credentials. With this, the agent can ship. That changes how you think about iteration: the loop is no longer "agent writes code, human deploys, human tests" but "agent writes, agent deploys, human reviews live".

Cost as a programmable signal. The 402 response with a price is data the agent can reason about. An agent that wants to register a domain can compare prices across registrars and pick the cheapest. An agent that needs storage can decide between R2 and S3 based on the per request fee. This is the first time price has been a first class API parameter in a way agents can actually use.

Per agent budgets as a defense layer. Today most teams running agents in production have a single API key with a monthly cap on the underlying model provider. With this, you can give each agent run its own scoped budget across compute, storage, and DNS at the same time. That is a much sharper control than you had before.

At Glincker we wired this in last night

Our internal agent that drafts and tests code for our content engine now has its own Stripe Project with a $25 weekly cap. It can register subdomains for staging tests, deploy preview Workers, and tear them down when the test finishes. Before, those steps required a human to provision and manually delete. The cap is the only thing standing between us and a runaway loop, and so far the cap has done its job.

The thing I was nervous about before flipping it on was a buggy retry loop burning $25 in 30 seconds. That has not happened, but I want to log a few hundred runs before I trust it. If you do this, log every 402 and every successful payment with the agent run ID. You will catch the loop the first time it happens.

The bottom line

This is the first agentic payment protocol from infrastructure providers that ships with real guardrails and a real spec. The spec is small enough to read on a Tuesday lunch. The implementation already works. The cap is not a substitute for thinking about the threat model, but it is a real cap.

If you build with agents, this is a control plane you have wanted for a year. If you do not, the existence of this protocol is a sign that the question "should agents spend money" has officially shifted to "how do we put the right limits on what they spend".

What are you about to give an agent a card for? I want to read the answer in the comments.

---

GDS K S · thegdsks.com · building Glincker · follow on X @thegdsks

Agents with a card change the threat model from "what can it do" to "what can it spend before you notice".