Skip to content

CONCEPT Cited by 1 source

Agent-provisioned account

Definition

An agent-provisioned account is a cloud-provider account that is created on demand by an agent, on behalf of a human user, keyed to a third-party-attested identity (typically the user's email + OIDC subject claim from a signed-in session on an orchestrator platform). The user has never visited the provider's signup page, confirmed an email, picked a plan tier, or entered a credit card on the provider.

Canonicalised by the 2026-04-30 Cloudflare + Stripe launch:

"If there is no existing Cloudflare account for the email you're logged in with, Cloudflare will provision an account automatically for you and your agent."

Why it matters

Prior to the agent-provisioning protocol, cloud-provider onboarding assumed a human at a dashboard. Agent-driven provisioning either couldn't start (no account) or required a human detour (dashboard trip, email verify, plan picker, card entry). The agent-provisioned account is the provider-side primitive that collapses "zero to production" into one agent session.

Preconditions

  1. Orchestrator-attested identity. A signed claim the provider can verify (OIDC ID token, or a bilateral JWT channel between orchestrator and provider). See patterns/orchestrator-provider-agent-trust-triangle.
  2. Payment method on the orchestrator. The provider isn't asked to collect card data; funding comes via the orchestrator's payment-token channel.
  3. ToS / consent wrapper. Human acceptance of the provider's terms is still required — it happens through the agent session UI, not a dashboard visit.

Lifecycle

agent calls orchestrator CLI
  ↓
orchestrator forwards attested identity to provider
  ↓
provider matches identity to existing account?
   yes → OAuth consent path → returns access token
   no  → CREATE new account keyed to attested identity
         ↓
         return API token + account metadata
         to orchestrator CLI (not directly to agent)

Distinguishing properties

  • Identity-first, payment-second. The account exists and is addressable even if no paid service has yet been provisioned; a paid charge is a separate orchestrator-side action gated by the spend cap.
  • Credentials live in the orchestrator's credential store — not in the agent's own memory. Revocation is a single orchestrator-side action.
  • First-class account on the provider, not a delegated sub-identity. The user can log into the provider dashboard afterward and see the account, resources, and billing records.
  • Indistinguishable from direct-signup at rest. Once provisioned, the account participates in the provider's normal product flows (dashboard, API, billing, team management). The provisioning path was novel; the account itself is ordinary.

Open questions

  • Account takeover if orchestrator is compromised. An attacker who hijacks an orchestrator session can auto-provision accounts across every participating provider. Mitigations (orchestrator MFA, anomaly detection) have not yet been standardised at the protocol layer.
  • Dispute / chargeback flow. If the user disputes an agent-initiated charge, the account may have been created specifically for that charge. Legal + UX mechanics of chargeback-against-just-provisioned-account are unresolved.
  • Multi-orchestrator identity collision. If two orchestrators attest the same user email to the same provider at different times, the matching policy for subsequent provisioning requests is unspecified.
  • Email ownership verification. Standard signup flows verify email by clicking a confirmation link. Agent- provisioning relies on the orchestrator having already done this; the quality of that prior verification becomes load-bearing for the provider.

Seen in

Last updated · 433 distilled / 1,256 read