Reicht ein Container aus oder benötige ich eine MicroVM?

Das hängt davon ab, was darin ausgeführt wird. Für eigenen Code mit einem Injection-Risiko ist ein gehärteter Container ohne Anmeldedaten und mit eingeschränktem Egress meist verhältnismäßig. Für beliebigen Code aus nicht vertrauenswürdigen Quellen sollten Sie davon ausgehen, dass aus dem gemeinsam genutzten Kernel ausgebrochen werden kann, und eine MicroVM verwenden.

Wie unterscheidet sich dies von Least-Privilege-Tooling?

Least Privilege (das Prinzip der minimalen Rechte) begrenzt, was der Agent anfordern darf; die Sandbox begrenzt, was passiert, wenn dennoch etwas ausgeführt wird. Das eine regelt die Anfrage, das andere die Umgebung, in der sie ausgeführt wird – und Agenten, die Code ausführen, benötigen beides.

Die Sandbox verlangsamt alles. Lohnt sich das?

Vergleichen Sie dies mit den Alternativkosten, nicht mit null. Der Großteil der Latenz entsteht beim Starten der Umgebung, was durch Pools und vorgewärmte Images weitgehend vermieden werden kann. Der Fehler, den sie verhindert, ist eine Kompromittierung des Hosts, auf dem der Agent läuft.

Sicherheit & AufsichtAktualisiert 2026-08-22 · Version 1.0

Sandbox-Ausführung

Führen Sie alles, was ein Agent generiert oder aufruft, in einer verworfenen, isolierten Umgebung ohne implizite Anmeldedaten (Ambient Credentials), mit einem begrenzten Dateisystem, kontrolliertem Egress und harten Ressourcenlimits aus. Die Sandbox existiert nicht, weil der Agent bösartig ist, sondern weil es die Eingaben des Agenten sein können.

Evidenz: BranchenbeobachtungKonfidenz: HochQuelle: BranchenbeobachtungQuelle: Persönliche ErfahrungQuelle: Paper

Maschinenlesbar: JSON

Definition

Sandbox-Ausführung bezeichnet die Praxis, von Agenten generierten Code und von Agenten aufgerufene Aktionen in einer isolierten, flüchtigen (ephemeren) Umgebung auszuführen, deren Dateisystem, Netzwerk, Anmeldedaten und Ressourcen durch den Host statt durch den Agenten begrenzt sind, sodass ein gekaperter oder fehlerhafter Agent nichts außerhalb dieser Umgebung beeinflussen kann.

Problem

Ein Agent, der Code auf dem Host ausführt, erbt dessen Umgebung: seine Anmeldedaten, sein Dateisystem und seine Netzwerkposition. Eine einzige erfolgreiche Injection oder ein einziger selbstbewusst falscher Befehl ist dann nicht mehr von einer Kompromittierung des Systems zu unterscheiden.

Wann zu verwenden

Nutzen Sie dies immer dann, wenn ein Agent Code ausführt, Shell-Befehle ausführt, Pakete installiert oder nicht vertrauenswürdige Dateien verarbeitet. Die Hürde ist niedrig: Wenn der Agent eine Ausführung bewirken kann, gehört diese Ausführung in eine Sandbox.

Lösung

Machen Sie es flüchtig (ephemer). Erstellen Sie die Umgebung pro Task, zerstören Sie sie danach und übertragen Sie niemals einen Zustand, der vom nächsten Task nicht angefordert wurde. Persistenz ist der Weg, wie aus einer einmaligen Kompromittierung ein dauerhafter Zugang wird.

Entfernen Sie implizite Anmeldedaten (Ambient Credentials). Nichts in der Umgebung sollte nutzbar sein, nur weil es vorhanden ist; injizieren Sie nur die eng begrenzten Secrets, die der Task für seine Dauer benötigt.

Begrenzen Sie das Dateisystem auf das Working Set. Mounten Sie das Repository oder den Input und nichts anderes, und mounten Sie alles schreibgeschützt (read-only), was nicht beschrieben werden muss.

Beschränken Sie den Egress innerhalb der Sandbox, nicht um sie herum. Die Isolation und die Netzwerkrichtlinie sind aus Sicht des Angreifers dieselbe Kontrollmaßnahme, und eine Sandbox mit offenem Netzwerk ist wie ein Gefängnis mit Telefon.

