LangChain: Nicht vertrauenswürdigen Agenten-Code ohne externen Sandbox ausführen

Die Ausführung von Code, den ein KI-Agent generiert hat, barg immer ein inhärentes Sicherheitsrisiko: Was, wenn der Agent — manipuliert durch Prompt Injection — schädlichen Code generiert? Die übliche Lösung waren externe Sandboxes — separate Prozesse, Docker-Container oder virtuelle Maschinen. Hunter Lovell vom LangChain-Team schlägt nun eine elegantere Lösung vor: nicht vertrauenswürdigen Agenten-Code innerhalb des Prozesses auszuführen, aber hinter einer festen Speichergrenze.

Warum klassische Ansätze nicht ausreichen?

Externe Sandboxes lösen das Isolationsproblem, bringen aber eigene Komplikationen mit sich: Kommunikationslatenz zwischen Prozessen, komplexes Lifecycle-Management und — besonders schmerzhaft für Agenten — die Unmöglichkeit, den Zustand natürlich zwischen Schritten beizubehalten, die menschliche Genehmigung erfordern.

Lovells Technik basiert auf einer zentralen Erkenntnis: WebAssembly (WASM) bietet ausreichende Grenzenisolation innerhalb eines einzelnen Prozesses, ohne externen Container. AWS, Shopify und Figma verwenden bereits WASM-Grenzen für ähnliche Zwecke in Produktionsumgebungen.

Drei Sicherheitssäulen dieser Architektur

Lovell definiert drei Bedingungen, die jedes System zur Ausführung nicht vertrauenswürdigen Agenten-Codes erfüllen muss:

Ausführungsisolation. Agenten-Code darf das Host-System nicht kompromittieren können. WASM erreicht dies durch seinen eigenen linearen Speicherraum — eine sandboxte In-Process-VM, die außerhalb des zugewiesenen Bereichs weder lesen noch schreiben kann. Die Runtime setzt Speicher- und Ausführungsgrenzen auf Architekturebene durch, ohne sich auf die Disziplin des ausgeführten Codes zu verlassen.

Kapazitätsisolation. Der Agent erhält standardmäßig keinen Zugriff auf das Dateisystem, Netzwerk oder externe Abhängigkeiten. Alle Fähigkeiten müssen explizit über den Harness mit engen Verträgen überbrückt werden. Dies implementiert das Prinzip der geringsten Privilegien auf Architekturebene — der Agent kann nur das, was ihm programmatisch gewährt wurde, nichts mehr.

Persistente Pausen mit Zustand. Die Ausführung muss anhalten und auf menschliche Genehmigung warten können, um dann ohne Kontextverlust fortgesetzt zu werden. Lovell löst dies durch Serialisierung des linearen Speicherraums des Interpreters in den LangGraph-Zustand — ein Snapshot, der gespeichert wird und von dem aus das Programm genau dort fortgesetzt werden kann, wo es aufgehört hat.

Auswahl von QuickJS für die Orchestrierung

Von allen verfügbaren JavaScript-Engines wählte LangChain QuickJS — eine kleine, schnelle, ECMA-konforme Runtime, geschrieben in C. Der Grund ist dreifach: Sie kompiliert sauber in WASM (was bedeutet, dass die Engine selbst hinter der Grenze sitzt, nicht neben ihr), ist ausdrucksstark genug für Orchestrierungsskripte, und erfordert keinen Kompilierungsschritt für kurze Programme — was die Latenz beim Start von Agenten-Skripten eliminiert.

Agenten in diesem Modell schreiben kurze JavaScript-Orchestrierungsskripte, anstatt Unteragenten einzeln zu dispatchen. Diese Verschiebung ändert den Arbeitsmodus: Der Agent definiert den Ausführungsfluss deklarativ, und der Harness führt ihn mit kontinuierlicher Kapazitätsprüfung und expliziten Überbrückungen durch.

Verweis auf Metas Sicherheitsprinzip

Lovell zitiert explizit Metas Sicherheitsprinzip, das besagt, dass ein Agent nicht gleichzeitig Zugriff auf sensible Daten haben, nicht vertrauenswürdigen Eingaben ausgesetzt sein und die Möglichkeit haben darf, externen Zustand zu ändern oder nach außen zu kommunizieren. Die Kombination aller drei Faktoren — unabhängig von der Raffinesse des restlichen Systems — macht eine Agenten-Architektur unsicher.

Der QuickJS-WASM-Ansatz adressiert direkt die zweite und dritte Bedingung: Ohne standardmäßigen Netzwerk- oder Systemzugriff hat selbst ein kompromittierter Agent einen dramatisch begrenzten Wirkungsradius.

Zwei neue Open-Source-Bibliotheken

Zusammen mit dem Artikel hat LangChain zwei experimentelle Open-Source-Bibliotheken freigegeben:

• quickjs-rs — Runtime und Python-Bindings für QuickJS über WASM, den Entwicklergemeinschaften als Grundlage für eigene Implementierungen zur Verfügung gestellt
• langchain-quickjs — Deep-Agents-Middleware, die quickjs-rs mit LangGraph integriert, einschließlich Mechanismen für persistente Pausen und Zustandsserialisierung zwischen Schritten

Beide sind als experimentell gekennzeichnet — die API kann sich zwischen Versionen ändern, aber das grundlegende Architektur- und Sicherheitsmodell ist stabil.

Implikationen für produktive Agenten-Architektur

Die Lösung des zuverlässigen Ausführens von generiertem Code ist eine der zentralen technischen Herausforderungen auf dem Weg zu produktionsrobusten autonomen Agenten. Prompt Injection bleibt ein offenes Problem — aber wenn ein Agent, selbst wenn er erfolgreich manipuliert wurde, ohne explizite Genehmigung nicht auf das Dateisystem, Netzwerk oder externe Dienste zugreifen kann, reduziert sich der mögliche Schadensradius dramatisch.

LangChains Ansatz ist kein Allheilmittel: Er erfordert sorgfältiges Design von Kapazitätsüberbrückungen und Disziplin bei der Definition enger API-Verträge. Aber eine Architektur, die in einem Zug Ausführungs-, Kapazitäts- und Zustandsisolation löst — ohne externen Container und ohne Kompromisse bei der Latenz — ist ein relevanter Fortschritt für jeden, der 2026 produktive Agenten-Systeme aufbaut.