Cloudflare Temporary Accounts for AI Agents, explained

Cloudflare Temporary Accounts for AI Agents, launched June 19, 2026, let a coding agent deploy a Cloudflare Worker with no signup — the agent runs wrangler deploy --temporary and the platform provisions a throwaway account, deploys the code, and hands back a claim URL the agent can return to a human.

The reason this matters is a workflow gap, not a missing feature. Coding agents are now competent at writing software end to end, but the moment one needs to ship, it hits an account-creation flow built for a human with a browser, an email inbox, and a credit card. For an unattended background session that wall is a hard stop. Temporary Accounts removes it for the simplest case: get something live, then decide whether to keep it.

This guide walks through the mechanics of the claim flow, the guardrails Cloudflare built in (proof-of-work, rate limits, credential checks), the product limits at launch, the explicit cases Cloudflare says it is not for, and how it fits alongside the other two agent-auth initiatives Cloudflare announced in 2026. Every number and limit below is drawn from Cloudflare's own announcement and documentation.

The framing in Cloudflare's announcement is blunt about where the friction sits. Writing software with an agent is already routine; shipping it is where the workflow breaks. A signup form expects a person — an email to verify, a card to enter, a button to click inside a short window. None of that survives an unattended background run, and Cloudflare argues an agent that gets stuck there will simply deploy somewhere it can get through.

That observation generalizes beyond Cloudflare. Background agent sessions — scheduled runs, ticket-driven automations, multi-step build pipelines kicked off by another system — are increasingly the norm rather than the exception. Any authentication step that needs a browser, a copy-paste, or a click in the next sixty seconds is a point where an autonomous agent stalls. The interesting design move here is not the temporary account itself; it is treating agent-legibility as a first-class CLI requirement. We cover the governance side of giving agents this kind of reach in our guide to AI agent governance and compliance frameworks.

The flow is deliberately short. When an agent runs wrangler deploy --temporary with no credentials present, three things happen on Cloudflare’s side: a temporary account is provisioned, Wrangler is issued an API token to work with, and a claim URL is generated for the agent to pass back to a human. The Worker goes live on a workers.dev subdomain immediately.

From there the clock matters. The temporary account stays live for 60 minutes. Within that window, a human can open the claim URL in a browser and take permanent ownership — the account, and the deployment running on it, become a normal Cloudflare account the person controls. If no one claims it inside the hour, the account expires automatically and the deployment goes with it. There is no documented mechanism to extend the 60-minute window; treat it as a fixed expiry.

The detail that makes this agent-native is the auto-discovery prompt. An agent does not need to know the flag exists in advance. When a deploy fails because no credentials are present, Wrangler prints guidance telling the caller to rerun the command with --temporary, explaining that it will use a temporary account and print a claim URL. In effect the CLI documents itself to whatever is reading its output — a human or a language model — which is a meaningfully different design target than a CLI written only for people.

A no-signup deploy endpoint is an obvious target for abuse, so Cloudflare wrapped the flow in three controls that an agent never has to think about but cannot route around either.

The credential check is worth dwelling on because it shapes how the feature behaves inside a real pipeline. Temporary mode is explicitly the path you take when you have nothing — no login, no token, no key. The instant any of those exist, Cloudflare assumes you want the permanent account behind them, and the temporary path closes. That keeps the feature scoped to genuine first-deploy moments rather than becoming a quiet way to sidestep an organization's real credentials.

Supported products are deliberately narrow at launch, with explicit per-product ceilings. The table below synthesizes Cloudflare's claim-deployments documentation into a single agent-builder reference. The most important line is the last one: custom domains are not available in temporary mode, so deployments live on workers.dev until the account is claimed.

Read as a set, the limits tell you the intended scope clearly: this is a deploy-and-demo surface, not a place to stand up something durable. You can prove that a generated app runs end to end — a front end, a database, a queue, some stateful coordination — but you cannot grow it into production inside the temporary account. That is by design, and it is consistent with the explicit non-use-cases in the next section.

