AI Agent Sandbox: Warum isolierte Code-Ausführung Pflicht ist

Wenn du einen KI-Agenten auf geteilter Infrastruktur Code ausführen lässt, hast du bereits verloren. Das ist die unbequeme Schlussfolgerung nach einem Jahr produktiver KI-Workloads bei CodeCourier. Das Modell ist nicht bösartig - die Inputs sind es. Prompt Injection, Supply-Chain-Vergiftung, Endlos-Prozesse und still korrumpierte Caches finden jede Naht in einer nicht-isolierten Umgebung. Die einzige glaubwürdige Antwort heißt AI Agent Sandbox: eine frische, hardware­isolierte Linux-Maschine, die in unter einer Sekunde bootet, die Instruktionen des Agenten entgegennimmt und in dem Moment geschreddert wird, in dem der Lauf endet.

Dieser Beitrag ist die technische Pillar-Erklärung, die wir versprochen haben. Er deckt das Threat Model ab, den Vergleich zwischen Containern, microVMs und vollwertigen VMs, wie wir E2B-gestützte Firecracker microVMs in unter einer Sekunde bereitstellen, wie wir Dateisysteme und Netzwerke eng halten, wie Secrets niemals persistieren, wie wir jede Aktion für das Audit aufzeichnen, und die sieben konkreten Lektionen, die wir auf die harte Tour gelernt haben. Wenn du Agenten baust, die Code anfassen, entscheidet die Substrat-Frage darüber, ob du am Freitagabend ruhig schlafen kannst.

Warum Sandboxes für KI-Engineers nicht verhandelbar sind

Eine AI Agent Sandbox ist eine ephemere, isolierte Ausführungs­umgebung - üblicherweise eine ephemere VM oder microVM - in der ein autonomer Agent Code, Befehle und Tools ohne Zugriff auf Host-Ressourcen, andere Tenants oder persistenten State ausführt. Sie ist der Unterschied zwischen einem Agenten, der einen Pull Request entwirft, und einem Agenten, der eine CVE in deine Supply Chain einschleust.

Drei Eigenschaften machen eine Sandbox zu einer Sandbox - nicht nur zu einem Container mit guten Absichten:

1. Hardware-Isolation. Die Grenze wird vom Hypervisor durchgesetzt, nicht von den Kernel-Namespaces, neben denen er läuft. Aus einem Container-Escape wird ein microVM-Escape - Größenordnungen schwerer.
2. Ephemeralität. Disk, RAM und Netzwerk-State verschwinden, wenn der Lauf endet. Keine Caches, keine zurückgelassenen Sockets, keine Temp-Dateien mit Bearer-Tokens.
3. Sub-Sekunden-Provisioning. Wenn der Kaltstart langsam ist, umgehen Engineers ihn und teilen Sandboxes zwischen Läufen. Sobald das passiert, ist die Isolation weg.

Lass eine der drei Eigenschaften weg und du hast keine Sandbox. Du hast einen Container mit Marketing-Budget.

Das Threat Model - was ohne Isolation schiefgeht

Jedes Team, mit dem ich rede, unterschätzt die Angriffsfläche eines autonomen Agenten. Das Modell ist nicht-deterministisch, die Inputs sind angreifer­kontrolliert, die Tools sind by Design mächtig. Hier ist der Threat-Katalog, gegen den wir unsere Architektur gebaut haben.

1. Prompt-Injection-Containment versagt

Ein Issue-Ticket, eine README, ein Kommentar in einer Dependency - jeder Text, den der Agent einliest, ist eine Instruktion, der er folgen könnte. Wir haben Agenten gesehen, die überredet wurden, mit git push auf ein angreifer­kontrolliertes Remote zu pushen, .env-Dateien per curl-Einzeiler zu exfiltrieren oder ein Paket zu installieren, dessen Post-Install-Skript in ~/.ssh/authorized_keys schreibt. Eine Sandbox verhindert die Prompt Injection nicht. Sie begrenzt den Schaden auf eine Disk, die in fünfzehn Minuten zerstört wird.

