NanoClaw in Docker-Sandboxes ausführen

 (nanoclaw.dev)
28 Punkte von GN⁺ 2026-03-14 | 1 Kommentare | Auf WhatsApp teilen
  • Durch die Zusammenarbeit von NanoClaw und Docker können einzelne AI-Agenten nun mit einem einzigen Befehl in isolierten Docker-Sandboxes ausgeführt werden
  • Jeder Agent läuft in einem eigenständigen Container innerhalb einer Micro-VM und verfügt über eine vollständig isolierte Umgebung ohne Zugriff auf das Host-System
  • Dank einer doppelten Sicherheitsgrenze wird selbst bei einem Container-Breakout auf VM-Ebene abgeblockt, sodass Host-Dateien, Zugangsdaten und Anwendungen geschützt bleiben
  • Das Sicherheitsmodell von NanoClaw folgt einem „Design ausgehend von Misstrauen“: Agenten werden als potenziell bösartig betrachtet, und die Architektur ist darauf ausgelegt, Schäden zu minimieren
  • Künftig sind Funktionserweiterungen für den Betrieb großer Agenten-Teams geplant, darunter kontrollierte Kontextfreigabe, persistente Agenten, fein granulare Berechtigungsrichtlinien und menschliche Freigabeprozesse

Überblick über die Docker-Sandbox-Integration

  • NanoClaw unterstützt durch die Zusammenarbeit mit Docker den Sandbox-Start per Einzeiler
    • Unterstützt auf macOS (Apple Silicon) und Windows (WSL); Linux soll bald folgen
    • Das Installationsskript übernimmt Klonen, Einrichtung und Sandbox-Konfiguration automatisch
  • Jeder Agent wird in einem eigenständigen Container innerhalb einer Micro-VM ausgeführt
    • Es sind weder separate Hardware noch komplexe Einstellungen erforderlich
    • Jeder Container besitzt seinen eigenen Kernel und Docker-Daemon, während der Zugriff auf den Host blockiert ist

Funktionsweise

  • Die Docker-Sandbox bietet Isolation auf Hypervisor-Ebene bei Startzeiten im Millisekundenbereich
  • NanoClaw lässt sich natürlich auf diese Struktur abbilden
    • Jeder Agent verfügt über ein eigenes Dateisystem, einen eigenen Kontext, eigene Tools und eigene Sitzungen
    • Beispiel: Ein Vertriebsagent kann nicht auf private Nachrichten zugreifen, und ein Support-Agent hat keinen Zugriff auf CRM-Daten
  • Die Micro-VM-Schicht bildet eine zweite Sicherheitsgrenze
    • Selbst bei einem Container-Breakout schützt die VM-Barriere weiterhin das Host-System

Sicherheitsmodell: Misstrauensbasierte Architektur

  • NanoClaw wurde unter der Annahme entwickelt, AI-Agenten nicht zu vertrauen
    • Berücksichtigt werden unvorhersehbare Risiken wie Prompt Injection oder Fehlverhalten des Modells
    • Die Architektur ist so ausgelegt, dass keine Geheimnisse oder Zugangsdaten in die Agentenumgebung eingebracht werden
  • Sicherheit wird außerhalb des Agenten erzwungen und hängt nicht von korrektes Verhalten ab
  • Im Unterschied zu OpenClaw bietet NanoClaw eine vollständige Isolation zwischen Agenten
    • Bei OpenClaw wird dieselbe Umgebung geteilt, wodurch private und geschäftliche Daten vermischt werden können
  • Hervorgehoben wird ein Security-Engineering-Prinzip, das Agenten zugleich als Kollaborationspartner und potenzielle Angreifer behandelt

Zukünftige Entwicklung

  • Es wird die Notwendigkeit eines neuen Infrastruktur- und Runtime-Layers für den Betrieb großer Agenten-Teams aufgezeigt
  • NanoClaw kann bereits mit mehreren Slack-Kanälen verbunden werden, um getrennte Agenten pro Aufgabenbereich zu betreiben
  • Als nächste Schritte werden vier Kernfunktionen genannt
    • Kontrollierte Kontextfreigabe: freier Informationsaustausch innerhalb eines Teams und selektive Freigabe zwischen Teams
    • Erstellung persistenter Agenten: keine einmaligen Unteragenten, sondern Teammitglieder mit dauerhafter ID, Umgebung und Datenbasis
    • Fein granulare Berechtigungsrichtlinien: etwa nur Lesezugriff auf E-Mails, eingeschränkter Zugriff auf bestimmte Repositories oder Ausgabenlimits
    • Menschliche Freigabeprozesse: nicht rückgängig zu machende Aktionen werden erst nach menschlicher Prüfung ausgeführt
  • NanoClaw wird als sicherheitszentrierter Runtime- und Orchestrierungs-Layer positioniert, Docker-Sandboxes als Infrastrukturbasis auf Enterprise-Niveau
  • Ziel ist der Aufbau eines Agent-Ausführungs-Stacks, der grundlegende Isolation, kontrollierte Zusammenarbeit sowie Sichtbarkeit und Governance auf Organisationsebene zugleich bietet