Begrenzen Sie die Ressourcen – CPU, Arbeitsspeicher, Festplatte, Laufzeit (Wall-Clock), Prozessanzahl. Unkontrollierter Ressourcenverbrauch ist das Fehlerszenario, das zuerst und am häufigsten auftritt, meist ganz ohne Angreifer.

Protokollieren Sie, was die Grenze überschritten hat: Welche Dateien kamen hinein, welche gingen heraus, welche Ziele wurden erreicht. Die Grenze ist nur dann nützlich, wenn Sie sehen können, was sie passiert hat.

Komponenten

Ein Isolations-Primitiv: Container, MicroVM oder Ähnliches, ausgewählt nach der für den Workload erforderlichen Stärke.Ephemeres Lifecycle-Management, bei dem die Zerstörung der Standardzustand und nicht nur ein Bereinigungsschritt ist.Ein Pfad zur Secret-Injektion, der auf den Task und dessen Dauer begrenzt ist.Eine Netzwerkrichtlinie, die innerhalb der Sandbox-Grenze angewendet wird.Ressourcen-Quotas und Timeouts, die vom Host erzwungen werden.Grenzprotokollierung (Boundary Logging): Eingaben, Ausgaben und Ziele.

Vorteile

Verwandelt das Szenario „Der Agent hat etwas Schädliches ausgeführt“ von einem Sicherheitsvorfall in einen verworfenen Container.
Ermöglicht es, einem Agenten echte Ausführungsfähigkeiten zu geben, was ihn oft überhaupt erst nützlich macht.
Begrenzt sowohl ehrliche Fehler als auch Angriffe – dieselbe Kontrollmaßnahme fängt eine Endlosschleife ebenso ab wie ein injiziertes Payload.
Bietet einen sauberen Ort für die Beobachtung: Alles, was der Task berührt hat, hat genau eine Grenze überschritten.

Risiken

Schwächere Isolation als angenommen: Ein gemeinsam genutzter Kernel ist keine Sicherheitsgrenze gegen einen entschlossenen Ausbruch (Escape), und einen Container wie eine MicroVM zu behandeln, ist ein Kategorienfehler.
Aus Bequemlichkeit eingeschmuggelte Anmeldedaten – eine einzige gemountete Konfigurationsdatei macht das gesamte Pattern zunichte.
Sandboxes, die unbemerkt persistent werden, weil der Neuaufbau zu langsam ist, wodurch die Flüchtigkeit (Ephemerality), die die Garantie bot, verloren geht.
Ausbruch über die verbleibende gemeinsame Schnittstelle: gemountete Volumes, die Orchestrator-API oder das Netzwerk, das die Sandbox noch erreicht.

Wann nicht zu verwenden

Read-only-Agenten ohne Ausführungsfähigkeit, bei denen es nichts zu isolieren gibt und die Kosten keinen Nutzen bringen.
Latenzkritische Inline-Pfade, bei denen der Start der Umgebung den Task dominiert und eine engere Kontrolle – wie ein eingeschränkter Interpreter oder eine reine Funktion – besser geeignet ist.
Wenn die Sandbox genau die Anmeldedaten benötigen würde, die sie eigentlich vorenthalten soll – was ein Zeichen dafür ist, dass der Task eher aufgeteilt als isoliert werden sollte.

Technologien

ContainersmicroVMs (Firecracker / gVisor)Ephemeral workspacesResource quotas and timeoutsScoped secret injection

Beispiele

Ein Coding-Agent, der für jeden Task in einen frischen Container klont, wobei das Repository gemountet ist, keine Cloud-Anmeldedaten vorhanden sind und der Egress auf die Paketregistrierung beschränkt ist. Die Installation einer bösartigen Abhängigkeit zerstört lediglich den Container und sonst nichts.
Ein Datenanalyse-Agent, der generierten Python-Code in einer MicroVM ausführt, wobei der Eingabedatensatz schreibgeschützt gemountet ist, keinerlei Netzwerkverbindung besteht und ein Laufzeitlimit (Wall-Clock Cap) gilt. Der generierte Code kann fehlerhaft sein; er kann jedoch weder teuer sein noch Daten exfiltrieren.
Ein Dokumentenverarbeitungs-Agent, der nicht vertrauenswürdige PDFs in einer Einwegumgebung öffnet, da ein Parser-Exploit in einer hochgeladenen Datei ein realer Pfad zum Host ist und die Datei von außen stammt.

