CLOUDFLARE 2026-04-30

Cloudflare — Agents can now create Cloudflare accounts, buy domains, and deploy¶

Summary¶

A joint launch post from Cloudflare and Stripe (2026-04-30) announcing a new agent-provisioning protocol co-designed between the two companies. The protocol lets a coding agent take a human user from literal zero — no Cloudflare account, no domain, no API token, no payment method configured — to a production deployment on a newly-registered domain, without the human leaving their agent session. The flow is fronted by Stripe Projects (a CLI + plugin that ships as part of the Stripe CLI) acting as an orchestrator that attests to the user's identity and carries a payment token; Cloudflare is the first external provider in the launch but the protocol is deliberately generic — "any platform with signed-in users can integrate with Cloudflare in the same way Stripe does."

The three load-bearing components:

Discovery — stripe projects catalog returns a JSON catalog of services every participating provider exposes; the agent picks from the catalog what to provision. Cloudflare exposes its ~3,000-operation HTTP API surface via this catalog (so the catalog's "Cloudflare Registrar" entry and stripe projects add cloudflare/registrar:domain come from here, not from hard-coding).
Authorization — if the user's Stripe-logged-in email already has a Cloudflare account, a standard OAuth 2.0 consent flow grants the agent access. If not, Cloudflare provisions a new account automatically using the Stripe-attested identity and hands back credentials.
Payment — Stripe ships a payment token (not raw card data) in the provider request; Cloudflare bills against the token. Default agent spending cap is $100/month per provider, raiseable via Cloudflare's Budget Alerts surface.

The protocol builds on OAuth + OIDC + payment tokenization but composes them specifically to remove human-in-the-loop steps that previously gated agent autonomy: dashboard signup, API-token copy/paste, credit-card entry. Humans must still accept Cloudflare's terms of service and grant OAuth consent, but "no human steps are otherwise required from start to finish."

The post also announces that any platform with signed-in users can play the orchestrator role Stripe plays — a PlanetScale-on-Cloudflare existing integration is named as prior art that pre-dates the formal protocol, and Cloudflare + Stripe plan to publish a more formal specification together. A $100,000 in Cloudflare credits perk is offered to new startups who incorporate via Stripe Atlas.

Key takeaways¶

Agent-provisioning is a first-class new transaction shape, not a special case of agentic commerce or machine payments. Agentic commerce moves a human buyer's money for a human-consumable good (clothing, groceries). Machine payments move an agent's own budget for an API call. Agent provisioning moves a human user's money to stand up persistent cloud resources on their behalf — accounts, domains, compute subscriptions — producing long-lived artefacts (an account ID, a registered domain, an API token) the human now owns. Different failure modes, different cap requirements, different fraud surface. (Source: sources/2026-04-30-cloudflare-agents-can-now-create-cloudflare-accounts-buy-domains-and-deploy.)
The 3-component protocol — discovery + authorization + payment — is explicitly framed as co-equal with OAuth in ambition. "Similar to how the OAuth standard made it possible to delegate access to your account to other platforms, the protocol uses OAuth and extends further into payments and account creation, doing so in a way that treats agents as a first-class concern." See patterns/agent-provisioning-protocol for the three- component pattern and patterns/orchestrator-provider-agent-trust-triangle for the role structure it assumes.
Stripe plays the "orchestrator" role — the party that already has a signed-in user and can attest identity + carry payment. The protocol calls this the Orchestrator role generically; Stripe is the launch instance but Cloudflare explicitly frames any signed-in-user platform as a candidate orchestrator: "Let's say your product is a coding agent. Your platform acts as the Orchestrator, with the already signed-in user. When your user needs a domain, a storage bucket, a sandbox to give their agent, you make one API call to Cloudflare to provision a new Cloudflare account to them, and get back a token to make authenticated requests on their behalf." The orchestrator-provider-agent triangle is the canonical trust topology.
Discovery is a machine-readable service catalog published by each provider. The catalog is "arguably overwhelming to humans" but is "exactly the context [agents] need." Providers expose it via "a simple REST API that returns JSON." See concepts/provider-service-catalog-api. Composable with Code Mode's TypeScript-API framing of MCP tools (Cloudflare already fits its full 3,000-operation API into <1,000 tokens via Code Mode; the stripe projects catalog output is the orchestrator-side companion).
New accounts are auto-provisioned on demand — the "cold-start-to-production-in-one-shot" property is the headline UX win. If the user has no Cloudflare account, "Cloudflare will provision an account automatically for you and your agent" using Stripe's attested identity. No signup page, no email verification handshake, no dashboard trip. See concepts/agent-provisioned-account for the primitive.
Payment tokens (not credit-card data) are the payment rail. "Raw payment details like credit card numbers aren't ever shared with the agent." Stripe issues a payment token per provider request; the provider (Cloudflare) redeems the token against Stripe for actual billing. This is the credential-vault-preserving shape familiar from SPTs in agentic commerce but at a different altitude: SPTs move a buyer's money to a seller during checkout; agent-provisioning tokens move a user's money to a service provider across a subscription lifetime. See concepts/payment-token-over-credit-card-sharing.
A default $100/month-per-provider spending cap is a first-class protocol element. "Stripe sets a default limit of $100.00 USD/month as the maximum the agent can spend on any one provider." The cap is raiseable by the user; Cloudflare pairs it with a Budget-Alerts surface so the user can see usage against the cap without leaving the Cloudflare dashboard. This is the protocol's answer to "what if my agent goes a bit overboard" — agent autonomy is structurally bounded, not trust-based. See concepts/agent-payment-budget-cap.
Existing OAuth flows remain the path for pre-existing accounts. If the user already has a Cloudflare account keyed to their Stripe-logged-in email, the flow falls through to "a typical OAuth flow to grant the agent access" — consent is per-agent, scope-limited, auditable, and aligns with the framing canonicalised in RFC 9728 Protected Resource Metadata for agent-driven consent.
The integration shape generalises the partner-managed native binding pattern to full account + billing lifecycle. Previously Cloudflare integrated partners (PlanetScale for Postgres, Tigris at Fly.io) by making provisioning + billing happen at the platform boundary, with the customer consuming the partner's service through platform-native bindings. The new protocol inverts the direction: a third party's signed-in-user platform can provision Cloudflare resources (domains, buckets, sandboxes) directly on that third party's behalf. Cloudflare can be either end of the triangle. "Cloudflare is partnering with PlanetScale to make it possible to create PlanetScale Postgres databases directly from Cloudflare... We started working with PlanetScale on this well before this new protocol got off the ground, but the flow here is quite similar."
Protocol + Code Mode MCP server + Agent Skills compose into the full agent-provisioning stack. Code Mode compresses the 3,000-operation Cloudflare API into <1,000 tokens so the agent knows what it can call; Agent Skills give task-level how-to prose so the agent knows how to do a specific task; the new protocol gives the agent an account and money to do those tasks with. Each solves a different altitude of the agent-autonomy problem; none substitutes for the others.

Architectural components¶

The trust triangle¶

          ┌────────────────┐
          │    Orchestrator│  ← Stripe (via Stripe Projects)
          │  (signed-in    │    or any platform with signed-in
          │   user + pay)  │    users (coding agents, IDEs, ...)
          └─┬──────────────┘
            │ attests identity +
            │ carries payment token
            ▼
  ┌───────────────┐            ┌────────────────┐
  │    Provider   │◄───────────│      Agent     │
  │  (Cloudflare  │ catalog +  │ (driven by the │
  │    / R2 / ... │ resource   │  user's prompt)│
  │    / domains) │ API calls  │                │
  └───────────────┘            └────────────────┘

Orchestrator — has the signed-in user; attests identity; routes payment tokens.
Provider — exposes a service catalog; provisions resources; redeems payment tokens against the orchestrator's billing rail.
Agent — discovers services, authorizes via the orchestrator, provisions and consumes resources.

Discovery¶

Command: stripe projects catalog
Returns: JSON list of available services across all participating providers.
Providers expose their own catalog feeds via "a simple REST API that returns JSON."
Cloudflare's catalog entries map to the Cloudflare service directory (Workers, R2, Registrar, etc.).

Authorization¶

Two sub-paths:

No existing provider account → provider auto-creates one from the orchestrator's attested identity; credentials are returned to the orchestrator CLI (not directly to the agent), securely stored, and made available to the agent for authenticated provider calls.
Existing provider account → standard OAuth 2.0 consent flow drives the user through a per-agent scope grant.

Payment¶

Orchestrator includes a payment token in the resource- provisioning request.
Provider redeems the token against the orchestrator's billing backend.
Spending is capped by default ($100/month/provider via Stripe Projects); cap is raiseable.
Budget Alerts on the Cloudflare side expose the cap + spend against it.

End-to-end flow (domain registration example)¶

User installs the Stripe CLI with the Stripe Projects plugin.
User runs stripe projects init.
User prompts their agent to build and deploy something on a new domain.
Agent runs stripe projects catalog → discovers cloudflare/registrar:domain as an available service.
Agent runs stripe projects add cloudflare/registrar:domain.
Stripe Projects either:
Prompts an OAuth consent flow (existing Cloudflare account) → receives an access token;
Or auto-provisions a new Cloudflare account using the Stripe-attested identity → receives credentials.
Stripe Projects sends a payment token to Cloudflare to initiate a paid subscription (domain registration costs money; payment is charged against the token via Stripe).
Agent uses the returned API token to deploy code on Workers to the newly- registered domain.
If the user's Stripe account has no linked payment method, the agent surfaces a prompt asking the human to add one.

Numbers disclosed¶

Default spending cap: $100.00 USD/month per provider (Stripe-side default; user-adjustable).
Cloudflare API surface: ~3,000 HTTP operations (context for why agent-friendly discovery matters).
Startup perk: $100,000 in Cloudflare credits for new startups incorporating via Stripe Atlas.

Not disclosed: per-provider onboarding latency, token TTL / refresh cadence, catalog update frequency, fraud-signals reuse from Stripe Radar, account-takeover threat model for auto-provisioned accounts, multi-agent-per-account consent model.

Caveats¶

Launch post density. The post is primarily a product announcement + partnership launch. Mechanism disclosure is high-level ("Cloudflare automatically provisions a new account", "securely stored, but available to the agent") without the protocol-level detail a full spec would have. Cloudflare + Stripe explicitly plan a "more official specification soon." This source canonicalises the shape and the vocabulary; future ingests on the formal spec will extend the mechanism sections.
Threat model unstated. Auto-provisioning accounts keyed to third-party-attested identity is a new account-takeover surface. The post doesn't address: what happens if the Stripe email is attacker-controlled; what the dispute / recovery path looks like; how Cloudflare distinguishes an orchestrator-attested identity from a direct-user registration for abuse scoring.
Spend-cap robustness unstated. The $100/month cap is described as default + user-adjustable; the post doesn't cover how the cap is enforced on the provider side (is it Cloudflare's responsibility to reject a charge over cap, or Stripe's to refuse to emit a token, or both), or what happens on token replay, double-spending across providers, or mid-cycle increases.
Only one non-Stripe orchestrator example. The PlanetScale case is cited as prior art "quite similar" in flow but predates the formal protocol; the post doesn't disclose whether PlanetScale intends to migrate to the protocol or whether other orchestrator candidates are in flight.
"Code Mode MCP server" and "Agent Skills" are framed as complementary but their integration with the protocol is sketched, not specified ("with Cloudflare's Code Mode MCP server and Agent Skills, they're even better at it"). Composition detail deferred to the formal spec.

Extracted entities¶

Systems¶

Stripe Projects — CLI + plugin from Stripe that plays the orchestrator role in the protocol. Open beta at launch. Ships as part of the Stripe CLI. Bootstrapping flow: stripe projects init → stripe projects catalog → stripe projects add <provider>/<service>.
Cloudflare Registrar — Cloudflare's domain-registration service; the launch-post exemplar of a paid service the agent provisions for the user. Accessed from the agent via stripe projects add cloudflare/registrar:domain.
Code Mode — Cloudflare's MCP surface that converts tool schemas to TypeScript APIs; the Code Mode MCP server is named as the companion surface for agents calling Cloudflare APIs "even better at it" after the agent has provisioned access via the new protocol.
Agent Skills — Cloudflare's task-instructional document standard for agents; named as the how-to-at-task-altitude complement to the what-can-I- do discovery the catalog provides.
Workers — the canonical deploy target referenced in the post ("deploy code right away," "ship to production"). The full value of the protocol is Workers + Registrar + other Cloudflare services as a production substrate the agent provisions without the user touching the dashboard.
PaymentIntents — Stripe's payment primitive; referenced indirectly as the mechanism carrying the payment token that funds the provider subscription.
PlanetScale — named prior art for the cross-platform integration shape; pre-protocol but "quite similar" in flow.

Concepts¶

concepts/agent-provisioned-account — an account at a cloud provider that is created on-demand by an agent on behalf of a user, keyed to a third-party-attested identity, without the user ever visiting the provider's signup page.
concepts/provider-service-catalog-api — a machine- readable JSON catalog of services a provider offers, exposed at a stable REST endpoint and aggregated by orchestrators for agent consumption.
concepts/agent-payment-budget-cap — a default-on ceiling on agent-initiated spending per provider, enforced by the orchestrator during token issuance and surfaced by the provider against usage.
concepts/payment-token-over-credit-card-sharing — the principle that raw card data never reaches the agent; the agent holds only a scoped, redeemable token that the provider exchanges with the orchestrator for settlement.
concepts/oauth-protected-resource-metadata — RFC 9728; the wire shape for an agent driving a user through OAuth consent against a provider. The protocol's authorisation sub-path for existing accounts aligns with this concept.
concepts/agentic-commerce — sibling concept: human-buyer → agent → seller, for human-consumable goods. Agent-provisioning is distinct: user → agent → provider, for cloud-infrastructure lifecycle.
concepts/machine-payment — sibling concept: agent → API per-request, no human buyer. Agent-provisioning is distinct: agent → provider for subscription / resource lifetime, with the human still on the hook for billing.

Patterns¶

patterns/agent-provisioning-protocol — the discovery + authorization + payment three-component shape this post canonicalises.
patterns/orchestrator-provider-agent-trust-triangle — the role topology assumed by the protocol: orchestrator attests identity + holds payment; provider exposes catalog
redeems payment; agent drives discovery + consumption.
patterns/partner-managed-service-as-native-binding — generalised by the protocol to full account + billing lifecycle; previously Cloudflare-provisioned partners (PlanetScale, Tigris) now has a bidirectional framing.

Cross-source continuity¶

Cloudflare agent-platform axis: this is the 2026-04-30 addition to the Cloudflare agent-platform arc that spans Agent Lee (2026-04-15) + Cloudflare CLI via Code Mode (2026-04-13) + internal AI engineering stack (2026-04-20) + Agent Readiness Score (2026-04-17) + Project Think (2026-04-15). Each addresses a different slice of agent-autonomy-at-the-cloud-edge: Code Mode compresses the API surface; Agent Skills document how to use it; Agent Readiness Score / llms.txt / MCP Server Cards expose site capabilities at discovery time; the new protocol closes the loop by letting the agent acquire access to the platform without human gating.
Stripe agentic-commerce axis: sibling to Stripe's first ACP retrospective (2026-03-12). The ACP post defined SPTs / machine payments / protocol-agnostic commerce for human-buyer-money-to-seller. This post adds the user-money-to-service-provider third altitude — cumulatively, Stripe is now the canonical venue for a three-altitude taxonomy of agent-initiated money movement: (a) agentic commerce (human buyer's money, seller); (b) machine payments (agent's own budget, API); (c) agent-provisioning (human user's money, service provider).
Partner-managed binding axis: third canonical post for patterns/partner-managed-service-as-native-binding after the PlanetScale-Postgres Workers integration (2026-04-16) and the PlanetScale/Hyperdrive demo (2026-04-21). The partner pattern pre-dates the formal protocol; the protocol generalises it by making orchestrator/provider roles swappable rather than Cloudflare-anchored.