Überblick über NanoClaw

  • NanoClaw ist ein Open-Source-Sicherheits-Runtime- und Orchestrierungs-Layer für den Betrieb von AI-Agenten auf Teamebene
  • Das Projekt kann auf GitHub eingesehen und per Star unterstützt werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-03-14
Hacker-News-Kommentare

  • Es wirkt wie ein kleines Detail, aber wenn sich einige neue Designentscheidungen branchenweit verbreiten, könnte das zu einem tiefgreifenden Wandel führen
    Wie Karpathy sagte, ist der entscheidende Punkt, statt Integrationen wie Slack oder Discord direkt zu implementieren, einen Skill-Spec dafür bereitzustellen, „wie man Integrationen schreibt“
    Man könnte das „Claude native development“ nennen; statt klassischer „batteries-included“-Frameworks scheint sich das Ökosystem eher in Richtung „fork and customize“ zu bewegen
    Allerdings gibt es noch viele offene Fragen, etwa wie man Specs für Tests, Verifikation und Sicherheit verteilen soll
    Ich frage mich, ob so ein Wandel auch auf OS-Ebene passieren könnte. Wenn jede Instanz ein starkes Immunsystem hätte, könnte daraus ein heterogenes Ökosystem entstehen, das widerstandsfähiger gegen Angriffe ist

    • Da jeder Nutzer dieselbe Arbeit wiederholen müsste, scheint die Effizienz zu leiden. Ich denke, es ist besser, etwas einmal zu implementieren und dann von allen gemeinsam nutzen zu lassen
    • Die Stärke von Open Source liegt in Zusammenarbeit und Verifikation. So wie LLMs anfangs viele Bugs produzieren, gilt das auch für Menschen. Ich halte es für besser, auf einer verifizierten Basis aufzusetzen und darauf anzupassen
    • Vielleicht leben wir irgendwann in einer Welt, in der Funktionen umgesetzt werden, indem man statt Code Markdown-Spec-Dateien austauscht

  • Wenn man über Sicherheitstools oder Sandboxing spricht, muss man immer das Threat Model klar benennen
    Gefährlich ist, dass ein AI-Agent auf einem Host mit geheimen Daten beliebigen Code ausführen kann
    Zum Beispiel lassen sich das Löschen eines Postfachs, das Abfließen eines Kalenders oder eine falsche Überweisung nicht allein durch Sandboxing verhindern
    Deshalb braucht es zusätzlich zum Sandboxing auch eine feingranulare Rechtekontrolle pro Aufgabe und pro Tool. Zum Beispiel: „Diese Anfrage darf Gmail nur lesen, Schreiben und Löschen müssen verboten sein“

    • Stimme völlig zu. Zusätzlich braucht es Tracking von Datenflüssen zwischen Tools (IFC) und Capability Attenuation (ocap). Man muss etwa Richtlinien wie „Keine Datenübertragung außerhalb des ursprünglichen Mail-Threads“ ausdrücken können
    • Wie im Artikel „Don’t Trust AI Agents“ gesagt wird, müssen AI-Agenten unter der Annahme von Misstrauen entworfen werden. Man braucht eine Struktur, die Fehlfunktionen und Prompt Injection einkalkuliert und den Schaden minimiert
    • Ich habe das agentische Framework smith-core mit Fokus auf Policy-Kontrolle und das Gateway smith-gateway gebaut. Aber solche Diskussionen über Sicherheitsdesign bekommen in der Community kaum Aufmerksamkeit
    • Ich habe einen interessanten Artikel gesehen; wie in OpenClaw Sandbox erwähnt, sind Berechtigungen binär, während das Verhalten von LLMs probabilistisch ist — diese beiden Konzepte kollidieren im Kern
    • Tatsächlich gibt es mit IAM, WIF, Macaroons und Service Accounts bereits bestehende Berechtigungssysteme. Wenn man das Security-Team fragt, gibt es womöglich auch im eigenen Unternehmen schon nutzbare Lösungen

  • NanoClaw gefällt mir. OpenClaw war mir zu komplex, NanoClaw ist deutlich schlanker
    Es ist das erste Projekt, das Claude Code als Konfigurationsoberfläche nutzt, und es macht Spaß, Funktionen hinzuzufügen; außerdem funktioniert es gut

    • Meine OpenClaw-Instanz ist vor Kurzem kaputtgegangen. Ein Update hat die OpenRouter-Integration zerstört, und der Code ist übermäßig komplex
      Auch das Sicherheitsmodell passt nicht zu meiner rootless-Kubernetes-Umgebung, weshalb es ständig Probleme gab
      Deshalb bin ich zu Nullclaw gewechselt. Dass ich dabei Zig lernen und beim Debuggen mitkommen kann, macht es auch aus Lernperspektive interessant
    • Mich würde interessieren, welche Workflows sich mit Claude in Nanoclaw nicht ohne Weiteres bauen lassen

  • Die Docker-Sandbox ähnelt Apples container-Framework
    Auf macOS eignet sie sich als deutlich leichtere native Runtime als Docker
    Unter Linux möchte ich aber keinen Hypervisor verwenden. Mit Linux-Namespaces allein lässt sich schon ausreichend isolieren
    Ich frage mich, warum OpenClaw oder NanoClaw kein ordentlich aufgebautes offizielles Docker-Image bereitstellen

    • Ich nutze auf macOS Apple Container und auf anderen Betriebssystemen Podman
      Container hat zwar ein paar Netzwerk-Bugs, aber es lohnt sich. Man muss nur die DNS-Einstellungen anpassen
      Ich bin zufrieden, weil ich Claude Code oder Node.js nicht auf dem Host installieren muss

  • Wichtiger als die Frage, ob es ein Container ist, ist was man eigentlich tun will
    Solange man nicht herausfindet, wie man Tokens für nützliche Aufgaben einsetzt, ist die Runtime zweitrangig
    Aus Sicherheitssicht reicht es nicht, ein LLM einfach in einen Container zu stecken. Entscheidend ist der Umfang der zugänglichen Informationen
    Wenn ein Agent auf alle Daten zugreifen kann, ist genau das das eigentliche Risiko

    • Die Docker-Sandbox verwendet MicroVMs als zusätzliche Isolationsschicht. Es ist nicht bloß ein einfacher Container

  • Der Kern sind feingranulare Rechte und Policy-Kontrolle
    Es geht nicht nur darum, welche Tools verwendet werden dürfen, sondern auch darum, was damit getan werden darf
    Zum Beispiel: nur E-Mails lesen, nur auf bestimmte Repositories zugreifen, Ausgabenlimits setzen usw.
    Nur mit Docker-Sandboxing wäre es mir zu riskant, sensible Assets wie Messaging-Accounts einem LLM anzuvertrauen

  • Die Docker-Sandbox startet für jeden Agenten eine eigene MicroVM und einen eigenen Docker-Daemon und kombiniert das mit einem flexiblen Egress-Proxy
    Ich habe es per Reverse Engineering untersucht, und die Implementierung ist ziemlich interessant

  • NanoClaw ist kein sofort einsatzbereites Fertigprodukt
    Man muss Funktionen wie iMessage über einen Coding-Agenten selbst hinzufügen
    Das heißt im Grunde, Claude übernimmt die Rolle des Compilers

    • Früher gab es Zeiten, in denen man den vom Compiler erzeugten Assembler noch direkt überprüft hat
      Coding-Agenten sind immer noch auf diesem Niveau. Die jüngsten Aussagen, „Coding-Agenten sind viel besser geworden“, sind übertrieben
      Man muss Claude immer noch wiederholt sagen: „Das ist noch nicht gelöst, mach es nochmal“

  • Ich arbeite an einer Idee, die den „claws“ ähnelt
    Statt Messaging-App-Integrationen bietet sie eine Ende-zu-Ende-verschlüsselte TUI
    Siehe wingthing.ai / GitHub-Repository
    Ich überlege noch, wie ich Docker-Unterstützung umsetzen soll, und werde mir dieses Projekt deshalb auch ansehen

  • Mich interessiert der konkrete Use Case von Nano/Open-Claw. Soll es mein digitales Leben stellvertretend organisieren?

    • Eigentlich ist es simpel. Entweder ein LLM-Cronjob oder ein Chat-Connector wie Telegram oder E-Mail. Ersteres geht auch mit normalem Cron, Letzteres auch mit manuellem Code oder Gemini Gems
    • Nützlich ist es, um wiederkehrende Wissensarbeit wie E-Mail-Zusammenfassungen, Termin-Erinnerungen oder Briefing-Dokumente zu automatisieren
    • Man kann es mit einer To-do-App verbinden und Dinge vom Bot per Nachricht verwalten lassen. Das hilft bei der Produktivitätssteigerung
    • Ich nutze NanoClaw als Coach für Ernährung und Training. Es kümmert sich um Zielverfolgung, Ernährungsplanung, Einkaufslisten und Trainingsprotokolle
      Ich habe es auf Apple Container umgestellt und außerdem ein langfristiges Gedächtnis auf Basis von LanceDB hinzugefügt. Jetzt muss ich nicht mehr ständig dieselben Dinge wiederholen