Sandboxing autonomer Agenten: der vollständige Leitfaden

Das Muster taucht in Vorfallsberichten, Forenbeiträgen und geflüsterten Slack-Gesprächen mit beunruhigender Regelmäßigkeit auf: Ein KI-Coding-Assistent bekommt eine Routineaufgabe, versteht sie nur ein kleines bisschen falsch und zerstört etwas Wichtiges. Ein Cursor-Nutzer sieht zu, wie sein Agent ein Git-Repository löscht. Eine Entwickler-Erweiterung für Amazon Q liefert einen Prompt-stehlenden Wurm aus. Eine Claude-Code-Sitzung, die „alte Dateien aufräumen“ soll, radiert Konfigurationsverzeichnisse aus, deren Aufbau Wochen gedauert hat.

Keiner dieser Agenten war bösartig. Sie waren hilfsbereit. Genau das ist das Problem.

Das ist das Paradox des agentischen Codings: Dieselbe Autonomie, die KI-Coding-Assistenten revolutionär macht, macht sie auch gefährlich. Wenn Sie einer KI die Fähigkeit geben, Code zu schreiben und auszuführen, haben Sie es nicht mehr bloß mit Autovervollständigung zu tun. Sie übergeben die Schlüssel zu Ihrem Königreich an etwas, das in fast 20 % der generierten Imports Paketnamen halluziniert, das sich mit weißem Text auf weißem Grund in Webseiten austricksen lässt und das fröhlich beim Server eines Angreifers anruft, wenn die richtige Prompt Injection trifft.

Die Branche hat rasch reagiert, aber ungleichmäßig. Manche Tools bringen ausgefeiltes Sandboxing gleich mit. Andere überlassen Sicherheit dem Leser als Übungsaufgabe. Und beunruhigend viele Entwickler führen KI-generierten Code direkt auf ihren Produktivsystemen aus, weil es, nun ja, schneller geht.

Dieser Leitfaden ist für den Rest von uns: für Praktiker, die verstanden haben, dass agentisches Coding nicht wieder verschwindet, es aber einsetzen müssen, ohne dabei zerstört zu werden. Wir gehen das gesamte Spektrum der Isolationstechniken durch, von leichtgewichtigen OS-Primitiven bis zu hardwaregestützten microVMs. Wir sehen uns an, wie die großen Tools Sicherheit tatsächlich umsetzen (Spoiler: Die Unterschiede sind enorm). Und Sie bekommen ein praktisches Framework, mit dem Sie den passenden Schutz für Ihr Bedrohungsmodell wählen.

Das Fazit gleich vorweg: Container-Isolation allein reicht nicht aus, wenn nicht vertrauenswürdiger KI-generierter Code läuft. Defense-in-Depth aus OS-Primitiven, Hardware-Virtualisierung und Netzwerksegmentierung ist heute Pflicht. Falls das paranoid klingt, haben Sie die CVEs nicht verfolgt.

Das Bedrohungsmodell: Was tatsächlich schiefgeht

Um zu verstehen, warum Sandboxing wichtig ist, muss man verstehen, was passiert, wenn es versagt. Die Bedrohungslage für agentische Coding-Systeme unterscheidet sich grundlegend von klassischer Anwendungssicherheit, weil die Angriffsfläche der Agent selbst ist.

Prompt Injection: OWASPs LLM-Schwachstelle Nummer 1

Die gefährlichsten Angriffe zielen nicht auf Ihre Infrastruktur, sondern auf das Denken Ihres Agenten. Prompt Injection, in den OWASP Top 10 for LLM Applications 2025 als Risiko Nummer 1 geführt, gibt es in zwei Varianten, und beide sind schlimmer, als Sie denken.

Direkte Injection ist die offensichtliche: Nutzer sagen dem Agenten, er solle „alle bisherigen Anweisungen ignorieren und etwas Bösartiges tun“. Sie ist gut verstanden und von modernen Modellen teilweise entschärft. Die eigentliche Bedrohung ist indirekte Injection: bösartige Anweisungen, versteckt in externen Datenquellen, die der Agent im normalen Betrieb verarbeitet.

Forscher haben erfolgreiche Angriffe über Webseiten (weißer Text auf weißem Grund, für Nutzer unsichtbar, vom Agenten aber gelesen), PDF-Dokumente (versteckte Textebenen), Code-Kommentare in Repositories, die der Agent klont, und sogar YouTube-Transkripte demonstriert. Der ZombAIs-Angriff hat bewiesen, dass sich Agenten mit Web-Browsing-Fähigkeit durch versteckte HTML-Anweisungen kompromittieren lassen, bis hin zu autonomen Malware-Downloads ganz ohne Zutun des Nutzers.

CVE-2024-5565 in Vanna.AI zeigte, wohin das führt: Remote Code Execution über KI-generiertes SQL und Python, ausgelöst allein durch Prompt Injection. Der Agent hatte keinen Bug. Er funktionierte genau wie vorgesehen, nur war er eben so konstruiert, dass er externen Eingaben vertraute.

