Warum dein KI-Agent eine Sandbox braucht

Die Sicherheitsarchitektur, die Stomme vertrauenswürdig für deine echte Arbeit macht

von Kai Stomme · März 2026

Du hast deinem KI-Agenten Zugang zu deiner E-Mail gegeben. Deinem Kalender. Deinem Dateisystem. Vielleicht zur Codebasis deines Unternehmens.

Stell dir jetzt die Frage: Was passiert, wenn der Agent einen Fehler macht?

Nicht dramatisch. Nicht Hollywood-mäßig. Nur... ein bisschen daneben. Er missversteht eine Anweisung. Ein Tool-Aufruf hat einen unbeabsichtigten Seiteneffekt. Eine Drittanbieter-API verhält sich seltsam. Und dein Agent hat die Berechtigung, darauf zu reagieren — weil du es so eingerichtet hast.

Die meisten KI-Agenten laufen direkt auf dem Host-Betriebssystem. Jede Datei, die sie anfassen können, können sie löschen. Jeden Ordner, den sie lesen können, können sie hochladen. Jede API, mit der sie verbunden sind, können sie aufrufen. Es gibt keine Wände. Nur den Agenten, dein Gerät und dein Vertrauen.

Wir haben entschieden, dass das nicht gut genug ist.

Was Isolation wirklich bedeutet

Wenn wir sagen, dein Agent läuft in einer isolierten Umgebung, meinen wir nicht, dass wir Warnhinweise in die Benutzeroberfläche eingefügt haben. Wir meinen, dass er in einem Container läuft — einer separaten Rechenumgebung mit eigenem Dateisystem, eigenem Netzwerk-Stack und hardwareerzwungener Trennung vom Host-Betriebssystem.

Der technische Begriff ist Kernel-Namespace-Isolation. Der Prozess deines Agenten kann dein Home-Verzeichnis buchstäblich nicht sehen. Kann nicht auf Pfade außerhalb seines zugewiesenen Bereichs zugreifen. Kann keine ausgehenden Netzwerkanfragen an etwas stellen, das wir nicht explizit erlaubt haben. Nicht weil wir höflich gebeten haben — sondern weil das Betriebssystem es auf Kernel-Ebene erzwingt.

So sieht das in der Praxis aus:

# Innerhalb der Sandbox des Agenten
ls /Users/
# → ls: cannot access '/Users/': No such file or directory

Das ist kein Berechtigungsfehler. Dieses Verzeichnis existiert vom Container aus schlicht nicht. Das Dateisystem selbst ist ein anderes.

Wie wir es gebaut haben: OpenShell

Die Laufzeitumgebung, die wir gewählt haben, ist OpenShell — eine speziell entwickelte sichere Runtime für autonome KI-Agenten, entwickelt von NVIDIA und im März 2026 veröffentlicht. Wir gehörten zu den ersten, die es unter Produktionsbedingungen getestet haben.

OpenShell führt deinen Agenten innerhalb eines Docker-Containers aus, der von einem leichtgewichtigen Kubernetes-Cluster verwaltet wird. Das klingt aufwendig, aber für dich ist es ein einziger Befehl. Es übernimmt:

Dateisystem-Isolation — der Arbeitsbereich des Agenten ist vollständig vom Host getrennt. Keine gegenseitige Kontamination. Dateien, die innerhalb der Sandbox erstellt werden, bleiben dort. Dateien außerhalb sind für den Agenten unsichtbar, sofern du sie nicht explizit übergibst.

Netzwerk-Egress-Policy — jede ausgehende Netzwerkanfrage des Agenten wird überprüft. Wir betreiben eine explizite Allowlist: Der Agent kann die Anthropic-API und Telegram erreichen. Sonst nichts. Wenn eine Anweisung den Agenten auffordert, eine nicht genehmigte URL aufzurufen, wird die Verbindung auf Netzwerkebene abgelehnt — bevor sie das Gerät verlässt.

Credential-Injektion — API-Schlüssel und Tokens werden niemals auf die Festplatte geschrieben. Sie werden beim Start als Umgebungsvariablen in den Container injiziert und existieren nur im Arbeitsspeicher, solange die Sandbox läuft. Wenn die Sandbox stoppt, sind sie weg.

Prozess-Isolation — seccomp-Profile sperren Systemaufrufe, die eine Privilegien-Eskalation ermöglichen könnten. Der Agent kann nicht Root werden. Er kann keine Kernel-Module installieren. Er kann seine eigene Sicherheitsrichtlinie nicht ändern.

Warum das für deine Arbeit wichtig ist

Bedenke, worauf ein fähiger KI-Agent tatsächlich Zugriff hat, wenn du ihn richtig einrichtest:

Deine E-Mail (lesen und schreiben)
Deinen Kalender (lesen und planen)
Dein Dateisystem (lesen, schreiben, ausführen)
Deine Code-Repositories (lesen, bearbeiten, pushen)
Deine verbundenen APIs (Abrechnung, CRM, Projektmanagement)