2. Supply-Chain-Vergiftung

Jedes npm install führt beliebigen Code aus. Jedes pip install auch. Ein typo­squattendes Paket, ein kompromittierter Maintainer, ein bösartiger Post-Install-Hook - dein Agent wird sie alle fröhlich ausführen. Ohne Sandbox bekommt der Host die Backdoor. Mit Sandbox bekommt sie die Wegwerf-VM, und es ist niemandem wichtig.

3. Exfiltration über DNS, HTTP oder git

Ein entschlossener Exfiltrations­kanal ist nur ein curl -d @secrets.txt entfernt. Auf einem geteilten Host vermischt sich der Traffic mit legitimem Traffic. In einer Sandbox mit Deny-by-Default-Egress-Allowlist schlägt der Request fehl und wir loggen ihn.

4. Endlos-Prozesse und Ressourcen­erschöpfung

Ein Agent, der einen flaky Test in einer while true-Schleife wiederholt, frisst jeden CPU-Zyklus, den er erreichen kann. Ohne Per-VM-Quoten reißt ein einziger schlechter Lauf den Host und alle darauf herunter. Mit Quoten erreicht die VM ihre Decke, der Agent kriegt das OOM-Signal, und der Rest der Plattform merkt nichts.

5. Cross-Tenant-Datenleck

Wenn zwei Kunden sich einen Prozess, einen Kernel oder auch nur ein Filesystem teilen, hast du einen Seitenkanal gebaut. Spekulative-Execution-Angriffe, /proc-Traversal, geteilte Temp-Verzeichnisse - die Geschichte der Multi-Tenant-Sicherheit ist die Geschichte, neue Varianten dieses Bugs zu finden. Eine microVM mit eigenem Kernel eliminiert die Kategorie.

Container vs. microVM vs. vollwertige VM - der Vergleich, der zählt

Ich werde dauernd gefragt, warum wir nicht einfach Docker genommen haben. Hier ist die Tabelle, die ich zurückschicke.

Eigenschaft	Container (Docker)	microVM (Firecracker / E2B)	Vollwertige VM (KVM, EC2)
Isolations­grenze	Kernel-Namespaces, cgroups	Hypervisor, dedizierter Kernel	Hypervisor, dedizierter Kernel
Kaltstart	100 ms - 2 s	150 ms - 400 ms	20 s - 90 s
Memory-Overhead	~5 MB	~5 MB	100 - 500 MB
Dichte pro Host	Hunderte	Tausende	Dutzende
Kernel-Exploit-Resistenz	Niedrig - geteilter Kernel	Hoch - eigener Kernel pro VM	Hoch - eigener Kernel pro VM
Filesystem-Isolation	Layered, oft geteilte Layer	Block-Device pro VM	Block-Device pro VM
Eignung für untrusted Code	Riskant	Genau dafür gebaut	Ja, aber langsam

Container gewinnen bei Tooling und Ökosystem. Vollwertige VMs gewinnen für unseren Use Case nichts - sie sind zu langsam, um pro Request bereitgestellt zu werden. Firecracker microVMs treffen den einzigen Punkt der Kurve, der für KI-Agenten zählt: Hardware-Isolation bei Container-Geschwindigkeit. Das ist der technische Grund, warum E2B existiert, und der Grund, warum wir darauf gesetzt haben.

Wie CodeCourier Sandboxes in unter einer Sekunde bereitstellt

Die Architektur basiert auf vier Primitiven: einem vorgewärmten Pool, Snapshot-Restore, Template-Images und einer dünnen Orchestrierungs­schicht zwischen unserer Control Plane und der E2B-API. Hier der Pfad, den eine Sandbox vom Request bis zur Bereitschaft nimmt.