Aktuelle Forschung zum Hackode-Framework berichtet von einer durchschnittlichen Angriffserfolgsrate von 84,29 % beim Herbeiführen verwundbarer Codegenerierung über mehrere untersuchte LLMs hinweg. Ihr System-Prompt mit „Lösche niemals Dateien“ ist keine Sicherheitskontrolle.

Supply-Chain-Angriffe: Slopsquatting und halluzinierte Abhängigkeiten

LLMs halluzinieren. Das ist nichts Neues. Neu ist, dass Angreifer herausgefunden haben, wie sie daraus eine Waffe machen.

„Slopsquatting“ nutzt aus, dass Sprachmodelle mit beunruhigender Regelmäßigkeit nicht existierende Paketnamen halluzinieren. Eine groß angelegte Studie mit 2,23 Millionen Paketreferenzen ergab, dass 19,7 % auf Pakete zeigten, die es nicht gibt: insgesamt 440.445 halluzinierte Referenzen mit 205.474 unterschiedlichen nicht existierenden Paketnamen. Wichtig dabei: 58 % davon tauchten über mehrere Prompts hinweg wiederholt auf, was sie zu berechenbaren Zielen für Angreifer macht, die sie auf npm und PyPI registrieren.

Klassisches Typosquatting bleibt genauso wirksam. Bis Ende 2025 hatten die Kampagnen Shai-Hulud und Shai-Hulud v2 Hunderte npm-Pakete kompromittiert, nach manchen Zählungen mehr als 800. Die Payloads suchten nach GitHub-Token und Cloud-API-Keys, und Lateral Movement über CI/GitHub Actions war ein üblicher Eskalationspfad.

Netzwerk-Exfiltration

Wenn ein KI-Agent Zugriff auf Umgebungsvariablen mit Secrets hat (und die meisten haben das), wird Exfiltration über das Netzwerk trivial. Smart Labs AI und die Universität Augsburg ließen 1.068 Angriffsvarianten pro Modell gegen populäre Agenten laufen und zeigten, dass man sie ohne Weiteres dazu bringt, interne Dateien zu lesen, den Inhalt zu kodieren (etwa in Base64) und ihn über scheinbar harmlose HTTP-Requests abfließen zu lassen.

Der Agent tut nichts offensichtlich Bösartiges. Er setzt einen HTTP-Request ab, genau wie beim Abrufen von Dokumentation oder beim Installieren von Paketen. Der Unterschied: Die Request-URL enthält Ihre AWS-Zugangsdaten.

DNS-Exfiltration ist noch schwerer zu erkennen. Weil DNS-Verkehr selbst restriktive Firewalls meist passieren darf, kann ein kompromittierter Agent sensible Daten in DNS-Abfragen kodieren und Zeichen für Zeichen hinausschleusen. Langsam? Ja. Wirksam? Verheerend.

Dateisystem-Angriffe

Naive Pfadprüfung hat sich immer wieder als unzureichend erwiesen. CVE-2025-53109 und CVE-2025-53110 im Filesystem-MCP-Server, der Referenzimplementierung @modelcontextprotocol/server-filesystem, die unter anderem von Anthropics Tools genutzt wird, zeigten, dass sich ein einfacher Abgleich des Pfadpräfixes per Symlink umgehen lässt. Präparierte Symlinks ließen Angreifer ganz aus den Sandbox-Verzeichnissen ausbrechen und ermöglichten das Lesen von /etc/sudoers, Schreibzugriffe auf macOS Launch Agents zur Persistenz und die vollständige Übernahme des Systems.

Die Lehre: Wenn Ihre Sandbox davon abhängt zu prüfen, ob ein Pfad mit /home/user/project beginnt, haben Sie schon verloren.

Vertrauen zwischen Agenten

Multi-Agent-Systeme werden immer häufiger: Orchestratoren, die mehrere spezialisierte Agenten koordinieren, um komplexe Aufgaben zu erledigen. Aber Forschung mit 17 LLMs ergab, dass 82,4 % bösartige Tool-Aufrufe oder Code ausführen, wenn „Peer-Agenten“ sie darum bitten, verglichen mit einer Erfolgsrate von 41,2 % bei direkter Prompt Injection und 52,9 % bei RAG-Backdoor-Angriffen.

Agenten vertrauen einander. Wenn Sie einen Agenten in einem Multi-Agent-System kompromittieren, haben Sie vermutlich alle kompromittiert.

Das Isolationsspektrum

Sandboxing-Techniken bilden eine Hierarchie, von bequem, aber schwach bis zu sicher, aber komplex. Dieses Spektrum zu verstehen ist wichtig, weil es keine Einheitslösung gibt: Die richtige Wahl hängt von Ihrem Bedrohungsmodell, Ihren Performance-Anforderungen und Ihren Betriebskapazitäten ab.

Stufe 1: Hardware-Virtualisierung (Firecracker, Kata Containers)

Der Goldstandard für die Ausführung nicht vertrauenswürdigen Codes ist die vollständige Isolation in einer virtuellen Maschine. Jede Ausführungsumgebung bootet ihren eigenen Linux-Kernel und ist durch die Hypervisor-Grenze vom Host getrennt. Systemaufrufe aus dem Gast erreichen den Host-Kernel nicht direkt, sie laufen über virtualisierte Hardware.

