Cloudflare Dynamic Worker Loader – schnellere Sandboxen für AI-Agenten

• Eine leichtgewichtige Sandbox für die Code-Ausführung von AI-Agenten, die im Vergleich zu Containern eine 100-fach schnellere Startzeit und eine 10- bis 100-fach höhere Speichereffizienz bietet
• Basierend auf der Isolate-Technologie der V8-JavaScript-Engine startet sie in wenigen Millisekunden und benötigt nur wenige Megabyte, sodass für jede Anfrage eine neue Sandbox erzeugt und wieder verworfen werden kann
• Mit dem Code-Mode-Ansatz, bei dem der Agent statt Tool-Aufrufen TypeScript-Code direkt schreibt und ausführt, lässt sich der Token-Verbrauch um bis zu 81 % senken
• Stellt Sicherheits- und Utility-Bibliotheken wie HTTP-Filterung, Credential Injection und ein virtuelles Dateisystem bereit und schafft damit ein Entwicklungsökosystem für Agenten
• Ein Infrastrukturwechsel, der die Kosten-, Latenz- und Skalierungsgrenzen containerbasierter Sandboxen überwindet und Agenten-Services im Consumer-Maßstab ermöglicht

---

Hintergrund: Sicherheitsprobleme bei der Ausführung von Agenten-Code

• Wenn ein Agent (oder MCP-Server) von einer AI spontan erzeugten Code ausführen soll, muss dieser Code in einer sicheren Umgebung laufen
• Wird er innerhalb der App direkt mit eval() ausgeführt, können böswillige Nutzer über Prompt Injection Schwachstellen einschleusen
• Es wird eine von der Anwendung und der Außenwelt isolierte Sandbox benötigt, in der nur die spezifischen Funktionen erlaubt sind, auf die der Code zugreifen darf

Grenzen des bisherigen Container-Ansatzes

• Der Großteil der Branche nutzt derzeit Linux-basierte Container als Sandbox
• Container benötigen mehrere hundert Millisekunden zum Start und mehrere hundert Megabyte Speicher für die Ausführung
• Um Latenzen zu vermeiden, müssen sie warmgehalten werden, und wenn bestehende Container für mehrere Aufgaben wiederverwendet werden, verschlechtert sich die Sicherheit
• In einem Consumer-Maßstab, in dem jeder Endnutzer einen Agenten hat und jeder Agent Code schreibt, reichen Container nicht aus

Dynamic Worker Loader: leichtgewichtige Sandbox

• Eine API, mit der ein Cloudflare Worker zur Laufzeit Code angeben und innerhalb seiner eigenen Sandbox on the fly einen neuen Worker erzeugen kann
• Wurde im vergangenen September im Code-Mode-Beitrag als experimentelle Funktion vorgestellt und ist nun als Open Beta für alle zahlenden Workers-Nutzer verfügbar
• Beim Erzeugen eines Workers wird der Code über compatibilityDate, mainModule und modules angegeben, RPC-Stubs werden über env übergeben, und mit globalOutbound kann der Internetzugang blockiert oder abgefangen werden

100-fach höhere Geschwindigkeit

• Dynamic Workers basieren auf V8-Isolates, demselben Sandboxing-Mechanismus, den die Cloudflare-Workers-Plattform seit 8 Jahren nutzt
• Ein Isolate ist eine Instanz derselben V8-JavaScript-Laufzeit-Engine, die auch in Google Chrome verwendet wird
• Mit wenigen Millisekunden Startzeit und wenigen Megabyte Speicherverbrauch sind sie gegenüber Containern etwa 100-mal schneller und 10- bis 100-mal speichereffizienter
• Dadurch ist es möglich, für jede Benutzeranfrage ein neues Isolate zu erstellen, ein Stück Code darin auszuführen und es danach wieder zu verwerfen

Unbegrenzte Skalierbarkeit

• Viele Anbieter containerbasierter Sandboxen setzen Limits für die globale Anzahl gleichzeitiger Sandboxen und die Erzeugungsgeschwindigkeit
• Da der Dynamic Worker Loader eine API derselben Technologie ist, die die Plattform selbst antreibt, gibt es diese Beschränkungen nicht
• Es können Millionen Anfragen pro Sekunde verarbeitet werden, wobei für jede Anfrage eine separate Dynamic-Worker-Sandbox geladen und parallel ausgeführt wird

