CLOUDFLARE DYNAMIC WORKERS: SECURE AI AGENTS AT THE EDGE

• 29/3/2026
• Updated 3/4/2026
• 9-minute read
• 1763 words

The bottleneck holding back modern AI agents isn’t intelligence; it’s execution. If you’ve spent any time working with multi-agent frameworks, you know that sequential tool calling—where the LLM pauses, asks a tool for data, waits for a response, and then reasons about what to do next—introduces massive latency. I’ve watched promising AI workflows grind to a halt because each API hop adds seconds of overhead.

Who Is This Guide For?

This is for you if you’re a developer building multi-agent AI systems that need secure code execution, an engineer evaluating serverless platforms for AI agent workloads, a platform lead exploring sandboxing solutions for user-generated code, or anyone trying to scale AI agents without managing container infrastructure. Sound like you? Let’s dive in.

By the end of this, you’ll know how Dynamic Workers compare to containers and unikernels for AI execution, the security model and how to configure granular access controls, actual implementation code for loading and caching dynamic workers, and which platform to choose based on your isolation and latency requirements.

When building complex agent workflows, developers are increasingly turning to “Code Mode.” Instead of sequential tool calls, the LLM generates a single script that chains APIs together and executes it. But this creates a new, terrifying problem: where do you safely run arbitrary, LLM-generated code on the fly? You can’t run it in your core application environment without inviting disaster.

The Container Problem

If you’re using traditional infrastructure, your instinct is probably to spin up a Docker container or a Firecracker microVM for every AI agent task. This is the approach many serverless vs self-hosted / architectures default to.

However, spinning up an ephemeral container introduces a painful cold start penalty. For latency-sensitive AI agents interacting with users in real-time, waiting a second or two for a container to boot is unacceptable. The orchestration overhead of managing thousands of fleeting containers is also an infrastructure nightmare.

With its March 2026 open beta release, Cloudflare threw a massive wrench into this paradigm by introducing Dynamic Workers.

Instead of heavy containers, Dynamic Workers leverage Chrome’s V8 isolates. Isolates are extremely lightweight sandboxes that spin up in a fraction of a millisecond and require significantly less memory than a full guest operating system or containerization layer.

Why Dynamic Workers Change the Game

The true value of Dynamic Workers lies in their security primitives. When your agent writes a script to orchestrate a multi-step task, a parent Worker can dynamically compile and instantiate that script into an isolated child environment.

Here is why this matters:

• Zero Cold Starts: V8 isolates start in less than 5 milliseconds. Your LLM finishes generating the script, and execution begins almost instantly.
• Granular Network Control: You can intercept and block outbound Internet access from the sandbox using globalOutbound: null. If the LLM goes rogue or falls victim to prompt injection, you prevent data exfiltration at the network boundary.
• Isolated Resources: You explicitly provide bindings to the Dynamic Worker via the env property. It cannot read your database or access your S3 buckets unless the parent worker deliberately grants it permission.

Use Cases

Dynamic Workers excel at several patterns that are emerging in the AI agent space:

• Code Mode: LLMs trained to write code can now execute it directly instead of making sequential tool calls—saving up to 80% in inference tokens and costs.
• AI Agent Execution: Run code for data analysis, file transformations, API calls, and chained actions in a secure sandbox.
• User-Generated Platforms: Run applications where users upload or generate code that must execute safely.
• Fast Previews: Load prototypes and playgrounds in milliseconds for rapid iteration.

If you are building multi-agent frameworks /, creating cheap, secure sandboxes on demand is no longer optional. It is the only way to scale agent capabilities safely.

Configuring the Worker Loader

Before you can load Dynamic Workers, you need to configure the Worker Loader binding in your wrangler.jsonc:

{
  "worker_loaders": [
    {
      "binding": "LOADER"
    }
  ]
}

This gives your Worker access to the Worker Loader API via env.LOADER.

Implementing the Dynamic Worker Loader API

Let’s look at how you actually implement this using the new Dynamic Worker Loader API.

First, your parent worker receives the dynamically generated code—perhaps from a tool call emitted by an LLM running on Cloudflare’s AI platform /.

Here’s the official example from Cloudflare’s agents repository :

const DEFAULT_CODE = `export default {
  fetch() {
    return new Response("Hello from a dynamic Worker!");
  },
};`;

export default {
  async fetch(request: Request, env: Env) {
    const url = new URL(request.url);
    if (url.pathname === "/api/run" && request.method === "POST") {
      const body = await request.json<{ code?: string }>();
      const code = body.code?.trim() || DEFAULT_CODE;

      try {
        const worker = env.LOADER.load({
          compatibilityDate: "2026-01-28",
          mainModule: "worker.js",
          modules: {
            "worker.js": code
          },
          globalOutbound: null
        });

        const result = await worker
          .getEntrypoint()
          .fetch(new Request("https://worker/"));

        const text = await result.text();
        return Response.json({
          ok: true,
          status: result.status,
          output: text
        });
      } catch (err) {
        return Response.json(
          {
            ok: false,
            error: err instanceof Error ? err.message : String(err)
          },
          { status: 400 }
        );
      }
    }
    return new Response("Not found", { status: 404 });
  }
} satisfies ExportedHandler;

This example shows a production-ready pattern: the host Worker exposes a /api/run endpoint that accepts user code and executes it in an isolated Dynamic Worker. The key components:

1. env.LOADER.load() - Creates a one-off dynamic isolate
2. modules: { "worker.js": code } - Passes the code as a module
3. globalOutbound: null - Blocks all outbound network access
4. worker.getEntrypoint().fetch() - Executes the dynamic Worker

