Cloudflare Now Lets Your Agent Spin Up Compute Without an Account. Here's What That Trades Away.

Let's be precise about what shipped, because the size of the change is easy to miss. You can deploy a Cloudflare Workers project and run it without an account, and Cloudflare deploys it to a new ephemeral project that stays live for 60 minutes, per Willison's writeup.

That's it. Sixty minutes of real, network-connected compute, summoned with zero setup ceremony.

To see why that's a bigger deal than it sounds, picture the old path. Your agent decides it needs to run some code in the cloud, maybe to test an HTTP endpoint, fetch something through a clean IP, or host a tiny tool for another service to call. Under the old model, the agent had to either use infrastructure you'd already provisioned (which means you set it up in advance and gave the agent durable access) or provision new infrastructure itself (which means handling signup, payment, and credential storage).

Both paths force a choice between friction and trust. Either you front-load the work and hand over standing keys, or the agent stalls waiting for a human. There was no clean third option.

Willison's own test makes the new path concrete. He had GPT-5.5 in Codex Desktop build a small application: a tool for following HTTP redirects and returning the final destination, as described in the post. The agent wrote the code and deployed it to live, running compute. No account creation step sat in the middle.

Think about the Feynman version of this. If you had to explain to a smart twelve-year-old why agents struggled with cloud compute, you'd say: "the computer wanted to know who you were before it would let you use it, and the robot didn't have an ID." This feature is the cloud agreeing to skip the ID check for an hour. Simple to state. The consequences are not.

Every agent deployment lives somewhere on what we at ClawBlog call the Autonomy Spectrum, the range from copilot (you approve each step) to full autonomy (the agent runs the loop unattended). Most failures come from deploying at the wrong point on that spectrum. And the single biggest thing pinning agents toward the copilot end has been provisioning.

An agent that can plan, write code, and reason about a task still hits a hard stop the moment the task requires standing up new infrastructure. Someone has to own the account. Someone has to hold the credential. That someone has been you.

The usual workaround was worse than the problem. To let an agent self-serve compute, teams handed it long-lived API tokens to a real cloud account. Now you've got a credential that:

• Outlives the task it was issued for
• Carries the full blast radius of your account, not just the job
• Sits in the agent's context or environment, where a prompt injection can reach it
• Has no natural expiry, so it lingers as attack surface

That is the friction-versus-trust tradeoff in its rawest form. Reduce friction by issuing durable credentials, and you expand trust to a dangerous radius. Keep trust tight by approving everything manually, and you've kneecapped the autonomy you bought the agent for.

Ephemeral, account-free compute collapses the tradeoff instead of picking a side. There is no durable credential because there is no account. The blast radius is one ephemeral project that evaporates in an hour. The agent self-serves, so you're not the bottleneck, but it self-serves into a sandbox that was built to be thrown away.

This is what it looks like when agent-friendly infrastructure stops being a bolt-on and becomes a product primitive. The platform didn't add an "agent permission tier." It changed the default unit of compute to something disposable enough that an autonomous actor can use it safely. That's the shift worth watching.

Let's get concrete about use, because "ephemeral compute" is abstract until you see your agent reaching for it. The canonical pattern is the one Willison demonstrated: the agent needs to run code that talks to the network from somewhere that isn't your laptop, following HTTP redirects to a final destination in his case.

Generalize that and you get a family of jobs your agent can now handle without asking you for anything:

• Throwaway tool hosting. The agent writes a small HTTP tool, deploys it, and hands the live URL to another service or another agent for the duration of a task. When the work's done, the endpoint is gone on its own.
• Clean-room execution. Code that the agent shouldn't run on your machine (something it generated, something it found, something that touches untrusted input) runs in an isolated sandbox with no path back to your environment.
• Network egress from a neutral location. Testing how a URL behaves, checking a redirect chain, or hitting an API from somewhere that isn't your IP, without standing up a proxy in advance.
• Ephemeral glue between systems. A short-lived webhook receiver or transform endpoint that exists only as long as the multi-step task that needs it.

Notice the shape of all four. They're jobs where you want the compute to exist briefly and then stop existing. That's exactly the case where a permanent account was overkill and a security liability at the same time.

For the power user configuring an agent rather than coding one, the practical upshot is this: tasks you used to scope down or hand-hold because "the agent can't really run things" just moved into the agent's reach. You'll find yourself granting broader task descriptions because the provisioning objection is gone.

That freedom is the point. It's also the thing that should make you pause before the next section, because broader reach is exactly when the trust boundary you stopped thinking about starts to matter again.

Here's the gotcha that experience will teach you the hard way if you don't read it now. Removing the account didn't remove the trust decision. It relocated it.

