Dynamic Workers — Demo Script

Prereq: Workers Paid plan required. Dynamic Workers does NOT work on the free Workers tier. Upgrade the demo account before showtime. https://dash.cloudflare.com/<account-id>/workers/plans

0The framing (before clicking anything)

"Before I click anything — let me frame what we're looking at. You said your team is vibecoding with Anthropic and OpenAI, and what worries you is what those agents might do when they execute code on your behalf.

Here's the model: an AI agent writes code. That code runs somewhere. The question is: where, and what can it touch?

If the code runs on your laptop, it has your laptop. If it runs on a VM you spun up, it has the VM. If it runs in a Cloudflare sandbox, it has exactly what we let it have. Nothing else."

1The risk — what an unsandboxed agent can do

"Imagine an AI agent that's trying to help you build something. It writes some code. Maybe it's a legit helper, maybe it's been prompt-injected by a malicious user, maybe it just hallucinated.

What we want to know is — can that code call out to anywhere on the internet? Can it ship your data to an attacker? Can it see your API keys? Can it use them to run up a bill?

The whole point of this sandbox is — no. None of that."

2Demo: the allowed call (it should work)

"This is the agent code. It's calling OpenAI. Look at it carefully — there's no API key in this code. The agent has no idea what the key is. It just calls fetch to OpenAI's URL.

Watch what happens when I run it."

"There it is. Real call to OpenAI, real response — 'hello from the sandbox.'

What just happened: the agent's fetch was intercepted by Cloudflare. We checked the destination — api.openai.com, that's allowed. We injected the API key from our secret store. The request went out. The response came back. The agent never saw the key.

This is the happy path. Now let me break it."

3Demo: the blocked call (this is the value)

"Same shape of code. But this time the agent is trying to ship data to evil-cdn.example.com — maybe an attacker tricked it, maybe a bad library got pulled in, doesn't matter why. The agent is trying to talk to something we didn't allow.

Watch."

"403 — egress_blocked. The sandbox tried to reach an unauthorized host and Cloudflare stopped it before the request ever left.

This is the part that matters. The allow-list lives in our infrastructure, not in the agent's code. The agent can't talk its way out of it. It can't curl a different URL. It can't read the network config and edit it. The boundary is enforced by the runtime itself, not by the code.

And — look at the response — we tell you exactly what it tried and what's allowed. You get an audit trail of every escape attempt."

If the customer asks "what's the allow-list?": Show them HttpGateway.fetch in src/index.js. It's about 15 lines. We're checking url.hostname against a hardcoded list. They can make it as complex as they want — wildcards, paths, request body inspection, rate limits, anything. It's just code in their Worker.

4Demo: proving the agent can't see the API key

"One more thing. People always ask — okay, but the API key has to be somewhere, right? Can the agent find it by snooping around its own environment?

This code is the agent looking at every global variable, every process.env, every place a secret could be hiding."

"Nothing. No process.env. No environment variables. No globals named anything-key. The agent runs in an isolated V8 context, the loader Worker holds the secret in its own environment, and only the loader can use it.

The agent doesn't have a key it could leak. It just calls fetch, and we — the platform — decide whether to attach a key for it."

5Close — what this gives you

"So to recap. You said your worry was — agents executing code, where do they get to go, what can they leak.

With Dynamic Workers:

  • You get an isolated sandbox per agent run. Fresh, no persistent state, no access to your other services.
  • You get explicit allow-listing of egress. One file, ~30 lines, tells you exactly what the sandbox can reach. Audit-friendly.
  • You get credential injection at the platform layer. Agents call fetch normally. The platform attaches the key. The agent never sees it.
  • You get blast-radius limits. CPU and subrequest caps per invocation. One runaway agent can't drain your account.
  • And you get all of this without running infrastructure. No containers to patch, no VMs to harden, no Kubernetes."

Anticipated questions

"Is this just regular Workers under the hood?"

"Yes and no. It's the same V8 isolate technology, but every invocation creates a brand new sandbox with its own bindings and policies. Regular Workers are deployed once and live forever. Dynamic Workers are spun up per request, torn down after."

"What languages can the sandboxed code use?"

"JavaScript, TypeScript, or anything that compiles to WebAssembly — so Rust, Go, C++, Python via Pyodide, etc. If you need raw Python or a native binary, look at our Containers product instead."

"What about Python specifically? AI tooling lives in Python."

"Two options. Workers has Python support via Pyodide that runs in the sandbox. Or if you need the full Python ecosystem including binary packages, use Containers — that's the right tool for full language runtimes."

"How fast does the sandbox spin up?"

"Milliseconds. V8 isolates have no cold start — it's the same primitive that runs every browser tab in Chrome. There's no container starting, no VM booting."

"How is this different from AI Gateway?"

"AI Gateway sits in front of your LLM calls and gives you caching, rate limiting, cost visibility, fallback between providers. It's about the API call. Dynamic Workers is about the code that makes the API call — sandboxing the executor itself. You'd often use both: Dynamic Workers contains the agent, AI Gateway optimizes the LLM traffic the agent generates."

"How is this different from Zero Trust Gateway?"

"Zero Trust Gateway protects your employees as they browse the internet. Dynamic Workers protects your platform from the code your platform runs. Different problems. Often paired."

"What does it cost?"

"Workers Paid plan, $5/month base, then standard Workers pricing per request and CPU time. The Dynamic Workers binding itself doesn't have a separate per-sandbox fee — you pay for the underlying Worker compute. Pricing scales with how many code executions you do."

"Can we run this on our own infrastructure?"

"No. The sandbox is the Cloudflare runtime — that's the whole point. We've spent years hardening V8 isolates and the network around them. The value is that we run it, not you."

"What if the customer says 'we already use Lambda for this'?"

"Two real differences. First, Lambda has cold start and isn't designed for per-request sandboxing — it's a function platform, not a sandbox primitive. Second, the egress control is yours to wire up on AWS — VPC, security groups, NAT, etc. Here it's 30 lines of JavaScript. The boundary is a code review away."

Dynamic Workers Demo Script

Setup (do this before the call)