Vertraue keinen KI-Agenten

Wenn man mit KI-Agenten arbeitet, sollte man sie als nicht vertrauenswürdig und potenziell bösartig behandeln. Ob man sich um Prompt-Injection sorgt, um ein Modell, das versucht aus seiner Sandbox auszubrechen, oder um etwas, woran noch niemand gedacht hat — unabhängig vom Bedrohungsmodell sollte man dem Agenten nicht vertrauen. Der richtige Ansatz sind nicht bessere Berechtigungsprüfungen oder intelligentere Allowlists. Es ist eine Architektur, die davon ausgeht, dass Agenten sich falsch verhalten werden, und den Schaden eindämmt, wenn es passiert.

Das ist das Prinzip, auf dem ich NanoClaw aufgebaut habe.

Vertraue nicht dem Prozess

OpenClaw läuft standardmäßig direkt auf dem Host-System. Es gibt einen optionalen Docker-Sandbox-Modus, aber der ist ab Werk deaktiviert, und die meisten Nutzer aktivieren ihn nie. Ohne ihn basiert die Sicherheit vollständig auf Kontrollen auf Anwendungsebene: Allowlists, Bestätigungsdialoge, ein Satz “sicherer” Befehle. Diese Kontrollen gehen von einem impliziten Vertrauen aus, dass der Agent nicht versuchen wird, etwas Falsches zu tun. Sobald man die Denkweise annimmt, dass ein Agent potenziell bösartig ist, wird klar, dass Blockaden auf Anwendungsebene nicht ausreichen. Sie bieten keine hermetische Sicherheit. Ein entschlossener oder kompromittierter Agent kann Wege finden, sie zu umgehen.

In NanoClaw ist Container-Isolation ein zentraler Bestandteil der Architektur. Jeder Agent läuft in seinem eigenen Container, entweder auf Docker oder in einem Apple Container unter macOS. Container sind kurzlebig: Sie werden bei jedem Aufruf neu erstellt und danach zerstört. Der Agent läuft als unprivilegierter Benutzer und kann nur Verzeichnisse sehen, die explizit eingehängt wurden. Die Container-Grenze wird vom Betriebssystem durchgesetzt.

Vertraue keinen anderen Agenten

Selbst wenn die Sandbox von OpenClaw aktiviert ist, teilen sich alle Agenten denselben Container. Man könnte einen Agenten als persönlichen Assistenten und einen anderen für die Arbeit haben, in verschiedenen WhatsApp-Gruppen oder Telegram-Kanälen. Sie befinden sich alle in derselben Umgebung, was bedeutet, dass Informationen zwischen Agenten durchsickern können, die eigentlich auf unterschiedliche Daten zugreifen sollten.

Agenten sollten einander nicht mehr vertrauen, als man ihnen selbst vertraut. In NanoClaw erhält jeder Agent seinen eigenen Container, sein eigenes Dateisystem und seinen eigenen Claude-Sitzungsverlauf. Der persönliche Assistent kann die Daten des Arbeitsagenten nicht sehen, weil sie in vollständig getrennten Sandboxes laufen.

Die Container-Grenze ist die harte Sicherheitsschicht — der Agent kann sie unabhängig von der Konfiguration nicht durchbrechen. Darüber hinaus fungiert eine Mount-Allowlist unter ~/.config/nanoclaw/mount-allowlist.json als zusätzliche Schicht der Tiefenverteidigung: Sie existiert, um den Benutzer daran zu hindern, versehentlich etwas einzuhängen, das nicht exponiert werden sollte, nicht um den Agenten am Ausbruch zu hindern. Sensible Pfade (.ssh, .gnupg, .aws, .env, private_key, credentials) sind standardmäßig blockiert. Die Allowlist befindet sich außerhalb des Projektverzeichnisses, sodass ein kompromittierter Agent seine eigenen Berechtigungen nicht ändern kann. Der Code der Host-Anwendung wird schreibgeschützt eingehängt, sodass nichts, was ein Agent tut, nach der Zerstörung des Containers bestehen bleibt.