Firecracker, der in Rust geschriebene Virtual Machine Monitor, auf dem AWS Lambda läuft, ist der aktuelle Stand der Technik. Er bootet microVMs in unter 125 Millisekunden mit weniger als 5 MiB Speicher-Overhead pro Instanz. Das minimale Gerätemodell (nur virtio-net, virtio-block, virtio-vsock, serielle Konsole und ein Keyboard-Controller für den Reset) verkleinert die Angriffsfläche von den rund 1,4 Millionen Zeilen C bei QEMU auf etwa 50.000 Zeilen speichersicheres Rust.

AWS verarbeitet auf dieser Grundlage monatlich Billionen von Lambda-Aufrufen. Öffentlich bekannt gewordene VM-Ausbrüche aus User-Space-Code in Firecracker sind mit Stand Ende 2025 nicht dokumentiert. Das ist allerdings genau die Art von Aussage, die Sie im Lauf der Zeit selbst nachprüfen sollten.

Kata Containers kombiniert OCI-Kompatibilität mit VM-gestützter Isolation und unterstützt mehrere Hypervisoren, darunter QEMU, Cloud Hypervisor und Firecracker selbst. Die Bootzeiten liegen typischerweise bei wenigen hundert Millisekunden, der Speicher-Overhead ist grob eine Größenordnung höher als bei Standard-Containern. Für Multi-Tenancy im Unternehmen ist das akzeptabel, hängt aber von der Konfiguration ab.

Der Preis dafür ist Komplexität. Sie brauchen Linux mit KVM-Unterstützung (Bare Metal oder verschachtelte Virtualisierung in der Cloud), Kernel-Images, Rootfs-Verwaltung, Netzwerkkonfiguration und zusätzlichen Betriebsaufwand für Monitoring und Log-Aggregation über die VMs hinweg.

Am besten für: Multi-Tenant-Codeausführung in Produktion, Serverless-Plattformen, jedes Szenario mit völlig nicht vertrauenswürdigem Code aus externen Quellen.

Stufe 2: Abfangen von Kernel-Aufrufen im User Space (gVisor)

Statt auf Hardware-Virtualisierung setzt gVisor auf einen in Go geschriebenen User-Space-Kernel (genannt „Sentry“), der jeden Systemaufruf des Containers abfängt und eine Linux-Kernel-Schnittstelle emuliert. Der Container teilt sich weiterhin den Host-Kernel, kann aber keine Syscalls direkt absetzen: Sentry filtert und vermittelt sie. Das reduziert die Exposition des Host-Kernels von rund 350 Syscalls auf etwa 68. Google Cloud Functions, Cloud Run und GKE nutzen gVisor alle für die Multi-Tenant-Isolation.

Der Preis dafür ist Performance. In Googles eigenen Benchmarks und in nachfolgender Forschung sind einfache Syscalls oft 2- bis 9-mal langsamer als nativ, und Dateisystemoperationen, die über den Host laufen müssen, können in synthetischen I/O-Mikrobenchmarks Dutzende Male bis über 100-mal langsamer sein. Die Auswirkungen im Alltag hängen stark von der Arbeitslast ab. Der Start bleibt schnell (50 bis 100 ms), und der Speicher-Overhead hält sich in Grenzen.

Am besten für: Multi-Tenant-Umgebungen mit Kubernetes, Arbeitslasten, die den Syscall-Overhead vertragen, Teams, die schon stark im Container-Ökosystem stecken.

Stufe 3: Container-Härtung (Docker + seccomp + Namespaces)

Standard-Container mit Docker, containerd oder runc bieten Isolation auf Prozessebene über Linux-Kernel-Namespaces (pid, mount, network, ipc, user, uts), Ressourcenlimits über cgroups und Syscall-Filterung über seccomp-bpf. Das ist schnell: nahezu native Performance und Start in unter 100 ms. Es ist außerdem gut verstanden, mit umfangreichem Tooling und reichlich Dokumentation.

Die entscheidende Einschränkung: Container teilen sich den Host-Kernel. Sie sind keine Sicherheitsgrenzen in dem Sinn, wie Hypervisoren es sind. NIST und Sicherheitsforscher haben das klar gesagt. Container-Ausbrüche sind weiterhin eine aktive CVE-Kategorie.

Im Januar 2024 kam CVE-2024-21626 („Leaky Vessels“) in runc, bei dem ein auf /proc/self/fd/<fd> gesetztes WORKDIR Filedeskriptor-Lecks für den Container-Ausbruch ausnutzen konnte. Im November 2025 folgten drei weitere schwerwiegende runc-Schwachstellen (CVE-2025-31133, CVE-2025-52565, CVE-2025-52881), alle unter CVSS 4.0 als hoch eingestuft (um 7 oder höher).

Richtige Härtung hilft: seccomp-Profile, die Syscalls filtern, entzogene Capabilities (vor allem CAP_SYS_ADMIN), User-Namespace-Remapping, schreibgeschützte Root-Dateisysteme. Aber auch gehärtete Container nehmen ein Risiko auf Kernel-Ebene in Kauf.

