PATTERN Cited by 1 source

Agent provisioning protocol¶

Intent¶

Let an agent take a user from literal zero at a cloud provider — no account, no payment method, no API token — to a production deployment on that provider, without the human leaving the agent session. The protocol composes OAuth 2.0, OIDC, and payment tokenization into three co-operating components so that a third- party orchestrator with a signed-in user can attest identity and fund subscriptions at external providers on that user's behalf.

Context¶

Until 2026, cloud-provider onboarding gated agent autonomy at three separate human-in-the-loop steps:

Signup: user visits a dashboard, confirms email, accepts terms, picks plan tier.
Authentication for the agent: user copies an API token from the dashboard, pastes it into the agent's config.
Payment setup: user enters a credit card on the provider's billing page.

Each step breaks the agent's autonomy loop; none is protocol-mediated. The agent-ergonomic answer is to collapse the three into a protocol the agent can drive end-to-end, with the human limited to explicit consent + payment-source grants that happen at the orchestrator altitude, not per-provider.

Relevant when:

A platform already has signed-in users with a payment method on file.
An agent needs to provision resources at external providers on those users' behalf.
The resources are long-lived (accounts, domains, paid subscriptions) — not per-request API charges (which is what concepts/machine-payment rails solve) and not human-consumable-goods checkouts (which is what concepts/agentic-commerce rails solve).

Solution¶

The protocol has three components. Each builds on existing IETF / OAuth standards but is composed specifically to remove human-gating from agent-driven provisioning.

1. Discovery¶

Each provider exposes a service catalog — a machine-readable JSON feed listing the services the provider can provision for agents. The orchestrator aggregates provider catalogs and exposes a single command to the agent:

<orchestrator-cli> catalog  →  [
  { provider: "cloudflare", service: "registrar:domain", ... },
  { provider: "cloudflare", service: "workers:compute",  ... },
  { provider: "<other>",    service: "<other>",          ... },
  ...
]

The agent reads the catalog to pick services to provision. See concepts/provider-service-catalog-api for the catalog primitive.

2. Authorization¶

The orchestrator holds the signed-in user's identity (typically an OIDC email + subject claim). Two sub-paths on provisioning:

No existing provider account — the orchestrator attests the user's identity to the provider. The provider auto-creates a new account keyed to that identity and returns credentials to the orchestrator. The user has never visited the provider's signup page. See concepts/agent-provisioned-account.
Existing provider account — standard OAuth 2.0 consent flow, aligned with RFC 9728: provider responds 401 with a Protected-Resource-Metadata pointer; agent drives the human through per-scope consent; provider returns an access token scoped to the requested service.

Credentials are stored by the orchestrator CLI and made available to the agent rather than handed to the agent directly — single revocation target on the orchestrator side.

3. Payment¶

When the requested service is paid, the orchestrator ships a payment token — not raw card data — with the provisioning request. The provider redeems the token against the orchestrator for settlement. Two safety primitives are co-equal with the token:

Default spending cap per provider (concepts/agent-payment-budget-cap); raiseable by the user, enforced by the orchestrator at token-issue time.
Provider-side usage dashboard for the user to see spend against cap without switching platforms.

Raw card data never reaches the agent. See concepts/payment-token-over-credit-card-sharing.

Canonical instance (2026-04-30)¶

Stripe Projects (orchestrator) + Cloudflare Registrar / Workers / other Cloudflare services (providers) are the launch-time canonical implementation. The launch writeup (co-authored by Cloudflare and Stripe, 2026-04-30) names the three components explicitly and frames the protocol as generalisable: "any platform with signed-in users can integrate with Cloudflare in the same way Stripe does."

The launch end-to-end flow:

user prompts agent
  ↓
stripe projects init
  ↓
stripe projects catalog                ← Discovery
  ↓
agent picks cloudflare/registrar:domain
  ↓
stripe projects add cloudflare/registrar:domain
  ↓
(if no Cloudflare acct)                ← Authorization
  Stripe attests identity →
  Cloudflare auto-creates account +
  returns credentials to Stripe CLI
(if Cloudflare acct exists)
  OAuth consent flow →
  Cloudflare returns access token
  ↓