Null Latenz

• Einmalige Dynamic Workers laufen normalerweise auf derselben Maschine und im selben Thread wie der Worker, der sie erzeugt hat
• Es ist keine globale Kommunikation nötig, um eine vorgewärmte Sandbox zu finden; sie werden direkt dort ausgeführt, wo die Anfrage eingeht
• Unterstützt in Hunderten globalen Standorten von Cloudflare

Nur JavaScript als Ausführungsumgebung

• Die einzige Einschränkung gegenüber Containern ist, dass der Agent JavaScript schreiben muss
• Workers unterstützen technisch auch Python und WebAssembly, aber für kleine, spontan vom Agenten erzeugte Code-Schnipsel lädt und führt sich JavaScript deutlich schneller aus
• LLMs beherrschen alle wichtigen Sprachen, und es gibt umfangreiche Trainingsdaten für JavaScript
• JavaScript ist durch seine Web-Herkunft eine für Sandboxing konzipierte Sprache

Mit TypeScript definierte Tool-APIs

• MCP definiert nur flache Tool-Call-Schemata, und OpenAPI beschreibt REST-APIs, aber sowohl das Schema selbst als auch der Aufrufcode sind ausführlich und schwergewichtig
• Für in JavaScript exponierte APIs ist TypeScript die beste einheitliche Lösung
• TypeScript-Interfaces können eine API mit deutlich weniger Tokens präzise beschreiben als eine vergleichbare OpenAPI-Spezifikation
• Die Workers Runtime richtet automatisch eine Cap'n Web RPC-Brücke zwischen Sandbox und Host-Code ein, sodass der Agent APIs wie lokale Bibliotheken aufrufen kann

HTTP-Filterung und Credential Injection

• Über die Option globalOutbound kann ein Callback für alle HTTP-Anfragen registriert werden, um Anfragen zu prüfen, umzuschreiben, Auth-Keys einzuschleusen oder zu blockieren
• Credential Injection (Token Injection): Wenn der Agent HTTP-Anfragen an Dienste sendet, die Authentifizierung erfordern, werden Credentials in ausgehende Anfragen eingefügt, sodass der Agent die geheimen Credentials selbst nicht kennt
• Das ist nützlich, wenn bekannte APIs im Trainingsdatensatz des Agenten enthalten sind oder wenn REST-API-basierte Bibliotheken innerhalb der Sandbox ausgeführt werden
• Wenn keine Kompatibilitätsanforderungen bestehen, ist ein TypeScript-RPC-Interface HTTP überlegen: geringerer Token-Verbrauch, kompakterer Aufrufcode und eine präzisere Begrenzung der API-Oberfläche

Bewährte Sicherheitsarchitektur

• Isolate-basierte Sandboxen haben eine komplexere Angriffsfläche als Hardware-VMs, und Sicherheitsfehler in V8 treten häufiger auf als bei allgemeinen Hypervisoren
• Cloudflare verfügt über rund 10 Jahre Erfahrung beim Absichern einer isolate-basierten Plattform
• V8-Sicherheitspatches werden innerhalb von Stunden und schneller als in Chrome in die Produktion ausgerollt
• Einsatz einer eigenen Sandbox-Schicht der zweiten Ebene sowie dynamisches Tenant-Cordoning auf Basis von Risikobewertungen
• Erweiterung der V8-Sandbox mithilfe von Hardware-Features wie MPK
• Entwicklung neuer Schutzmechanismen wie Spectre-Abwehr in Zusammenarbeit mit der TU Graz
• Betrieb von Systemen zum automatischen Scannen bösartiger Muster sowie zu deren Blockierung oder zusätzlichem Sandboxing

Helper-Bibliotheken

Code Mode (@cloudflare/codemode)

• Eine Bibliothek, die die Ausführung von vom Modell erzeugtem Code gegen AI-Tools mit Dynamic Workers vereinfacht
• Zentral ist DynamicWorkerExecutor(), das häufige Formatierungsfehler per Code-Normalisierung behandelt und direkten Zugriff auf den globalOutbound-Fetcher ermöglicht
• codeMcpServer({ server, executor }) kapselt einen bestehenden MCP-Server und ersetzt die Tool-Oberfläche durch ein einzelnes code()-Tool
• openApiMcpServer({ spec, executor, request }) nimmt eine OpenAPI-Spezifikation und einen Executor entgegen und erstellt automatisch einen vollständigen MCP-Server mit den Tools search() und execute()