Use the Trust Boundary Model: find every place data crosses from one trust level to another, because those are the places you inspect and enforce. Under the old account-based model, the boundary was obvious and coarse. The credential was the boundary. You either had account access or you didn't, and you spent your security attention on protecting that key.

With account-free ephemeral compute, the credential boundary is gone, and three new boundaries appear in its place.

One: anyone, or anything, can deploy. No account means no caller identity check at the door. That's the entire convenience. It also means the thing summoning the compute could be your agent acting on your behalf, or it could be your agent acting on a prompt injection it just swallowed. The platform won't tell the difference. You have to enforce that boundary upstream, in what you let the agent execute and on what inputs.

Two: the sandbox runs code, and code your agent wrote is still code you didn't review. A 60-minute window doesn't sanitize what runs inside it. If the agent generated the deployed application from untrusted instructions, you've got attacker-influenced code running on live, network-connected infrastructure. Isolated from your machine, yes. Harmless, no.

Three: the live URL is a public-ish artifact for an hour. Whatever your agent deploys is reachable. If it handles sensitive data or acts as glue between systems that trust it, that endpoint is an exposed surface for its lifetime, even if that lifetime is short.

The reason this matters more for agents than for the human developer who'll also love this feature: a human deploys deliberately, once, knowing what's in the code. An autonomous agent in a loop can deploy repeatedly, on inputs you never saw, faster than you can watch. Convenience scales. So does the consequence of getting the boundary wrong.

If you're going to wire your agent into account-free, ephemeral compute, here's the order of operations that keeps the convenience without inheriting the risk. Work top to bottom; the early steps are the ones people skip and regret.

Step 1: Decide where on the Autonomy Spectrum this sits. For a first deployment, keep the agent in copilot mode for anything that deploys live compute. Let it draft the code and propose the deploy, and you approve. You can loosen this once you trust the task shape, not before.

Step 2: Treat every deploy as untrusted code execution, because it is. Assume the application your agent deploys may have been shaped by something in its input. Don't let it deploy code that holds secrets, calls your internal systems, or processes data you can't afford to expose. The ephemeral sandbox is a place to run things you're willing to lose, not a place to run things that matter.

Step 3: Keep nothing valuable in the deployed app. No real credentials, no production database strings, no tokens to your other services. If the live URL is reachable for an hour, write the app as if a stranger will find it, because the absence of an account login means you can't assume they won't.

Step 4: Scope the agent's network reach, not just its compute. The value here is egress and isolation. Make sure what the agent deploys can't phone home to systems that would trust a call from "your" infrastructure. The endpoint should be a dead end, not a bridge.

Step 5: Log what your agent deploys. A 60-minute lifespan means the artifact vanishes, but you still want a record of what the agent built and ran, separate from the platform. Tooling in this space is maturing fast: observability projects for agents keep shipping, with Langfuse pushing regular releases including agent-focused fixes. Capture the deploy events somewhere durable so a vanished sandbox doesn't mean a vanished audit trail.

Step 6: Watch for the deploy-in-a-loop failure. The classic gotcha: an agent that hits an error, decides the fix is to redeploy, and burns through ephemeral projects in a tight loop while accomplishing nothing. Cap how many deploys a single task can trigger. You'll thank yourself the first time a confused agent tries to brute-force its way out of a bug.

Step back from Cloudflare specifically, because the move it made is a signal about where infrastructure is heading. The interesting thing isn't a 60-minute timer. It's that a mainstream platform shipped agent-grade ergonomics as a user-facing default rather than a special mode.

This follows a logic worth naming: Commoditize Your Complement. A platform makes the layer next to its own cheap and frictionless so that its own layer captures the demand. Cloudflare's product is the compute and the network. The complement is the friction of getting onto it. By driving that friction to zero, even for an anonymous, automated caller, they make their compute the path of least resistance for the fastest-growing source of new compute demand: agents acting on their own.

You can read the same instinct in adjacent tooling moves. Model SDKs keep smoothing the rough edges of routing requests to the right endpoint so developers and agents don't trip over them. Observability platforms keep shipping agent-specific fixes. The pattern across the stack is the same: assume an automated, non-human consumer, and design the default experience for it.

The Harness Hypothesis says the value in AI isn't the model, it's the harness that connects the model to the world. Account-free ephemeral compute is a harness component, and a load-bearing one. It's the difference between an agent that can reason about running code and an agent that can actually run it, unattended, without you holding its hand at the credential step.

That's why this matters even though the feature itself is a sentence long. When the boring infrastructure layer starts treating an autonomous agent as a first-class user, the ceiling on what you can hand your agent rises. The friction wall that kept agents in copilot mode for whole categories of task just got shorter.

Your job, as the person configuring that agent, is to make sure the trust boundary moved with intent and not by accident. The platform handed you reach. The discipline is still yours to supply.