1. Request landet beim Sandbox-Manager. Der Workflow-Runner fragt eine Sandbox mit Template (z.B. node20-postgres), Region, CPU/RAM-Form und Egress-Policy an.
2. Pool-Lookup. Wir halten einen Warm-Pool pausierter microVMs pro Template pro Region. Bei Treffer überspringen wir den Boot komplett.
3. Snapshot-Restore. Eine getroffene VM wird in rund 120 - 180 ms aus einem Memory-Snapshot wieder­hergestellt. Kernel, Paketmanager und Sprach-Runtime sind schon im RAM.
4. Cold Path. Ist der Pool leer, booten wir eine frische microVM aus dem Basis-Template-Image. Firecracker meldet ready in 150 - 250 ms; Gesamtzeit inklusive Orchestrierungs-Overhead liegt bei 300 - 600 ms.
5. Secrets und Policy injizieren. Kurzlebige Per-Step-Credentials gehen über einen Memory-only-Init-Kanal an den Agenten. Egress-Regeln werden im Host-Netzwerk-Namespace gesetzt, bevor der Agent den ersten Befehl ausführt.
6. Handle an den Workflow. Der Orchestrator gibt eine opake Sandbox-ID zurück. Der Agent fängt an zu arbeiten.

End-to-End-Median über die letzten 30 Tage Produktion: 520 ms. p99: 1,4 s. Cold Path (kein Pool-Hit): 1,8 s p50. Das ist die Zahl, die es dem User-facing-Dashboard erlaubt, "Starte Sandbox" zu sagen - ohne Spinner.

Ein repräsentativer Ausschnitt aus unserem Orchestrator (TypeScript, vereinfacht):

import { Sandbox } from 'e2b';

async function provision(opts: {
  template: string;
  region: 'us-east' | 'eu-west';
  egressAllowlist: string[];
  stepSecrets: Record<string, string>;
}) {
  const warm = await pool.tryClaim(opts.template, opts.region);
  const sbx = warm ?? await Sandbox.create(opts.template, {
    region: opts.region,
    timeoutMs: 15 * 60 * 1000,
  });

  await applyEgressPolicy(sbx.id, opts.egressAllowlist);
  await injectSecrets(sbx.id, opts.stepSecrets); // memory-only

  return sbx;
}

Die volle Maschinerie - Pool-Sizing, Eviction, Snapshot-Generationen, Region-Failover - lebt hinter dieser Oberfläche. Siehe wie wir Sandboxes betreiben für die Produkt-Sicht.

Filesystem- und Netzwerk-Isolation in der Praxis

Isolation ist eine Eigenschaft, die du auf jeder Schicht durchsetzen musst - sonst hast du keine. Wir behandeln Filesystem und Netzwerk als die zwei primären Schutztüren.

Filesystem. Jede Sandbox bekommt ihr eigenes Block-Device, gestützt auf eine Kopie des Template-Images. Es gibt kein Overlay, das mit dem Host geteilt wird. Der Agent hat root innerhalb der VM und exakt nichts außerhalb. Writes persistieren nicht über Läufe hinweg, es sei denn, der Workflow pusht Artefakte explizit in Objekt­speicher oder git. Endet der Lauf, wird das Block-Device gewipt, bevor der Slot zurück in den Pool geht.

Netzwerk. Default-Policy ist Deny-All-Egress mit einer kuratierten Allowlist: dem Git-Host des Kunden, gängigen Paket-Registries (npmjs.org, pypi.org, crates.io) und dem LLM-Endpoint. Alles andere wird an der Host-Firewall verworfen. Kunden können die Allowlist pro Projekt erweitern - aber nie pro Lauf und nie über den Agenten selbst. Sonst dürfte Prompt Injection ihre eigenen Mauern umschreiben.

DNS löst über unseren eigenen Resolver auf, der jeden Lookup loggt. Eine überraschende Zahl an Exfiltrations­versuchen taucht als DNS-Query zu angreifer­eigenen Domains auf, lange bevor ein HTTP-Request feuert. Dort fangen wir sie.