In this architecture, the parent worker acts as the strict supervisor. It evaluates the risk, provisions the exact subset of necessary bindings, and executes the generated code.

Reusing Dynamic Workers with Caching

If you expect to load the same Worker code repeatedly, use get() instead of load(). This caches the Worker by ID so it stays warm across requests:

const worker = env.LOADER.get("tenant-123-agent", async () => {
  let code = await env.CODE_STORAGE.get("tenant-123-agent");
  return {
    compatibilityDate: "2026-01-01",
    mainModule: "index.js",
    modules: { "index.js": code },
    globalOutbound: null,
    env: { INTERNAL_API: env.INTERNAL_API }
  };
});

const entrypoint = worker.getEntrypoint();
return entrypoint.fetch(request);

Using TypeScript and npm Dependencies

For Dynamic Workers that need TypeScript compilation or npm packages, use the official @cloudflare/worker-bundler library:

import { createWorker } from "@cloudflare/worker-bundler";

const worker = env.LOADER.get("my-worker", async () => {
  const { mainModule, modules } = await createWorker({
    files: {
      "src/index.ts": `
        import { Hono } from 'hono';
        const app = new Hono();
        app.get('/', (c) => c.text('Hello from Dynamic Worker!'));
        export default app;
      `,
      "package.json": JSON.stringify({
        dependencies: { hono: "^4.0.0" }
      })
    }
  });
  return { mainModule, modules, compatibilityDate: "2026-01-01" };
});

The bundler handles TypeScript compilation, npm dependency resolution, and esbuild bundling automatically.

Securing the Edge

Beyond bindings, you should enforce strict network access. By attaching a Tail Worker to your Dynamic Worker, you can stream all fetch events and console logs to a centralized monitoring system. If the AI agent attempts to contact a domain outside its allowlist, you fail the execution and log the anomaly.

Pricing

During the open beta (as of March 2026), Dynamic Workers are priced at $0.002 per unique Worker loaded per day, but this fee is waived during beta. You only pay standard CPU and invocation charges:

For developers orchestrating high-volume AI agents, this pricing is aggressively competitive against running dedicated fleets of microVMs—execution cost becomes negligible compared to inference costs.

How It Compares

Cloudflare Dynamic Workers aren’t the only game in town. Here’s how they stack up against other sandboxing approaches:

V8 Isolates vs Unikernels vs Containers

Detailed Comparison

KraftCloud (Unikraft)

• Uses unikernels—minimal OS tailored to the application
• Cold starts in 15-50ms (NGINX: 15-20ms, Next.js: 130ms)
• Hardware-level isolation (stronger than isolates)
• Pay-per-millisecond pricing (~$0.00001/GB-second)
• Supports any language that compiles to a unikernel
• Recently launched publicly in 2025 with $6M funding

WasmCloud

• Open source (CNCF project), free to self-host
• WebAssembly-based—WASM components start in <1ms
• Runtime initialization (Wasmtime): 50-120ms
• More complex setup than Cloudflare’s managed offering
• You pay for the underlying cloud infrastructure
• Best for: teams wanting full control over their runtime

Vercel Sandbox

• Full Linux containers with Docker support
• Cold starts: 1-5 seconds (significantly slower)
• Pricing: $20/mo Pro plan minimum, then $0.128/vCPU-hour (active CPU only)
• Better for: Vercel-native workflows, longer-running tasks
• Supports stateful workloads with persistent execution contexts

When to Choose What

The key insight: Cloudflare’s V8 isolate approach sacrifices some hardware-level isolation for raw speed. For most AI agent use cases—where code is generated by your own LLMs and the stakes are moderate—the 5ms cold start wins over the stronger isolation of unikernels.

The Verdict

Building your own container-based sandboxing infrastructure for AI code execution is a poor allocation of resources. The economics don’t work: you’d spend engineering time maintaining infrastructure that costs more per-execution than the AI inference that generated the code.

Cloudflare Dynamic Workers give you a globally distributed, sub-millisecond execution environment specifically designed to run untrusted code securely. At $0.002 per unique Worker (waived during beta), the execution cost is essentially negligible compared to inference costs. With 5ms cold starts and zero infrastructure management, it’s purpose-built for the AI agent era.

That said, this isn’t a one-size-fits-all solution. If you need hardware-level isolation for compliance reasons, KraftCloud’s unikernels offer stronger guarantees at 10-50ms cold starts. If you want full control and are comfortable self-hosting, WasmCloud provides an open-source path. And if you’re already deep in the Vercel ecosystem with stateful workload requirements, Vercel Sandboxes make sense.

But for the majority of teams building autonomous agents in 2026—where speed matters, cost efficiency is non-negotiable, and you control the code being executed—Dynamic Workers are the right default. The future of AI infrastructure is moving toward lightweight, ephemeral execution environments, and Cloudflare just made it accessible to everyone.

References

Cloudflare Dynamic Workers

• Dynamic Workers Official Documentation
• Dynamic Workers Pricing
• Dynamic Workers Starter Example
• Dynamic Workers Playground
• @cloudflare/worker-bundler npm package

Competing Platforms

• KraftCloud (Unikraft) - Unikernel-based millisecond cloud
• WasmCloud - CNCF WebAssembly platform
• Vercel Sandbox - Container-based code execution

Related Reading

• Cloudflare Blog: Sandboxing AI agents, 100x faster
• VentureBeat: Cloudflare’s Dynamic Workers analysis