Eine gehärtete Docker-Grundkonfiguration für die Ausführung von KI-Agenten:

docker run -d \
  --user 1001:1001 \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=64M \
  --cap-drop ALL \
  --security-opt no-new-privileges:true \
  --security-opt seccomp=/path/to/profile.json \
  --memory="512m" \
  --cpus="1.0" \
  --pids-limit 100 \
  --network none \
  agent-image:latest

Das ist ein Ausgangspunkt. Der CIS Docker Benchmark bietet umfassendere Anleitungen zur Härtung.

Am besten für: Entwicklungsumgebungen, CI/CD-Pipelines, Szenarien, in denen das Bedrohungsmodell „versehentlichen Schaden verhindern“ lautet und nicht „aktiven Gegnern standhalten“.

Stufe 4: Sandboxing auf OS-Ebene (Bubblewrap, Seatbelt)

Leichtgewichtige OS-Primitive können wirksame Isolation schaffen ohne den Overhead von Containern oder VMs. Ist Sandboxing aktiviert, nutzt Anthropics Claude Code Bubblewrap unter Linux und Seatbelt unter macOS, um Bash-Shells in einer Sandbox auszuführen, die Grenzen für Dateisystem und Netzwerk durchsetzen.

Dabei wird genau festgelegt, auf welche Verzeichnisse und Hosts der Agent zugreifen darf. Prozesse erben die Beschränkungen, verschachtelte Shells können also nicht ausbrechen. Der Start erfolgt praktisch sofort, und der Ressourcen-Overhead ist minimal.

Die Einschränkung ist der geteilte Kernel: Ein schwerer Kernel-Exploit könnte ausbrechen. Aber für halbwegs vertrauenswürdigen Code (Ihr eigener Agent arbeitet an Ihrer eigenen Codebasis) ist das ein wirksamer Schutz gegen Unfälle und wenig raffinierte Angriffe.

Am besten für: Lokale Entwicklung, Einzelnutzer-Szenarien, Teams, die feingranulare Policy-Kontrolle ohne die Komplexität von Containern wollen.

Stufe 5: Laufzeiten mit Berechtigungsschranken (Deno)

Deno und ähnliche Laufzeiten verlangen ausdrückliche Berechtigungen für Zugriffe auf Netzwerk, Dateisystem und Subprozesse. Standardmäßig steht keine dieser Fähigkeiten zur Verfügung. Im formalen Sinn ist das kein Sandboxing, denn ein Bug in der Deno-Laufzeit selbst könnte einen Ausbruch ermöglichen. Es macht Policies aber explizit und leichter prüfbar. Laufzeiten mit Berechtigungsschranken funktionieren gut als innere Schicht in Kombination mit OS- oder Container-Isolation.

Am besten für: Die Kontrolle, welche APIs Agenten aufrufen dürfen, nicht für die Isolation der Ausführung. Eine Ergänzung zu echtem Sandboxing.

Stufe 6: Kontrollen nur per Prompt

Dem LLM sagen: „Lösche keine Dateien“, und hoffen, dass es zuhört. Das versagt bei gezielten Angriffen in über 84 % der Fälle. Es ist kein Sandboxing. Es ist ein Schild, auf dem steht: „Bitte nicht einbrechen.“

Urteil: Für kein agentisches System in Produktion akzeptabel.

Wie die großen Tools Sicherheit tatsächlich umsetzen

Die Sandboxing-Ansätze der großen agentischen Coding-Tools unterscheiden sich erheblich: von ausgefeilter mehrschichtiger Isolation bis zu „das ist das Problem des Nutzers“.

Claude Code: Isolation mit doppelter Grenze

Anthropics Ansatz ist unter den Mainstream-Tools technisch der ausgefeilteste. Ist Sandboxing aktiviert, setzt Claude Code die Isolation mit Primitiven auf OS-Ebene um statt mit klassischer Containerisierung (im Detail beschrieben in Anthropics Engineering-Blogbeitrag zum Sandboxing).

Unter Linux nutzt es Bubblewrap für die Isolation von Dateisystem und Prozessen. Unter macOS übernimmt Apples Seatbelt (sandbox-exec) die Durchsetzung. Wesentlich ist: Der gesamte Netzwerkverkehr läuft über Proxy-Server, die außerhalb der Sandbox auf Unix Domain Sockets laufen, und der Linux-Netzwerk-Namespace wird vollständig entfernt. Prozesse in der Sandbox können nur über HTTP (durch den HTTP-Proxy) oder TCP (durch SOCKS5) kommunizieren.

Diese Architektur erreicht zwei Dinge: Sie verhindert direkte Exfiltration über das Netzwerk, selbst wenn die Sandbox teilweise kompromittiert ist, und sie erlaubt feingranulares Logging aller Netzwerkaktivität. Die Konfiguration unterstützt Allow- und Denylists für Domains, Pfadkontrollen im Dateisystem mit getrennten Lese- und Schreibrechten sowie Schutz für sensible Pfade wie ~/.ssh und ~/.aws.

Anthropic berichtet von 84 % weniger Berechtigungsabfragen mit diesem Ansatz: Nutzer können den Agenten autonomer arbeiten lassen, weil der Schadensradius jedes Fehlers begrenzt bleibt. Die Sandbox-Runtime steht als Open-Source-Research-Preview zur Verfügung.