Secrets-Handhabung - niemals leaken, niemals persistieren

Jeder Secrets-Bug, den wir je ausgeliefert haben, kam von einem Secret, das länger gelebt hat als nötig. Unsere Regel: kurzlebig, eng skopiert, nie auf Disk, nie in Logs. Konkret:

• Per-Step-Tokens, nicht Per-Run. Ein Workflow mit zwölf Schritten prägt zwölf unterschiedliche Credentials, jedes gültig für die Dauer des Schritts plus einen kleinen Gnade-Slot.
• Memory-only-Injection. Secrets gehen durch eine tmpfs-gestützte Env-Datei, die bei Prozess­ende unmountet wird. Sie berühren keinen persistenten Speicher.
• Log-Scrubbing auf der Streaming-Schicht. Stdout und stderr laufen durch einen Redactor, bevor sie unsere Datenbank, das Dashboard oder menschliche Augen erreichen.
• Kein agentenlesbarer Secret-Store. Der Agent kann verfügbare Secrets nicht enumerieren. Er kann nur die nutzen, die der Workflow ausdrücklich an den aktuellen Schritt gebunden hat.
• Automatische Sperrung bei Anomalie. Sieht unsere Audit-Pipeline ein Credential außerhalb seines deklarierten Scopes, wird es innerhalb von Sekunden widerrufen.

Compliance dokumentiert das im Detail - siehe SOC 2 und GDPR - aber die ingenieur­technische Substanz sind die fünf Punkte oben.

Observability - jede Agenten-Aktion fürs Audit aufzeichnen

Ein autonomer Agent ohne Tonband ist eine Haftung. Wir streamen jedes relevante Ereignis in Echtzeit aus der Sandbox und persistieren es in unveränderlichen Speicher:

• Jeden ausgeführten Befehl, mit Argumenten, Arbeits­verzeichnis, Exit-Code und Dauer.
• Jeden geschriebenen oder gelesenen File-Zugriff über einem konfigurierbaren Größen­schwellwert, mit Content-Hash.
• Jede ausgehende Netzwerk­verbindung, die aufgelöste IP, den Zielport und die Zahl übertragener Bytes.
• Jeden LLM-Call aus der Sandbox, inklusive Modell, Token-Counts und der vom Modell emittierten Tool-Calls.
• Jedes Secret-Materialisierungs-Event, geschrubbt vom Secret-Wert selbst.

Das Ergebnis ist eine forensische Timeline, die du im Dashboard replayen oder in dein SIEM pipen kannst. Fragt ein Enterprise-Security-Team "was hat der Agent am 4. März um 14:32 tatsächlich gemacht?", antworten wir in Sekunden, nicht Tagen. Dieselbe Pipeline füttert unser nächtliches Red-Team - siehe die Security-Übersicht für das adversarial Setup.

Lektionen aus einem Jahr KI in Sandboxes

Über Isolation zu lesen ist eine Sache. Sie auf echten Workloads zu betreiben eine andere. Hier sind die sieben Lektionen, für die wir wirklich bezahlt haben - mit Zahlen.

Lektion 1 - geteilte Caches sind ein Security-Incident, der nur wartet

Unser erster Prototyp teilte einen npm-Cache zwischen Sandboxes, um 8 - 12 Sekunden bei Installs zu sparen. Funktionierte wunderbar, bis ein Agent ein typo­squattendes Paket installierte, dessen Post-Install-Skript eine Backdoor ins Cache-Verzeichnis schrieb. Die nächsten zwanzig Läufe haben sie aufgegabelt. Wir entfernten den geteilten Cache am selben Tag. Der Fix war, die Top-200-Pakete ins Template-Image zu backen - das brachte den Großteil der Geschwindigkeit zurück, ohne Shared-State-Risiko.

Lektion 2 - vorgewärmte Pools schlagen optimierte Kaltstarts