Auch den Personen in den Gruppen sollte man nicht vertrauen. Nicht-Hauptgruppen sind standardmäßig als nicht vertrauenswürdig eingestuft. Andere Gruppen und ihre Mitglieder können keine Nachrichten an andere Chats senden, keine Aufgaben für andere Gruppen planen und keine Daten anderer Gruppen einsehen. Jeder in einer Gruppe könnte eine Prompt-Injection senden, und das Sicherheitsmodell berücksichtigt das.

Vertraue nicht, was du nicht lesen kannst

OpenClaw hat fast eine halbe Million Zeilen Code, 53 Konfigurationsdateien und über 70 Abhängigkeiten. Das bricht die grundlegende Prämisse der Open-Source-Sicherheit. Chromium hat über 35 Millionen Zeilen, aber man vertraut den Review-Prozessen von Google. Die meisten Open-Source-Projekte funktionieren anders: Sie bleiben klein genug, damit viele Augen sie tatsächlich prüfen können. Niemand hat die 400.000 Zeilen von OpenClaw überprüft. Es wurde in Wochen geschrieben, ohne einen ordentlichen Review-Prozess. Komplexität ist der Ort, an dem sich Schwachstellen verstecken, und die Analyse von Microsoft hat das bestätigt: Die Risiken von OpenClaw konnten durch normale API-Aufrufe entstehen, weil keine einzelne Person das Gesamtbild überblicken konnte.

NanoClaw ist ein einziger Prozess und eine Handvoll Dateien. Wir verlassen uns stark auf das Claude Agent SDK von Anthropic, den Wrapper um Claude Code, für Sitzungsverwaltung, Speicherkomprimierung und vieles mehr, anstatt das Rad neu zu erfinden. Ein kompetenter Entwickler kann die gesamte Codebasis an einem Nachmittag durchsehen. Das ist eine bewusste Einschränkung, keine Limitation. Unsere Beitragsrichtlinien akzeptieren ausschließlich Fehlerbehebungen, Sicherheitskorrekturen und Vereinfachungen.

Neue Funktionalität kommt über Skills: Anleitungen mit einer vollständigen, funktionierenden Referenzimplementierung, die ein Programmieragent in die eigene Codebasis integriert. Man prüft genau, welcher Code hinzugefügt wird, bevor er eingespielt wird. Und man fügt nur die Integrationen hinzu, die man tatsächlich braucht. Jede Installation besteht am Ende aus wenigen tausend Zeilen Code, maßgeschneidert für die genauen Anforderungen des Besitzers.

Das ist der entscheidende Unterschied. Bei einer monolithischen Codebasis von 400.000 Zeilen ist der Rest des Codes immer noch da, selbst wenn man nur zwei Integrationen aktiviert. Er ist immer noch geladen, immer noch Teil der Angriffsfläche, immer noch erreichbar durch Prompt-Injections und unkontrollierte Agenten. Man kann nicht unterscheiden, was aktiv und was inaktiv ist. Man kann es nicht auditieren, weil man nicht einmal die Grenze dessen definieren kann, was “der eigene Code” ist. Bei Skills ist die Grenze offensichtlich: Es sind wenige tausend Zeilen, es ist alles Code, den man bewusst hinzugefügt hat, und man kann jede Zeile lesen. Der Kern wird tatsächlich mit der Zeit kleiner: Die WhatsApp-Unterstützung wird beispielsweise gerade herausgelöst und als Skill verpackt.

Entwirf für Misstrauen

Wenn eine Halluzination oder ein sich falsch verhaltender Agent ein Sicherheitsproblem verursachen kann, dann ist das Sicherheitsmodell kaputt. Sicherheit muss außerhalb der agentischen Oberfläche durchgesetzt werden und darf nicht davon abhängen, dass sich der Agent korrekt verhält. Container, Mount-Beschränkungen und Dateisystem-Isolation existieren, damit selbst wenn ein Agent etwas Unerwartetes tut, der Explosionsradius begrenzt bleibt.

Nichts davon eliminiert das Risiko. Ein KI-Agent mit Zugriff auf die eigenen Daten ist von Natur aus eine Hochrisiko-Angelegenheit. Aber die richtige Antwort ist, dieses Vertrauen so eng und überprüfbar wie möglich zu gestalten. Vertraue dem Agenten nicht. Baue Mauern um ihn herum.

Man kann den Quellcode und das vollständige Sicherheitsmodell von NanoClaw lesen; sie sind kurz genug, um sie an einem Nachmittag durchzulesen.