Agent Sandboxing: Container vs. WASM vs. Kernel – drei Wege, Agenten einzusperren

In 30 Sekunden

KI-Agenten führen Code aus, rufen APIs auf und interagieren mit Dateisystemen. Ohne Isolation ist das ein Sicherheitsrisiko. Aktuell konkurrieren drei Ansätze: Container (NemoClaw), WASM Sandboxes (IronClaw) und Kernel-Level Isolation (nono). Jeder löst das Problem anders – mit unterschiedlichen Trade-offs bei Performance, Sicherheit und Komplexität.

Warum Agenten Sandboxing brauchen

Ein klassischer API-Call ist deterministisch: Input rein, Output raus. Ein Agent ist anders. Er entscheidet selbst, welche Tools er aufruft, in welcher Reihenfolge, und mit welchen Parametern. Das macht ihn mächtig – und gefährlich.

Ohne Sandboxing kann ein Agent:

• Dateisysteme lesen/schreiben, die er nicht kennen sollte
• Netzwerkzugriffe auf interne Services machen
• Credentials aus Umgebungsvariablen lesen
• Seiteneffekte auslösen, die nicht rückgängig zu machen sind

Die Frage ist nicht ob Isolation nötig ist, sondern welche Art von Isolation zum Use Case passt.

Die drei Ansätze im Überblick

	Container	WASM Sandbox	Kernel-Level
Projekt	NemoClaw	IronClaw	nono
Isolation	Prozess + Namespace	Linearer Speicher	Syscall-Filter
Startup	~100–500ms	~1–5ms	~10–50ms
Overhead	Mittel–Hoch	Minimal	Niedrig
Maturität	Produktionsreif	Early Stage	Experimentell
Skalierung	Tausende möglich, aber teuer	Zehntausende leichtgewichtig	Tausende mit geringem Overhead

Container: Der bewährte Weg (NemoClaw)

NemoClaw setzt auf Container – den gleichen Ansatz, den die Industrie seit einem Jahrzehnt für Microservices nutzt. Jeder Tool-Call eines Agenten läuft in einem eigenen Container mit definierten Ressourcen-Limits.

Stärken

• Bewährt: Docker, OCI-Standards, breites Ökosystem
• Vollständige Isolation: Eigenes Dateisystem, Netzwerk, Prozessraum
• Tooling: Monitoring, Logging, Orchestrierung sind gelöste Probleme
• GPU-Passthrough: Relevant für lokale Inferenz (Nemotron-Modelle)

Schwächen

• Startup-Latenz: 100–500ms pro Container – bei tausenden parallelen Tool-Calls summiert sich das
• Ressourcen-Overhead: Jeder Container braucht eigene Kernel-Namespaces, cgroups, Dateisystem-Layer
• Skalierungsprobleme: Tausende kurzlebige Container pro Sekunde sind ein Orchestrierungs-Albtraum
• Overkill für einfache Tools: Ein JSON-Parser braucht keinen eigenen Container

Wann Container sinnvoll sind

Container passen, wenn Tool-Calls komplex, langlebig und ressourcenintensiv sind. Beispiel: Ein Agent, der lokale Nemotron-Inferenz mit GPU-Zugriff braucht und dabei sensible Daten verarbeitet. Der Privacy Router von NemoClaw nutzt Container genau dafür.

WASM Sandboxes: Der leichtgewichtige Weg (IronClaw)

IronClaw verfolgt einen anderen Ansatz: Agent-Tools laufen als WebAssembly-Module in einer Sandbox. Keine Container, kein Kernel-Overhead – nur linearer Speicher mit definierten Grenzen.

Stärken

• Startup in Mikrosekunden: WASM-Module starten in 1–5ms – Größenordnungen schneller als Container
• Minimaler Overhead: Kein OS, kein Dateisystem, kein Netzwerk-Stack
• Determinismus: WASM-Ausführung ist deterministisch – reproduzierbare Tool-Calls
• Capability-basierte Security: Tools bekommen nur die Fähigkeiten, die explizit gewährt werden (WASI)

Schwächen

• Eingeschränktes Ökosystem: Nicht jede Library ist als WASM verfügbar
• Kein GPU-Zugriff: Lokale Inferenz in WASM ist (noch) nicht praktikabel
• Speicherlimits: WASM-Module arbeiten mit linearem Speicher – komplexe Datenstrukturen werden schnell teuer
• Netzwerkzugriff: Muss über Host-Funktionen proxied werden – zusätzliche Komplexität

Wann WASM sinnvoll ist

WASM-Sandboxes passen, wenn Tool-Calls leichtgewichtig, kurzlebig und hochfrequent sind. Beispiel: Ein Agent, der pro Sekunde hunderte kleine Transformationen ausführt – JSON parsen, Strings formatieren, Berechnungen durchführen. Hier wäre ein Container pro Call absurd.