Wir verbrachten zwei Wochen damit, 80 ms vom Firecracker-Cold-Path abzuhobeln. Dann bauten wir einen Warm-Pool und bekamen pro Cache-Hit 280 ms gratis zurück. Lektion: optimiere den langsamen Pfad nicht, bevor du ihn eliminiert hast. Heute treffen 87% unserer Sandbox-Provisionierungen den Pool. Median-Provisioning­zeit fiel in einer Woche von 1,4 s auf 520 ms.

Lektion 3 - langlebige Tokens sind ein Eigentor

Früher prägten wir pro Workflow-Lauf ein einzelnes git-push-Token, gültig für den ganzen Lauf. Bequem. Auch nur eine Prompt Injection von der Katastrophe entfernt. Wir bauten die Credentials-Schicht neu und prägen Per-Step-Tokens mit 60 Sekunden TTL plus explizitem Renewal-Handshake. Unser Worst-Case-Expositions­fenster fiel von 40 Minuten auf unter 2.

Lektion 4 - Observability rechnet sich in Woche drei

Als ein Kunde zum ersten Mal fragte, warum sein Workflow 14 Minuten länger als sonst gedauert habe, replayten wir die Timeline, fanden ein flaky npm install, das gegen einen langsamen Mirror retried, und patchten das Template am selben Nachmittag. Dieser eine Vorfall rechtfertigte den gesamten Observability-Stack. Drei Monate später nutzen wir diese Timelines mehr zum Debugging als zur Security.

Lektion 5 - Fair-Share-Scheduling stoppt laute Nachbarn

Ein Kunde fuhr einen Workflow, der 100 parallele Test-Suiten in einer einzigen Sandbox spawnte. Die Sandbox war okay - das I/O-Budget des Hosts nicht. Nachdem wir Per-Sandbox-I/O-Quoten und Per-Tenant-Concurrency-Caps mit Fair-Share-Scheduler ergänzten, fiel die p99-Latenz für alle anderen um 38% - und wir sahen das Problem nie wieder.

Lektion 6 - Snapshots sind Phase-Eins, nicht Phase-Zwei

Wir behandelten Sandbox-Snapshots die ersten sechs Monate als Nice-to-have. Kunden mit mehrstündigen Workflows liefen in Rate Limits, transiente Modell-Ausfälle oder flaky Tests - und mussten jedes Mal bei Null beginnen. Als wir Snapshotting auslieferten, fielen die Kosten pro erfolg­reichem Lauf um 23%, und kundengemeldete "Workflow ist grundlos gestorben"-Tickets gingen in zwei Wochen auf Null.

Lektion 7 - das Audit-Log ist das Produkt

Jeder Enterprise-Sales-Zyklus erreicht irgendwann die Frage "beweise, dass der Agent genau das gemacht hat, was er behauptet". Wir dachten, die Antwort sei das Ergebnis. Die Antwort ist die Timeline. Behandle dein Audit-Log als erstklassiges User-Interface, nicht als Compliance-Artefakt. Unsere Deal-Geschwindigkeit verdoppelte sich grob, nachdem wir die Timeline-Ansicht im Dashboard ausgelieferten.

Wann KEINE Sandbox

Ich bin in diesem Punkt nicht dogmatisch. Es gibt echte Fälle, in denen eine Sandbox Overkill oder sogar kontraproduktiv ist:

• Reine Inferenz, kein Tool-Use. Wenn der Agent nur aus einer API liest und eine Markdown-Zusammenfassung schreibt, brauchst du keine microVM. Du brauchst eine stateless Function.
• Hoch latenz­sensitive interaktive UX, in der du jeden Input kontrollierst. Ein Code-Completion-Modell auf der eigenen Maschine eines Entwicklers, ohne untrusted Input im Loop, ist seine eigene Vertrauens­grenze.
• Tief integrierte IDE-Plugins. Wenn der Agent per Definition als der Entwickler agiert, hebelt es den Zweck aus, ihn vom Repo des Entwicklers zu sandboxen. Sandbox das Netzwerk, nicht das Filesystem.