Das ist erheblicher Zugriff. Er muss erheblich sein — sonst kann der Agent seine Arbeit nicht erledigen. Aber erheblicher Zugriff kombiniert mit einer direkten Verbindung zum Host-Betriebssystem bedeutet, dass ein einziger fehlerhafter Tool-Aufruf echte Konsequenzen haben kann.

Mit Container-Isolation:

Ein unkontrollierter Schreibvorgang stoppt an der Sandbox-Grenze
Ein kompromittiertes Drittanbieter-Tool kann deine Dateien nicht lesen
Ein Agent, der sich über seinen Geltungsbereich irrt, kann nichts außerhalb der erlaubten Zone beeinflussen
Wenn etwas schiefläuft, betrifft der Schaden die Sandbox — nicht dein Gerät

Wogegen das nicht schützt

Ehrliche Sicherheitsdokumentation benennt auch die Grenzen.

Die Sandbox isoliert die Laufzeitumgebung — die Prozessausführungsumgebung. Sie schützt nicht vor:

Schlechten Anweisungen — wenn du deinen Agenten anweist, deine Dokumente zu löschen, wird er versuchen, sie innerhalb des Arbeitsbereichs zu löschen. Die Sandbox bewertet nicht die Qualität deiner Anweisungen.

Daten, die du hineingibst — wenn du deine E-Mail oder deinen Kalender verbindest, kommen diese Daten in die Sandbox. Die Sandbox verhindert, dass der Agent auf Dinge außerhalb seiner Zone zugreift; sie schränkt nicht ein, was er mit den Daten macht, auf die du ihm Zugriff gegeben hast.

Credential-Leckage über Ausgaben — wenn der Agent eine Datei schreibt, die einen API-Schlüssel enthält, befindet sich dieser Schlüssel jetzt im Sandbox-Dateisystem. Die Isolation verhindert Exfiltration, aber nicht, dass der Agent Fehler macht.

Deshalb haben wir eine zweite Schicht: Berechtigungsrichtlinien. Jede Fähigkeit deines Agenten ist explizit konfiguriert. Er hat keinen Zugriff auf Dienste, die du nicht verbunden hast. Und du kannst die Konfiguration jederzeit einsehen.

Die Frage der Anmeldedaten

Wenn du deinen Stomme-Agenten einrichtest, gibst du API-Schlüssel für die Dienste an, die du verbinden möchtest. Hier ist genau das, was damit passiert:

Du gibst sie während des Onboardings ein
Sie werden über HTTPS an unser Provisioning-System übertragen
Das Provisioning-System injiziert sie beim Start als Umgebungsvariablen in die Sandbox deines Agenten
Sie werden niemals auf die Festplatte deines Geräts geschrieben
Sie werden nicht länger als für die Injektion notwendig auf unseren Servern gespeichert
Wenn deine Sandbox nicht läuft, existieren sie nirgendwo dauerhaft

Das Onboarding erfasst sie. Die Sandbox-Laufzeit nutzt sie. Wenn du fertig bist, sind sie weg.

Das praktische Ergebnis

Wie fühlt sich das für dich an? Meistens nach nichts. Die Sicherheitsarchitektur ist unsichtbar, wenn alles richtig funktioniert — das ist der Punkt. Du gibst deinem Agenten eine Aufgabe. Er führt sie aus. Die Ergebnisse kommen zurück.

Was sich ändert, ist das, was du vertrauen kannst. Du kannst deinem Agenten wirklich leistungsfähigen Zugang geben — E-Mail, Dateien, Code — in dem Wissen, dass es harte Grenzen gibt, was er beeinflussen kann. Du kannst den Aktionsradius deines Agenten im Laufe der Zeit ausweiten, in dem Wissen, dass der Schaden im schlimmsten Fall begrenzt bleibt.

Der Agent, der dein morgendliches Meeting vorbereitet, deinen Posteingang triagiert und deinen Code deployed, läuft nicht unkontrolliert auf deinem Gerät. Er läuft in einer speziell entwickelten Runtime, die genau für diese Art von vertrauensintensiver, wichtiger Arbeit konzipiert wurde.

Das ist das Stomme: die tragende Struktur darunter. Du siehst sie nicht. Aber ohne sie hält nichts.

Technische Zusammenfassung

Schicht	Technologie	Was sie bietet
Container-Isolation	Docker + K3s	Dateisystem- und Prozesstrennung
Netzwerkrichtlinie	OpenShell Egress Engine	Allowlist für ausgehendes HTTPS
Credential-Verwaltung	Runtime-Injektion	Schlüssel nur im Arbeitsspeicher, niemals auf Festplatte
Syscall-Filterung	seccomp-Profile	Blockiert Privilegien-Eskalation
Laufzeitumgebung	OpenShell 0.0.12	Orchestriert das Gesamtsystem

Stomme läuft auf deinem Mac. Dein Agent ist durch Design isoliert — nicht durch Richtlinien.