Anfang Februar 2026 veröffentlichte GitGuardian einen Bericht, der jeden Entwickler mit einem persönlichen KI-Assistenten hätte alarmieren müssen. Ihre Secret-Scanning-Infrastruktur hatte über 200 geleakte Zugangsdaten entdeckt, die direkt mit OpenClaw-Deployments zusammenhingen — API-Keys, Datenbankpasswörter, OAuth-Tokens und Cloud-Provider-Credentials, verstreut über öffentliche Repositories, Log-Dateien und Fehlerberichte. Einige gehörten Unternehmen im Gesundheitswesen. Andere Fintech-Startups. Alle waren aktiv.
Wenige Tage später veröffentlichte die Northeastern University einen Artikel mit einer Überschrift, die tiefer traf als jede CVE-Nummer: „Warum der OpenClaw-KI-Assistent ein ‚Datenschutz-Albtraum' ist." Die Forscher konzentrierten sich nicht auf eine einzelne Schwachstelle. Sie konzentrierten sich auf die Architektur selbst — die Art und Weise, wie OpenClaw Daten verarbeitet, Zugangsdaten speichert und Nutzerinformationen by Design offenlegt, nicht durch Zufall.
Das waren keine Einzelfälle, verursacht durch unvorsichtige Nutzer. Es waren die vorhersehbaren Folgen davon, KI-Agents in Umgebungen laufen zu lassen, in denen Secrets, Nutzerdaten und Agent-Code sich denselben Adressraum teilen — ohne jegliche Isolation.
Wie Secrets an die falschen Stellen gelangen
Das typische OpenClaw-Setup funktioniert so: Man installiert es auf seinem Rechner, konfiguriert die API-Keys als Umgebungsvariablen und beginnt zu chatten. Der Agent-Prozess läuft unter dem eigenen Benutzer, mit den eigenen Berechtigungen, und liest die eigenen Umgebungsvariablen. Jeder installierte Skill läuft im selben Prozess, mit demselben Zugriff.
Das bedeutet: Wenn man seinen KI-Assistenten bittet, ein Deployment-Skript zu debuggen, kann der Agent die AWS-Zugangsdaten sehen. Wenn ein Skill E-Mails verarbeitet, kann er das Datenbankpasswort lesen. Wenn ein Fehler auftritt und ein Stack-Trace geloggt wird, können diese Umgebungsvariablen in der Log-Datei landen. Und wenn diese Log-Datei in ein Repository committed, in einen Bug-Report hochgeladen oder mit einem Cloud-Dienst synchronisiert wird — sind die Secrets öffentlich.
GitGuardians über 200 geleakte Secrets waren nicht das Ergebnis von 200 einzelnen Fehlern. Sie waren das Ergebnis eines einzigen Architekturfehlers, der 200-mal wiederholt wurde: Secrets in process.env zu legen, wo jedes Stück Code im Prozess sie lesen kann.
Das Problem verschärft sich mit Skills und Plugins. OpenClaws Skill-System führt Drittanbieter-Code im selben Prozess wie den Kern-Agent aus. Ein bösartiger Skill braucht keinen Exploit, um Zugangsdaten zu stehlen — er liest einfach process.env. Ein schlecht geschriebener Skill muss Daten nicht absichtlich leaken — er fügt einfach Umgebungskontext in einen Fehlerbericht ein. Die Angriffsfläche ist keine Schwachstelle, die gepatcht werden kann. Es ist die Architektur selbst.
Was Northeastern richtig erkannt hat
Die Northeastern-Forscher identifizierten etwas, um das die Security-Community herumgetanzt war: Das Datenschutzproblem bei KI-Assistenten dreht sich nicht um Verschlüsselung oder Authentifizierung. Es geht um die grundlegende Frage, worauf der Agent zugreifen kann und welche Grenzen zwischen der Welt des Agents und der eigenen existieren.
Wenn ein KI-Agent unter dem eigenen Benutzer läuft, mit den eigenen Berechtigungen, auf dem eigenen Rechner, gibt es keine Grenze. Der Agent kann Dateien, Zugangsdaten, den Browserverlauf und SSH-Keys lesen. Er kann auf alles zugreifen, worauf man selbst zugreifen kann. Das Einzige, was ihn davon abhält, etwas Schädliches zu tun, ist der Prompt — und Prompt-Injection-Angriffe haben wiederholt gezeigt, dass Prompts keine Sicherheitsgrenze sind.
Das meinte Northeastern mit „Datenschutz-Albtraum". Nicht dass OpenClaw absichtlich Daten stahl, sondern dass die Architektur es unmöglich machte zu garantieren, dass Daten nicht leaken würden. Der Zugriff des Agents war nur durch die Benutzerberechtigungen des Betriebssystems begrenzt, was so viel heißt wie: er war praktisch gar nicht begrenzt.
Wie NanoClaws Container-Isolation die Gleichung verändert
NanoClaw verfolgt einen grundlegend anderen Ansatz. Jeder Agent läuft in seinem eigenen Linux-Container — Apple Container auf macOS, Docker auf macOS und Linux. Der Container ist kein Komfort-Feature und keine Deployment-Option. Er ist das Sicherheitsmodell.
Wenn man eine Nachricht an NanoClaw sendet, führt der Host-Prozess Claude nicht direkt aus. Er startet einen Container, mountet nur die spezifischen Verzeichnisse, auf die der Agent Zugriff braucht, und übergibt den Konversationskontext. Der Agent läuft innerhalb des Containers mit eigenem Dateisystem, eigenem Prozessraum und eigenem Netzwerk-Stack. Wenn er fertig ist, wird der Container abgebaut.
Hier wird die Secret-Behandlung interessant. NanoClaw lädt den ANTHROPIC_API_KEY nie in process.env. Stattdessen liest es den Key zur Laufzeit aus der .env-Datei und übergibt ihn als JSON-Payload über stdin an den Container-Prozess. Innerhalb des Containers empfängt der Agent-Runner den Key, nutzt ihn für API-Aufrufe und schreibt ihn nie auf die Festplatte oder exportiert ihn in die Umgebung.
Das bedeutet: Selbst wenn ein bösartiger Prompt den Agent dazu bringt, `printenv` oder `cat /proc/self/environ` auszuführen, ist der API-Key nicht da. Er existiert nur im Prozessspeicher des Agent-Runners, für die Dauer dieses einzelnen Konversationsschritts. Ein kompromittierter Container kann nicht leaken, worauf er keinen Zugriff hat.
Das Mount-System fügt eine weitere Schicht hinzu. NanoClaw pflegt eine Allowlist von Verzeichnissen, die in Container gemountet werden dürfen, gespeichert außerhalb des Projektstammverzeichnisses. Jede Gruppe erhält ihr eigenes isoliertes Dateisystem — ihre eigene CLAUDE.md-Speicherdatei, ihren eigenen beschreibbaren Arbeitsbereich. Die Allowlist enthält eine Symlink-Escape-Erkennung, sodass ein manipulierter symbolischer Link das Mount-System nicht dazu bringen kann, Verzeichnisse außerhalb der erlaubten Menge freizugeben.
Container laufen außerdem als Nicht-Root-Benutzer, wobei der Projektquellcode schreibgeschützt gemountet ist. Ein Agent kann die Codebasis lesen, um Kontext zu verstehen, aber er kann die Dateien des Hosts nicht verändern. Beschreibbare Pfade sind pro Gruppe begrenzt und werden beim Beenden des Containers bereinigt.
Das Per-Group-Isolationsmodell
NanoClaws Isolation geht über die bloße Trennung von Agent und Host hinaus. Jede WhatsApp-Gruppe erhält ihren eigenen Container, ihren eigenen Speicher und ihr eigenes Dateisystem. Gruppe A kann Gruppe Bs Konversationen, Dateien oder CLAUDE.md-Speicher nicht sehen — nicht wegen Zugangskontrollen auf Anwendungsebene, sondern weil sie in physisch getrennten Containern mit separaten Mount-Punkten laufen.
Das ist relevant für ein Szenario, das die meisten KI-Assistenten komplett ignorieren: gemeinsam genutzte Geräte und Mehrbenutzer-Setups. Wenn man NanoClaw mit der Familie nutzt, sind die Konversationen und Dateien der Arbeitsgruppe auf Container-Ebene von denen der Familiengruppe isoliert. Es gibt keinen Anwendungsfehler, der Daten zwischen Gruppen leaken könnte, weil die Isolation von der Container-Runtime durchgesetzt wird, nicht von der Anwendung.
Der eigene WhatsApp-Hauptkanal — die Direktnachricht mit dem Assistenten — dient als Admin-Interface. Es ist der einzige Kanal, der geplante Aufgaben verwalten, die Konfiguration ändern und auf gruppenübergreifenden Status zugreifen kann. Gruppenkanäle sind standardmäßig auf ihre eigene Sandbox beschränkt.
Was die Branche daraus lernen sollte
Der GitGuardian-Bericht und die Northeastern-Analyse kommen zum selben Schluss: KI-Agents sind Infrastruktur, und Infrastruktur erfordert Sicherheit auf Infrastruktur-Niveau. Einen KI-Agent im selben Prozess wie die eigenen Zugangsdaten laufen zu lassen, mit denselben Berechtigungen wie das eigene Benutzerkonto, ist das Äquivalent dazu, einen Webserver als Root ohne Firewall zu betreiben. Es funktioniert, bis es nicht mehr funktioniert, und wenn es nicht mehr funktioniert, ist der Schadensradius alles.
Container-Isolation ist keine neue Idee. Die Webhosting-Branche hat das vor zwei Jahrzehnten begriffen — man lässt den Code mehrerer Kunden nicht im selben Prozess laufen. Die Datenbankbranche hat es noch früher begriffen — man gibt nicht jeder Abfrage Zugriff auf jede Tabelle. Aber das KI-Agent-Ökosystem befindet sich noch in seiner „alles als Root ausführen"-Phase, und die geleakten Secrets und Datenschutz-Albträume sind das vorhersehbare Ergebnis.
NanoClaws Ansatz ist nicht der einzige Weg, dieses Problem zu lösen, aber er zeigt, dass das Problem lösbar ist, ohne Funktionalität zu opfern. Agents in Containern können weiterhin das Web durchsuchen, Seiten browsen, Dateien lesen und schreiben und Shell-Befehle ausführen. Sie tun es nur innerhalb einer Sandbox, in der der Schadensradius jedes Fehlers — ob Bug, Prompt-Injection oder bösartiger Skill — auf den Scope dieses einzelnen Containers begrenzt ist.
Die 200 geleakten Secrets, die GitGuardian fand, hätten nicht passieren müssen. Sie passierten, weil die Architektur sie unvermeidlich machte. Die Lösung ist nicht bessere Nutzerschulung oder sorgfältigeres Credential-Management. Die Lösung ist eine Architektur, in der Secrets nicht leaken können, weil sie sich nie an einem Ort befinden, an dem ein Leak möglich ist.