Kernel-Level Isolation: Der radikale Weg (nono)

nono geht den härtesten Weg: Isolation auf Kernel-Ebene durch Syscall-Filtering (ähnlich seccomp-bpf), Namespace-Isolation und Capability-Dropping. Kein Container-Runtime, kein WASM-Runtime – direkte OS-Level-Kontrolle.

Stärken

• Maximale Isolation: Direkter Syscall-Filter – kein Umweg über Container- oder WASM-Runtime
• Niedriger Overhead: Näher am Bare-Metal als Container, weniger Abstraktion als WASM
• Feine Granularität: Kontrolle auf Syscall-Ebene – welche Systemaufrufe darf ein Tool machen?
• Kein Runtime-Lock-in: Funktioniert mit jeder Sprache, jedem Binary

Schwächen

• Hohe Komplexität: Syscall-Policies manuell zu pflegen ist fehleranfällig
• Linux-only: Kernel-Features wie seccomp, namespaces, cgroups sind Linux-spezifisch
• Schwer zu debuggen: Wenn ein Syscall geblockt wird, ist die Fehlersuche aufwändig
• Experimentell: nono ist kein produktionsreifes Projekt – es zeigt, was möglich ist

Wann Kernel-Level sinnvoll ist

Kernel-Level-Isolation passt für hochsensitive Umgebungen, in denen weder Container- noch WASM-Runtimes vertraut werden. Beispiel: Agenten in regulierten Branchen (Banken, Gesundheitswesen), die nachweisbar isoliert sein müssen.

Entscheidungsmatrix

Braucht der Tool-Call GPU-Zugriff?
  ├── Ja → Container (NemoClaw)
  └── Nein
       ├── Hochfrequent (>100 Calls/s)?
       │    └── Ja → WASM (IronClaw)
       └── Regulierte Umgebung?
            ├── Ja → Kernel-Level (nono)
            └── Nein → Container oder WASM nach Präferenz

Hybride Architektur: Der realistische Weg

In der Praxis wird sich kein einzelner Ansatz durchsetzen. Die wahrscheinlichste Architektur ist hybrid:

1. Container für komplexe, langlebige Tool-Calls mit GPU-Bedarf
2. WASM für leichtgewichtige, hochfrequente Transformationen
3. Kernel-Level als zusätzliche Härtungsschicht innerhalb von Containern

Das ergibt ein Schichtenmodell:

Agent Runtime
  └── Tool Router (entscheidet Sandbox-Typ)
       ├── Container Pool (NemoClaw-Stil)
       │    └── Kernel-Härtung (nono-Stil)
       └── WASM Pool (IronClaw-Stil)

Zusammenhang mit Privacy Routing

Die Sandbox-Frage hängt direkt mit dem Privacy Router zusammen. Wenn sensible Daten lokal verarbeitet werden müssen, braucht der lokale Pfad stärkere Isolation als der Cloud-Pfad – denn Cloud-Provider haben eigene Isolation.

Das bedeutet: Privacy Routing und Sandboxing sind keine unabhängigen Entscheidungen. Sie müssen zusammen gedacht werden:

Routing-Pfad	Empfohlene Isolation
Lokal + sensibel	Container + Kernel-Härtung
Lokal + unkritisch	WASM oder Container
Cloud	Provider-seitige Isolation

Offene Fragen

• Startup-Latenz vs. Sicherheit: Wie viel Latenz ist akzeptabel für bessere Isolation?
• WASM-GPU: Wird WebGPU in WASM-Sandboxes praktikabel für lokale Inferenz?
• Standardisierung: Wird es einen Standard für Agent-Sandboxing geben, oder fragmentiert der Markt?
• Attestierung: Wie weist man nach, dass die Isolation tatsächlich funktioniert hat?

Fazit

Es gibt keinen Gewinner im Agent-Sandboxing – nur Trade-offs. Container sind bewährt, aber schwer. WASM ist leicht, aber eingeschränkt. Kernel-Level ist maximal sicher, aber komplex. Die Zukunft liegt in hybriden Architekturen, die den richtigen Isolationsgrad pro Tool-Call wählen.

Drei Takeaways:

1. Container sind der sichere Default – aber nicht für alles die richtige Wahl
2. WASM wird für hochfrequente Calls unverzichtbar – die Startup-Latenz macht den Unterschied
3. Hybride Architekturen werden Standard – kein einzelner Ansatz löst alles

→ NemoClaw: Privacy Router erklärt → Die 5 Bausteine eines KI-Agenten → Agentic Engineering verstehen → Kontakt aufnehmen