Die webbasierte Version ergänzt das um Credential-Isolation: Git-Keys und Signaturschlüssel existieren nie in der Sandbox. Ein Proxy-Dienst übernimmt die Authentifizierung, prüft die Operationen und wendet auf dem Host die echten Zugangsdaten an. Wird die Sandbox kompromittiert, kommt der Angreifer trotzdem nicht an die Zugangsdaten.

GitHub Copilot Workspace: Prozess-Gates statt technischer Isolation

Die Agenten von GitHubs Copilot laufen in kurzlebigen Ausführungsumgebungen mit integrierten Firewall-Kontrollen. Die technische Isolation ist üblicher Container-Standard, das Sicherheitsmodell setzt aber auf Prozess-Kontrollen: Der Agent hat nur Lesezugriff auf das Repository und darf ausschließlich in von Copilot verwaltete Branches pushen. Kein Code, den der Agent schreibt, läuft, bevor ein Mensch einen Pull Request genehmigt hat.

Das ist eine grundlegend andere Philosophie: Statt den Ausbruch aus der Sandbox unmöglich machen zu wollen, macht sie ihn für die gefährlichsten Aktionen irrelevant. Der Agent kann kompromittiert werden, aber ohne menschliche Freigabe bringt er keinen Code in die Produktion. Der Netzwerkzugriff wird per Firewall mit konfigurierbaren Allowlists gesteuert.

Cursor

Cursor 2.x ergänzt unter macOS eine optionale Agenten-Sandbox, die dem Agenten einen eigenen Worktree gibt und im Sandbox-Modus den Netzwerkzugriff blockieren und den Git-Zustand isolieren kann. Die Umsetzung nutzt die Isolation über Git-Worktrees für parallel arbeitende Agenten. Standardmäßig lassen viele Nutzer Cursor aber weiterhin Befehle direkt in ihrer lokalen Umgebung ausführen. Die Sandbox muss man aktiv einschalten.

OpenHands (früher OpenDevin)

OpenHands führt allen von Agenten generierten Code in isolierten Docker-Containern aus, optional mit Daytona-Integration für stärkere Isolation durch Zero-Trust-Sandboxes und kurzlebige Umgebungen. Die Architektur trennt den Runtime-Container von der Hauptanwendung.

Das ist solide Isolation auf Container-Ebene, mit der Option, über eine Drittanbieter-Integration auf stärkere Grenzen aufzurüsten.

Aider und Continue.dev

Aider und Continue.dev bringen keine eingebaute Sandbox mit. Für die Isolation müssen Nutzer selbst sorgen, über Docker oder ähnliche Mechanismen. Neuere Dokumentation empfiehlt teils Docker-Setups, aber die Tools selbst erzwingen das nicht. Das ist nicht unbedingt falsch: Manche Nutzer haben Sicherheitsexpertise und wollen ihren Stack selbst kontrollieren. Es verlagert aber viel Sicherheitsverantwortung auf Endnutzer, denen womöglich nicht klar ist, dass sie handeln müssen.

Cloud-Ausführungsdienste

Falls der Aufbau einer eigenen Sandboxing-Infrastruktur nach keinem Vergnügen klingt (ist er auch nicht): Inzwischen gibt es eine eigene Kategorie von Diensten speziell für die Ausführung von KI-generiertem Code.

E2B: Die Firecracker-native Option

E2B vermarktet sich als erste Adresse für Firecracker-Sandboxes für KI-Agenten und behauptet, bei 88 % der Fortune 100 im Einsatz zu sein (eine Herstellerangabe, die man als solche festhalten sollte). Zu den Nutzern gehören Perplexity, Hugging Face und Groq.

Die Architektur ist einfach: Ihr Agent läuft lokal, und wenn er Code ausführen muss, ruft er die API von E2B auf. E2B startet in rund 150 Millisekunden eine isolierte Firecracker-microVM, führt den Code aus, gibt die Ausgabe zurück und räumt auf. Zugangsdaten gelangen nie in die Sandbox.

Der aktuelle öffentliche Preis liegt in der Größenordnung von 0,05 Dollar pro vCPU-Stunde für Sandboxes. In den bezahlten Tarifen sind Sitzungen von bis zu 24 Stunden möglich. SDKs gibt es für Python und JavaScript, dazu Integrationen für die großen KI-Frameworks.

Der Nachteil sind Vendor Lock-in und Netzwerklatenz: 150 bis 500 ms pro Ausführung summieren sich bei interaktiven Arbeitslasten.

Modal: gVisor mit GPU-Unterstützung

Modal nutzt gVisor-Container statt Firecracker, das wesentliche Unterscheidungsmerkmal ist die GPU-Unterstützung. H100-, A100-, L40S- und T4-GPUs stehen mit sekundengenauer Abrechnung zur Verfügung, was Modal zur Standardwahl für KI-Arbeitslasten macht, die Modelle innerhalb der Sandbox ausführen müssen.