Bundling (@cloudflare/worker-bundler)

• Erzeugt die vorab gebündelten Module, die Dynamic Workers erwarten
• Übergibt man Quelldateien und package.json, werden npm-Abhängigkeiten aufgelöst, mit esbuild gebündelt und die vom Worker Loader erwartete Modultabelle zurückgegeben
• Unterstützt über createApp Full-Stack-Apps, bei denen Server-Worker, Client-JavaScript und statische Assets gemeinsam gebündelt werden
• Einschließlich integriertem Asset-Serving für Content-Type, ETag und SPA-Routing

Dateiverarbeitung (@cloudflare/shell)

• Stellt dem Agenten innerhalb eines Dynamic Workers ein virtuelles Dateisystem bereit
• Über typisierte Methoden des state-Objekts sind read, write, search, replace, diff, glob, JSON-Abfragen/-Updates, Archivierung und mehr möglich
• Der Speicher wird durch einen persistenten Workspace (SQLite + R2) abgesichert, sodass Dateien zwischen Ausführungen erhalten bleiben
• Groß angelegte Operationen wie searchFiles, replaceInFiles und planEdits minimieren RPC-Roundtrips — statt Schleifen über einzelne Dateien erfolgt ein einzelner Aufruf
• Batch-Schreibvorgänge sind standardmäßig transaktional: Scheitert auch nur einer, werden frühere Schreibvorgänge automatisch zurückgerollt
• Enthält vorgefertigte TypeScript-Typdeklarationen und Vorlagen für System-Prompts

Anwendungsfälle

Einsatz von Code Mode

• Statt sequentieller Tool-Aufrufe schreibt der Agent eine einzelne TypeScript-Funktion, die mehrere API-Aufrufe verkettet, führt sie in einem Dynamic Worker aus und gibt nur das Endergebnis zurück
• Da nicht die Zwischenschritte, sondern nur die Ausgabe ins Kontextfenster gelangen, sinken sowohl Latenz als auch Token-Verbrauch
• Der Cloudflare-MCP-Server ist auf diese Weise aufgebaut und stellt die gesamte Cloudflare-API mit nur 2 Tools (search, execute) und weniger als 1.000 Tokens bereit

Aufbau benutzerdefinierter Automatisierung

• Zite entwickelt eine App-Plattform, mit der Nutzer über eine Chat-Oberfläche interagieren
• Im Hintergrund schreibt das LLM TypeScript, um CRUD-Apps zu erzeugen, Stripe, Airtable und Google Calendar zu verbinden und Backend-Logik auszuführen
• Jede Automatisierung läuft in ihrem eigenen Dynamic Worker und hat nur Zugriff auf die jeweils benötigten Dienste und Bibliotheken
• Laut Zite-CTO Antony Toron war es als „sofortige, isolierte und sichere Ausführungsschicht“ unter allen getesteten Plattformen am schnellsten und bei der Bibliotheksunterstützung am leistungsfähigsten; aktuell werden täglich Millionen Ausführungsanfragen verarbeitet

Ausführung von AI-generierten Anwendungen

• Eignet sich auch für den Aufbau von Plattformen, die vollständige Anwendungen per AI erzeugen
• Jede App wird on demand erzeugt und bis zum nächsten Aufruf in Cold Storage gehalten
• Dank der schnellen Startzeit lassen sich Änderungsvorschauen während aktiver Entwicklung leicht bereitstellen
• Durch Blockieren oder Abfangen der Netzwerkzugriffe des erzeugten Codes wird die sichere Ausführung AI-generierter Apps gewährleistet

Preismodell

• Dynamisch geladene Workers werden mit $0.002 pro eindeutigem Worker-Load und Tag berechnet (zzgl. CPU-Zeit- und Request-Kosten normaler Workers)
• Im AI-generierten „Code Mode“-Use-Case sind alle Workers einmalig, daher fallen $0.002 pro Load an; verglichen mit den Inferenzkosten für die Code-Erzeugung ist das in der Regel vernachlässigbar
• Während der Beta entfällt die Gebühr von $0.002