This is the part most coverage of the announcement skips, and it is where the feature earns its credibility. Cloudflare states the non-use-case directly in its documentation:

That guidance is more than a disclaimer. A 60-minute account with no owner, no custom domain, and capped products is structurally wrong for anything that needs to persist, be monitored, or be redeployed from a pipeline. Pointing CI at temporary accounts would mean a fresh throwaway environment on every run with no continuity of state, secrets, or domains. The feature is best understood as the very first step of a longer journey: get a generated app live so a human can look at it, then claim it and move it onto proper credentials before doing anything serious.

The boundary also matters for security review. Because temporary accounts deploy real, internet-reachable Workers with no identity attached up front, an attacker could in principle use the flow to spin up short-lived phishing or malware-hosting Workers. The 60-minute expiry and rate limits blunt that, but teams adopting agent-driven deploys should still treat the surface as part of their threat model — the same way they would any unattended deploy path. Cloudflare's broader approach to keeping autonomous agents in check is covered in our piece on securing autonomous agents at the edge.

Temporary Accounts is one of three concurrent agent-auth initiatives Cloudflare advanced in 2026. Most coverage treats them as separate announcements; they read more coherently as a layered model for how an agent acquires identity, payment, and a place to run. The first removes friction entirely, the second adds delegated payment, and the third standardizes the handshake.

The Stripe Projects protocol, announced May 18, 2026, lets agents go further — create a Cloudflare account, start a paid subscription, register a domain, and obtain an API token — under a default spending cap of $100 per month per provider, with human approval gates kept at Stripe authentication, terms acceptance, billing setup, and merge decisions. Note that the $100 cap belongs to Stripe Projects, where money changes hands; Temporary Accounts involves no payment at all, so it has no spending cap to speak of. The auth.md protocol from WorkOS, published around May 25, 2026, takes the abstraction up a level: a Markdown file at a well-known URL that composes existing OAuth standards into a portable agent-registration handshake, with Cloudflare among the early adopters.

For the adjacent question of how agents pay for the resources they provision, the emerging machine-payment rails are worth understanding alongside this — see our explainer on the x402 payment protocol for AI agents. Read together, the picture is an identity-and-payment layer forming beneath agent infrastructure, with Cloudflare staking out each tier.

Most of the documented risk in this space attaches to the payment-enabled tier rather than to Temporary Accounts, which is payment-free by design. Developer commentary on the Stripe Projects model surfaced three failure modes worth carrying into any agent-driven cloud workflow: an agent buying the wrong domain, burning through credit in a retry loop, and committing irreversible spend on durable assets. Cloudflare's answers there are runtime budget enforcement, audit logs, idempotency keys, and fast kill switches.

The bars above are an illustrative weighting, not measured incident rates — they are meant to show where the heavier risk sits, which is squarely in the payment tier. For Temporary Accounts specifically, the two real exposures are mundane by comparison: a claim URL that leaks (because it grants ownership) and the abuse of a short-lived anonymous Worker. Both are bounded by the 60-minute expiry, the rate limits, and the proof-of-work check, but neither is zero. Our advice is to treat claim URLs as secrets in your agent scaffolding and to keep the no-credentials deploy path inside the same monitoring you apply to any other deploy.

The right adoption posture follows the feature's own scoping: lean on it for the moments it was built for, and route everything durable to permanent credentials.

For agencies and engineering teams, the practical move is to build the claim step into the workflow from day one. Have the agent surface the claim URL to a named human channel, decide on the spot whether the deployment is worth keeping, and either claim it onto a real account or let it expire. That keeps the throwaway tier genuinely throwaway and prevents the anti-pattern of leaning on it for things it was never meant to hold. If you are designing the broader deployment and identity stack that agents plug into, our overview of an enterprise agent platform reference architecture maps where a feature like this fits. Teams standing up agent-driven development pipelines end to end are exactly who we work with in our AI digital transformation engagements, and when it comes to shipping the apps those agents produce, our web development team handles the move from preview to production.