Die Sandbox-Preise liegen laut Modals Dokumentation beim 3-Fachen der normalen Container-Tarife. Damit steht Modal zwischen E2Bs reinem Sandbox-Angebot und allgemeinem Serverless-GPU-Computing.

Daytona: Auf Geschwindigkeit optimierte Container

Daytona schwenkte Anfang 2025 auf Sandboxing für KI-Agenten um und bietet Docker-Container mit optional Kata Containers oder Sysbox für stärkere Isolation. Daytona gibt Cold Starts unter 90 ms an, was, falls es stimmt, die schnellste verfügbare Option wäre. Die Unterstützung des Language Server Protocol ermöglicht ausgefeilte Code-Intelligenz.

Die Einschränkung ist die relative Unreife: Funktionen wie erweitertes Networking und Snapshots befinden sich noch in Entwicklung.

Together Code Sandbox

Der Sandbox-Dienst von Together.ai kann laut eigenen Benchmarks vollständige VM-Instanzen in rund 500 ms aus Snapshots starten und zielt auf persistente Agenten im „IDE-Stil“, die große VMs mit Zustand brauchen. Bis zu 64 vCPUs sind verfügbar, dazu versionierter Speicher.

Die Preise sind VM-typisch (pro vCPU-Minute). Für kurze, flüchtige Aufgaben ist das weniger kosteneffizient, für lang laufende Entwicklungsumgebungen passt es.

Defense-in-Depth aufbauen

Wirksame Sicherheit für agentisches Coding braucht mehrere Verteidigungsschichten. Jede einzelne Kontrolle kann versagen. Das Ziel ist, dass die anderen Schichten den Schaden eindämmen, wenn eine versagt.

Schicht 0: Hardware-Isolation

Für völlig nicht vertrauenswürdigen Code bilden Firecracker-microVMs oder Kata Containers die Grundlage. Jede Ausführungsumgebung bekommt ihren eigenen Kernel, isoliert durch Extended Page Tables (EPT). Speicherzugriff über VM-Grenzen hinweg ist ohne Ausbruch aus dem Hypervisor unmöglich.

Schicht 1: Kontrollen auf OS-Ebene

Landlock LSM (Linux 5.13+) ermöglicht unprivilegierten Prozessen, sich selbst in eine Sandbox zu sperren, mit hierarchischen Dateisystem-Beschränkungen und Netzwerkkontrollen (TCP bind/connect seit Linux 6.7). Seccomp-BPF bietet Syscall-Filterung mit einem Overhead im einstelligen Nanosekundenbereich. Linux-Namespaces (mount, PID, network, user) sorgen für die Isolation von Ressourcen.

Schicht 2: Container-Härtung

Docker und ähnliche Container-Runtimes kommen mit freizügigen Standardeinstellungen, die auf Kompatibilität ausgelegt sind, nicht auf Sicherheit. Härtung verlangt explizite Konfiguration:

Capability Dropping entfernt Linux-Capabilities, also fein abgestufte Root-Rechte, die Container standardmäßig erben. Das Flag --cap-drop ALL entfernt alle über 40 Capabilities (etwa CAP_NET_RAW für Raw Sockets, CAP_SYS_ADMIN für Mount-Operationen). Fügen Sie mit --cap-add nur wieder hinzu, was wirklich nötig ist:

docker run --cap-drop ALL --cap-add NET_BIND_SERVICE myimage

Eigene seccomp-Profile schränken ein, welche Syscalls der Container absetzen darf. Dockers Standardprofil blockiert rund 44 gefährliche Syscalls, Sie können aber strengere Profile anlegen, die nur die Syscalls per Allowlist freigeben, die Ihre Anwendung tatsächlich braucht:

docker run --security-opt seccomp=/path/to/profile.json myimage

User-Namespace-Remapping bildet den Container-Root (UID 0) auf einen unprivilegierten Host-Nutzer ab. Selbst wenn ein Angreifer als „root“ ausbricht, landet er auf dem Host als nobody:

# In /etc/docker/daemon.json
{ "userns-remap": "default" }

Ein schreibgeschütztes Root-Dateisystem hindert Angreifer daran, Binärdateien zu verändern oder Persistenzmechanismen abzulegen:

docker run --read-only --tmpfs /tmp myimage

Ressourcenlimits über cgroups verhindern Denial of Service durch Ressourcenerschöpfung:

docker run --memory=512m --cpus=1 --pids-limit=100 myimage

Ein vollständig gehärteter Container-Aufruf könnte so aussehen:

docker run \
  --cap-drop ALL \
  --security-opt no-new-privileges:true \
  --security-opt seccomp=/path/to/strict-profile.json \
  --read-only \
  --tmpfs /tmp:size=64m \
  --memory=512m \
  --cpus=1 \
  --pids-limit=100 \
  --network=none \
  myimage

Schicht 3: Anwendungs-Sandbox

Tool-spezifische Beschränkungen bilden eine weitere Schicht. Konfigurieren Sie Allowlists für das Dateisystem (nur das Projektverzeichnis) und das Netzwerk (Paket-Registries und bestimmte APIs), und sperren Sie sensible Pfade (~/.ssh, ~/.aws, ~/.gnupg).

Schicht 4: Netzwerksegmentierung

