Cloudflare Dynamic Workers
language-runtimecloud-platformCloudflare's API for running AI-generated code in a fresh V8 isolate per request, milliseconds to start, with brokered credentials and off by default.
Isolation mechanism, defense layers, and the patch-within-hours claim are all vendor-stated in the launch post. The second wall in particular is described rather than detailed, and we have not measured any of it. Note that Cloudflare also sells a container-based sandbox product; this entry covers the isolate path only.
Dynamic Workers (open beta, March 2026) let a Worker call a loader API to instantiate further Workers from code supplied at runtime, which is what makes it usable for code an AI wrote after you deployed. The sandbox is the V8 isolate Cloudflare Workers has used since launch, so a sandbox costs a few milliseconds and a few megabytes rather than the hundreds of each a container costs, which is the entire argument: at consumer scale, with every user running several agents, container-per-execution does not fit. The capability model is the good part. Generated code gets only the APIs the parent hands it over a typed RPC interface, credentials are injected by the host so the code never sees a token, and network access is off unless granted, with globalOutbound set to null for total isolation or pointed at an interceptor that rewrites requests. Cloudflare is unusually direct about the cost of this design, stating that an isolate sandbox is a more complicated attack surface than a hardware VM and that V8 security bugs are more common than bugs, and they answer it with layers: V8 patches to production within hours, a second-layer sandbox with tenant cordoning, MPK, and Spectre work.
Strengths
- Sandbox creation in single-digit milliseconds and a few megabytes, roughly 100x faster and 10-100x lighter than a container per the vendor
- Deny-by-default capability model: generated code reaches only the APIs the parent Worker passes it
- Credentials are brokered by the host, so the code never holds a token it could exfiltrate
- Egress is off unless you grant it, and can be pointed at an interceptor instead
- V8 security patches reach production within hours, the strongest patch-cadence answer of any product on this site
- The vendor states the weakness of its own boundary in writing, which is rare enough to be worth weighting
Limitations
- The weakest rung on the kernel axis: a shared process on a shared kernel, so an engine escape is a tenancy escape unless the second wall holds
- Cloudflare's own framing is that this is a more complicated attack surface than a hardware VM, and that V8 bugs are more common than hypervisor bugs
- The compensating controls are proprietary and undetailed, you are trusting the second-layer sandbox and the patch pipeline rather than inspecting them
- JavaScript and WebAssembly only, so it cannot sandbox an arbitrary binary or a shell command the way a container or microVM can
- Hosted only, with no self-host story, and in open beta
Files & editor
edit-insideCode is supplied to the loader API at runtime by the calling Worker; there is nothing to attach an editor to.
How you get your project into the environment and edit it. Shared-kernel routes bind-mount host files for your desktop editor; own-kernel routes keep files in the guest, so a desktop editor attaches over remote, or you edit inside. Mounts and remote editing.
Secrets
secrets: brokeredThe host Worker injects credentials into outbound requests, so generated code holds a reference and never the token itself. Stealing the secret means defeating the host Worker, not reading an environment variable.
The realistic agent threat is exfiltration, not a kernel escape. Keeping credentials out of the code's reach is what defends against a prompt-injected agent stealing your keys. Keeping keys out of the blast radius.
VMM second wall
VMM second wall: partiala custom second-layer sandbox around the runtime process with risk-based cordoning of tenants, an extended V8 sandbox using hardware memory protection keys (MPK), novel Spectre defenses, and scanning that blocks known-malicious code patterns; vendor-described, and the vendor states plainly that this is harder to harden than a hardware VM.
The second wall confines the VMM itself, so a compromised device backend can't own the host. It's separate from the hardware boundary every microVM already has. The two walls, explained.