KPIs

Anteil der in einer Sandbox ausgeführten Prozesse: Die Abdeckungsrate. Alles, was außerhalb der Sandbox läuft, bestimmt das tatsächliche Sicherheitsniveau, unabhängig davon, was der in der Sandbox ausgeführte Anteil tut.
Lebensdauer der Sandbox: Wie lange Umgebungen existieren. Steigende Lebensdauern bedeuten, dass die Flüchtigkeit (Ephemerality) schleichend in Persistenz übergeht.
Erreichen von Ressourcenlimits: Tasks, die durch ein Kontingent oder ein Timeout gestoppt wurden. Eine nützliche Mischung aus unkontrollierten Generierungen und tatsächlich zu eng gesetzten Limits.
Zur Laufzeit vorhandene Secrets: Anzahl der innerhalb der Umgebung erreichbaren Anmeldedaten. Das Ziel ist das für den Task erforderliche Minimum, oft null.

Beobachtete Fehlermuster

Das Bequemlichkeits-Mounting: Ein Home-Verzeichnis, eine Anmeldedatendatei oder ein Socket, die gemountet werden, damit ein Task nicht mehr fehlschlägt.
Persistente Wiederverwendung: Die Umgebung wird nicht mehr pro Task erstellt, weil der Neuaufbau zu viel kostet, sodass sowohl der Zustand als auch eine Kompromittierung überdauern.
Offener Egress innerhalb der Grenze: Eine starke Isolation bei freiem Netzwerkzugriff schützt lediglich das Dateisystem.
Erreichbarkeit des Orchestrators: Die Sandbox kann die API aufrufen, die die Sandboxes verwaltet – was ein systembedingter Ausbruch (Escape by Design) statt eines Exploits ist.

Lessons Learned

Isolieren Sie die Ausführung, bevor Sie der Generierung vertrauen. Erst die Sandbox macht es überhaupt vertretbar, einen Agenten Code ausführen zu lassen.
Flüchtigkeit (Ephemerality) ist die eigentliche Sicherheitseigenschaft; Isolation allein verschiebt das Problem nur nach hinten.
Anmeldedaten, die nicht vorhanden sind, können nicht gestohlen werden – und das ist die einzige Kontrollmaßnahme, die nach einem Ausbruch noch greift.
Die meisten Sandbox-Aktivierungen sind ehrliche Fehler, keine Angriffe. Das zeigt, dass das Pattern funktioniert, und ist kein Beweis dafür, dass es unnötig war.

FAQs

Reicht ein Container aus oder benötige ich eine MicroVM?: Das hängt davon ab, was darin ausgeführt wird. Für eigenen Code mit einem Injection-Risiko ist ein gehärteter Container ohne Anmeldedaten und mit eingeschränktem Egress meist verhältnismäßig. Für beliebigen Code aus nicht vertrauenswürdigen Quellen sollten Sie davon ausgehen, dass aus dem gemeinsam genutzten Kernel ausgebrochen werden kann, und eine MicroVM verwenden.
Wie unterscheidet sich dies von Least-Privilege-Tooling?: Least Privilege (das Prinzip der minimalen Rechte) begrenzt, was der Agent anfordern darf; die Sandbox begrenzt, was passiert, wenn dennoch etwas ausgeführt wird. Das eine regelt die Anfrage, das andere die Umgebung, in der sie ausgeführt wird – und Agenten, die Code ausführen, benötigen beides.
Die Sandbox verlangsamt alles. Lohnt sich das?: Vergleichen Sie dies mit den Alternativkosten, nicht mit null. Der Großteil der Latenz entsteht beim Starten der Umgebung, was durch Pools und vorgewärmte Images weitgehend vermieden werden kann. Der Fehler, den sie verhindert, ist eine Kompromittierung des Hosts, auf dem der Agent läuft.