Die Linie, die wir bei CodeCourier ziehen: Jeder Agent, der Code im Auftrag eines anderen Users als sich selbst ausführt, läuft in einer Sandbox. Alles andere ist Case-by-Case. Wenn du Issue Sessions, Personas oder den Workflow Builder einsetzt, bist du auf der Sandbox-Seite.

FAQ - AI Agent Sandboxes

Was ist eine AI Agent Sandbox?

Eine AI Agent Sandbox ist eine ephemere, hardware­isolierte Ausführungs­umgebung - meist eine microVM - in der ein autonomer Agent Code ausführt, Pakete installiert, Befehle ausführt und Tools verwendet. Sie wird zerstört, wenn der Lauf endet - nichts, was der Agent macht, persistiert, es sei denn, der Workflow exportiert es ausdrücklich.

Warum ist eine microVM besser als ein Docker-Container für KI-Agenten?

Ein Docker-Container teilt den Host-Kernel. Ein Kernel-Exploit, eine fehlkonfigurierte Capability oder ein Namespace-Escape gibt einem Angreifer den Host. Eine microVM läuft mit eigenem Kernel unter einem Hypervisor; ein Escape verlangt, den Hypervisor zu brechen - ein deutlich härteres Ziel. Für untrusted Code - und LLM-generierter Code ist per Definition untrusted - sind microVMs die konservative Wahl.

Wie erreicht E2B Sub-Sekunden-Sandbox-Start?

E2B nutzt Firecracker microVMs, die in 100 - 250 ms booten, weil sie jedes Device, jede BIOS-Routine und jedes Kernel-Modul weglassen, das ein Serverless-Workload nicht braucht. Obendrauf halten wir einen vorgewärmten Pool pausierter VMs pro Template. Ein Pool-Hit restored in rund 120 - 180 ms aus einem Memory-Snapshot.

Kann Prompt Injection aus einer Sandbox ausbrechen?

Prompt Injection kann die Sandbox-Grenze selbst nicht durchbrechen - die wird vom Hypervisor durchgesetzt, nicht vom Modell. Was Prompt Injection kann: den Agenten überreden, die Ressourcen zu missbrauchen, die er innerhalb der Sandbox legitim hat - Exfiltration über einen allowlisted Endpoint, Push auf das falsche git-Remote, Credit verbrennen. Die Verteidigung ist mehr­schichtig: strikte Egress-Allowlists, Per-Step-Credentials mit engem Scope, und Observability, die anomale Tool-Calls in Echtzeit markiert.

Wie lange lebt eine Sandbox?

Default: fünfzehn Minuten Idle-Zeit vor automatischer Zerstörung, mit einem absoluten Maximum, das pro Workflow konfigurierbar ist. Lange Workflows nutzen unser Snapshot-Protokoll, um über die Lebensdauer eines einzelnen Laufs zu pausieren und fortzusetzen.

Wohin gehen Kunden-Artefakte, nachdem die Sandbox zerstört wurde?

Wohin auch immer der Workflow sie explizit legt. Branches pushen zum Git-Host des Kunden. Artefakte laden in den Objekt­speicher. Sonst überlebt nichts. Das Block-Device wird gewipt, bevor der Slot zurück in den Pool geht.

Ist die AI Agent Sandbox SOC-2- und GDPR-konform?

Ja. CodeCourier ist SOC 2 Type II und betreibt eine EU-only Data Plane für GDPR-sensitive Workloads. Siehe SOC 2 und GDPR für die vollständigen Kontrollen.

Wo erfahre ich mehr?

Starte mit unseren Guides, durchstöbere den Engineering-Blog oder lies über das Team. Willst du mit uns über einen konkreten Workload sprechen, melde dich.