Stripe ships payment token →           ← Payment
  Cloudflare registers domain +
  charges token via Stripe
  ↓
agent uses returned API token to
  deploy Workers code on new domain

Trade-offs¶

Upsides¶

Agent cold-start collapses. Zero-to-production in one agent session; no dashboard trip, no token paste, no credit- card entry.
Structurally bounded autonomy. The protocol's default spending cap is first-class, not policy-bolted-on; the agent cannot spend beyond it without an explicit user action at the orchestrator altitude.
Single revocation point. Credentials live in the orchestrator CLI; revoking the orchestrator project revokes access at every provider.
OAuth-like generality. The orchestrator/provider distinction is symmetric — platforms can be orchestrator or provider. Cloudflare plays both roles in existing integrations (Cloudflare-as-orchestrator for PlanetScale Postgres provisioning; Cloudflare-as-provider for Stripe Projects).
Reuses mature standards. OAuth + OIDC for identity, payment tokenization for settlement. Composition is new, primitives are not.

Downsides / open questions¶

Account-takeover surface grows. Auto-provisioning an account from a third-party-attested identity makes the orchestrator's account-security model co-load-bearing with the provider's. If the orchestrator's email + session is compromised, the attacker provisions new accounts at every participating provider. Dispute / recovery paths are unspecified at launch.
Spend-cap enforcement split-brain. Cap is issued by the orchestrator, redeemed at the provider. Who is responsible for refusing a charge over cap — orchestrator refusing to mint a token, or provider refusing to accept one — is unspecified. Double-spending across providers against the same user cap is an open problem.
Catalog poisoning. A provider could list services at misleading prices or with capabilities that don't match. Catalog-schema + trust-anchor design is not yet standardised; at launch the orchestrator aggregates by bilateral partnership.
Consent fatigue. Per-provider OAuth consent is still required for existing accounts; scaling to a catalog of dozens of providers reintroduces the consent-click churn the protocol aims to reduce.
Auto-created accounts vs. dispute rights. A user who later disputes an agent-initiated charge may find the account was created for them mid-session; standard chargeback flows assume account existence precedes the charge.
Protocol-spec maturity. Launch framing is "a more official specification soon." Early adopters are building against bilateral contracts, not a finalised spec.

Composes with¶

patterns/orchestrator-provider-agent-trust-triangle — the role topology the protocol assumes.
patterns/partner-managed-service-as-native-binding — the pre-protocol pattern for platform-to-partner provisioning (Cloudflare-provisions-PlanetScale, Fly.io- provisions-Tigris). The agent-provisioning protocol generalises this by letting any signed-in-user platform play the orchestrator role, not just the platform that owns the runtime.
patterns/well-known-endpoint-discovery — the discovery component uses a well-known-style REST endpoint per provider, aggregated by the orchestrator.
Code Mode — agent consumption of provisioned provider APIs. Code Mode compresses the API surface to fit in the context window; the protocol gets the agent access to call it.
Agent Skills — task-level how- to documents for using provisioned services. Orthogonal to the protocol (access vs. know-how); both compose.

Generalises to¶

Agent-initiated SaaS subscriptions beyond cloud infrastructure (analytics, observability, collaboration tools).
Inter-platform resource federation — any platform with a signed-in user + payment method can provision at any other participating platform. The PlanetScale-on-Cloudflare Postgres integration is prior art at a smaller altitude.

Distinction from sibling shapes¶

concepts/agentic-commerce — human buyer's money → seller for a human-consumable good. "A checkout session with shipping, loyalty, and a human confirmation step." Short-lived transaction.
concepts/machine-payment — agent's own budget → API for a per-request charge. "A fast, programmatic payment inside an HTTP call." HTTP-native, per-request.
Agent provisioning (this pattern) — human user's money → service provider for a persistent cloud resource / subscription. Long-lived artefact (account, domain, API token) that outlives the agent session.

These three shapes cover the money-through-agent taxonomy: transient buyer flow, per-call machine flow, lifecycle provisioning flow. Different fraud surfaces, different cap primitives, different settlement cadence.

Seen in¶

sources/2026-04-30-cloudflare-agents-can-now-create-cloudflare-accounts-buy-domains-and-deploy — canonical wiki instance; Cloudflare + Stripe launch post.