Default-Deny für ausgehenden Verkehr mit freigegebenen Domains verhindert Exfiltration. Blockieren Sie interne Adressen (10.x, 192.168.x, 169.254.169.254), um den Zugriff auf Cloud-Metadaten zu unterbinden. Leiten Sie den gesamten Verkehr über protokollierende Proxys: Wenn der Agent einen verdächtigen Request absetzt, wollen Sie davon erfahren. DNS verdient besondere Aufmerksamkeit. Es ist der bevorzugte Exfiltrationskanal raffinierter Angreifer, weil es Firewalls fast immer passieren darf. Erwägen Sie DNS-Logging und Anomalieerkennung.

Schicht 5: CI/CD-Gates

Statische Analyse mit CodeQL oder Semgrep, Secret Scanning und Dependency Review sollten vor dem Merge über jeden KI-generierten Code laufen. Das fängt die unbeabsichtigten Sicherheitsprobleme ab, die Agenten regelmäßig einbauen.

Schicht 6: Menschliches Review

Jeder KI-generierte Code sollte vor dem Deployment in die Produktion geprüft werden. Nicht überflogen, geprüft. Audit-Logs der Agentenaktionen ermöglichen forensische Analysen und die Erkennung auffälligen Verhaltens. Für besonders heikle Operationen (Datenbankänderungen, das Anlegen von Zugangsdaten, Deployments in die Produktion) verlangen Sie eine ausdrückliche menschliche Freigabe direkt im Agenten-Workflow.

Entscheidungs-Framework

Für vertrauenswürdige interne Entwicklung

Wenn die KI an Ihrem eigenen Code mitarbeitet und Tempo zählt, bietet Landlock + seccomp minimalen Overhead. Der Sandbox-Modus von Claude Code oder die Agenten-Sandbox von Cursor bringen wirksamen Schutz ohne nennenswerte Performance-Einbußen. Sie nehmen damit ein gewisses Risiko für mehr Geschwindigkeit in Kauf. Das passt, wenn Sie den Eingaben Ihrer Codebasis vertrauen und der Agent keinen externen Inhalten ausgesetzt ist.

Für Paketinstallation und nicht vertrauenswürdige Abhängigkeiten

Wenn die KI Pakete aus öffentlichen Registries installieren darf, bietet Docker mit seccomp-Härtung einen guten Ausgleich aus Isolation und Performance. Ergänzen Sie eine Paketprüfung gegen bekannte, vertrauenswürdige Registries, und lassen Sie den Agenten kein pip install hallucinated-package-name ohne Überprüfung ausführen.

Für Multi-Tenant-SaaS

Wenn Kundencode in Ihrer Infrastruktur läuft, bieten gVisor oder Kata Containers die nötige Isolation. Der kompromittierte Agent eines Kunden kann die Daten eines anderen nicht beeinträchtigen. Google Cloud Run der 2. Generation oder GKE Sandbox (gVisor-basiert) bieten verwaltete Infrastruktur, falls Sie das nicht selbst betreiben wollen.

Für völlig nicht vertrauenswürdigen Code

Die Ausführung von KI-generiertem Code aus nicht vertrauenswürdigen Quellen in Produktion verlangt Firecracker-microVMs. E2B oder selbst betriebenes Firecracker mit Jailer liefern diese Grundlage. (AWS Lambda nutzt unter der Haube zwar Firecracker, ist aber kein konfigurierbarer Sandbox-Dienst, an den Sie Agenten direkt anbinden können.)

Irrtümer und Fallstricke

1. Container sind keine Sicherheitsgrenzen

Docker, OCI-Runtimes und Kubernetes Pod Security Policies sind Komfortschichten, keine Tresore, jedenfalls nicht in dem Sinn, wie Hypervisoren es sind. Ein falsch konfiguriertes seccomp-Profil, eine Kernel-Schwachstelle oder der Privileged Mode reichen, um sie zu brechen. Behandeln Sie Container als Prozessgruppen mit Leitplanken.

2. Firecracker ist nicht kugelsicher

Firecracker ist tatsächlich stärker isoliert als Container, aber Hypervisor-Bugs gibt es (selten, schnell gepatcht), verschachtelte Virtualisierung bringt zusätzliche Komplexität, und Angriffe auf physischer Ebene (Rowhammer, Seitenkanäle) bleiben theoretisch möglich. Für typische Bedrohungsmodelle (versehentlicher Schaden, Script Kiddies, opportunistische Angreifer) ist Firecracker ausgezeichnet. Gegen Gegner mit Zugriff auf Hardware-Ebene oder den Ressourcen eines Nationalstaats ist nichts kugelsicher.

3. Netzwerkisolation ist am schwierigsten

Eine Sandbox vom Netzwerk abzuschneiden ist leicht. Dafür zu sorgen, dass sie keine Daten exfiltrieren kann, ist schwer. Eine kompromittierte Sandbox kann Daten in DNS-Abfragen kodieren, per ICMP tunneln oder jedes Protokoll auf Anwendungsebene ausnutzen, das Sie erlaubt haben. Egress-Allowlists (standardmäßig blockieren) helfen. DNS-Inspektion hilft mehr. Anomalieerkennung für Verkehrsmuster ist fast schon eine Notwendigkeit.

4. Prompts sind keine Leitplanken

Wenn eine Fähigkeit gefährlich ist, entfernen Sie sie per Policy, nicht per Prompt. Die System Message ist keine Sicherheitsgrenze.

5. RAG ist eine neue Angriffsfläche

Vektordatenbanken, Prompt-Injection-Ketten und Memory Poisoning gehören zu den besorgniserregendsten neuen Angriffsvektoren für Agentensysteme. Eine kompromittierte Retrieval-Pipeline kann manipulierten Kontext in jede Entscheidung des Agenten einschleusen. Isolieren Sie RAG-Komponenten, bereinigen Sie abgerufene Inhalte und überwachen Sie auf Injection-Signaturen.

Ausblick 2026

Hardwaregestützte Isolation

AMD SEV-SNP, Intel TDX und ARM CCA werden ausgereifter und ermöglichen VMs, die selbst auf Hypervisor-Ebene verschlüsselt sind. Das schützt vor Innentätern bei Cloud-Anbietern: Die Ausführung Ihres Agenten ist sogar vor dem Betreiber der Infrastruktur geschützt. Rechnen Sie anfangs mit Preisaufschlägen, bis 2027 dürfte das zur Massenware werden. Wie bei allen Aussagen über die Zukunft gilt aber: Prüfen Sie das nach, wenn es so weit ist.

Formale Verifikation

Die akademische Arbeit am Nachweis von Sandbox-Eigenschaften kommt voran. Werkzeuge wie Isabelle/HOL werden auf seccomp-Policies und Hypervisor-Konfigurationen angewendet. „Zertifizierte Isolation“ ist weiterhin selten, wird aber häufiger.

Standardisierte Sandbox-APIs

E2B, Replit, Modal und andere nähern sich ähnlichen Schnittstellen an. Rechnen Sie mit standardisierten APIs für isolierte Codeausführung, was zu herstellerunabhängigen Implementierungen und zu Massenware-Preisen führen könnte.

Empfehlungen

1. Solo-Entwickler und Startups

Docker mit seccomp-Profilen plus Netzwerk-Proxy bietet für Entwicklungsarbeit ausreichenden Schutz. Oder Sie lagern das an E2B oder Replit aus und sparen sich die Infrastruktur ganz. Zeitaufwand: 1 bis 2 Tage für saubere seccomp-Regeln. Kosten: gratis (Open Source) oder rund 100 Dollar im Monat für einen verwalteten Dienst.

2. Unternehmen und Multi-Tenant-Systeme

Firecracker oder gVisor mit SIEM-Integration. Kafka oder SQS für die Arbeitsverteilung. Eigenes Personal für Betrieb und Red Teaming. Zeitaufwand: 4 bis 8 Wochen für den Aufbau der Control Plane. Kosten: 5K bis 20K Dollar im Monat für die Infrastruktur plus Personal.

3. KI/ML-Teams, die agentische Plattformen bauen

Beginnen Sie mit E2B oder Replit und überlassen Sie denen das Infrastrukturproblem. Ihr Alleinstellungsmerkmal liegt in Agentendesign, Monitoring und Governance, nicht in der Container-Orchestrierung. Zeitaufwand: 2 bis 3 Wochen für die Integration. Danach widmen Sie sich den schwierigen Problemen.

Checkliste

Sandboxing ist nicht optional. Wenn Sie von einem LLM generierten Code ausführen, brauchen Sie eine Grenze.
Entscheiden Sie nach Bedrohungsmodell, nicht nach Marketing. „KI-sicher“ heißt nicht sicher. Isolieren Sie nach dem, was tatsächlich schiefgehen kann.
Kombinieren Sie mehrere Schichten. Sandbox plus Monitoring plus Human-in-the-Loop-Gates plus signierte Artefakte plus Red Teaming.
Testen Sie Fehlerfälle, nicht Happy Paths. Kann der Agent Dateien löschen? Daten exfiltrieren? Den Host per DoS lahmlegen? Testen Sie es. Reproduzieren Sie Symlink-Ausbrüche, volllaufende Festplatten und Exfiltrationsversuche über das Netzwerk.
Fangen Sie einfach an. Docker plus seccomp ist eine solide Grundlage. Steigen Sie auf Firecracker um, wenn Sie es brauchen, nicht früher.
Dokumentieren Sie Ihre Entscheidungen. Schreiben Sie auf, warum Sie eine Sandbox gewählt haben und wovor Sie sich schützen. Das hilft bei Audits und beim Einarbeiten neuer Teammitglieder.
Prompts sind keine Leitplanken. Das kann man nicht oft genug sagen.

Zur Zukunft der Softwareentwicklung gehören KI-Agenten, die autonom Code schreiben und ausführen. Diese Zukunft kann sicher sein, aber nur, wenn wir ehrlich mit den Risiken umgehen und sie konsequent eindämmen. Der Technologie-Stack ist so weit gereift, dass er der Herausforderung gewachsen ist. Die Frage ist, ob wir ihn nutzen.

Aus dem Englischen übersetzt: zum Originalbeitrag