Exécuter NanoClaw dans des sandboxes Docker

• Grâce à la collaboration entre NanoClaw et Docker, il est désormais possible d’exécuter chaque agent IA dans une sandbox Docker isolée avec une commande sur une seule ligne
• Chaque agent s’exécute dans un conteneur indépendant à l’intérieur d’une micro-VM, avec un environnement totalement isolé sans accès au système hôte
• Grâce à une architecture à double frontière de sécurité, même en cas d’évasion du conteneur, le blocage se fait au niveau de la VM, protégeant les fichiers, identifiants et applications de l’hôte
• Le modèle de sécurité de NanoClaw repose sur une « conception fondée sur la défiance », qui considère les agents comme des acteurs potentiellement malveillants et adopte une architecture visant à minimiser les dommages
• À l’avenir, l’objectif est d’étendre les fonctionnalités pour l’exploitation d’équipes d’agents à grande échelle, avec notamment le contrôle du partage de contexte, des agents persistants, des politiques d’autorisation granulaires et des procédures d’approbation humaine

---

Vue d’ensemble de l’intégration des sandboxes Docker

• NanoClaw prend en charge l’exécution en sandbox via une commande sur une seule ligne grâce à sa collaboration avec Docker
  • Pris en charge sur macOS (Apple Silicon) et Windows (WSL), avec Linux prévu prochainement
  • Le script d’installation automatise le clonage, la configuration et la mise en place de la sandbox
• Chaque agent s’exécute dans un conteneur indépendant à l’intérieur d’une micro-VM
  • Aucun matériel distinct ni configuration complexe ne sont nécessaires
  • Chaque conteneur dispose de son propre kernel et de son propre démon Docker, avec un accès hôte bloqué

Fonctionnement

• La sandbox Docker fournit une isolation au niveau de l’hyperviseur avec un démarrage rapide de l’ordre de la milliseconde
• NanoClaw s’intègre naturellement à cette architecture
  • Chaque agent dispose d’un système de fichiers, contexte, outils et session indépendants
  • Exemple : un agent commercial ne peut pas accéder aux messages privés, et un agent de support n’a pas accès aux données CRM
• La couche de micro-VM forme une deuxième frontière de sécurité
  • Même en cas d’évasion du conteneur, le mur de la VM protège le système hôte

Modèle de sécurité : conception fondée sur la défiance

• NanoClaw est conçu selon le principe d’une architecture qui ne fait pas confiance aux agents IA
  • Il prend en compte des risques imprévisibles comme l’injection de prompt ou les dysfonctionnements du modèle
  • L’architecture est conçue pour éviter d’introduire des informations secrètes ou des identifiants dans l’environnement des agents
• La sécurité est imposée depuis l’extérieur des agents et ne dépend pas de leur bon comportement
• Contrairement à OpenClaw, NanoClaw fournit une isolation complète entre les agents
  • OpenClaw partage le même environnement, ce qui peut mélanger données personnelles et professionnelles
• Il met en avant un principe d’ingénierie de sécurité qui considère les agents à la fois comme des collaborateurs et comme des attaquants potentiels

Évolutions à venir

• Le besoin de construire une nouvelle infrastructure et une nouvelle couche d’exécution pour exploiter de grandes équipes d’agents est mis en avant
• NanoClaw peut déjà se connecter à plusieurs canaux Slack pour permettre l’exploitation d’agents indépendants par fonction métier
• Quatre fonctionnalités clés sont présentées pour la prochaine étape
  • Partage de contexte contrôlé : combiner un partage fluide de l’information au sein d’une équipe avec un partage sélectif entre équipes
  • Création d’agents persistants : non pas des sous-agents ponctuels, mais des membres d’équipe dotés d’un ID, d’un environnement et de données persistants
  • Politiques d’autorisation granulaires : autoriser uniquement la lecture des e-mails, limiter l’accès à certains dépôts, définir des plafonds de dépense, etc.
  • Procédures d’approbation humaine : les actions irréversibles sont exécutées après validation humaine
• NanoClaw est présenté comme une couche d’exécution et d’orchestration orientée sécurité, tandis que les sandboxes Docker servent de base d’infrastructure de niveau entreprise
• L’objectif est de construire une pile d’exécution d’agents offrant simultanément isolation par défaut, collaboration contrôlée, visibilité à l’échelle de l’organisation et gouvernance

Présentation de NanoClaw

• NanoClaw est une couche open source d’exécution sécurisée et d’orchestration qui prend en charge l’exploitation d’agents IA au niveau des équipes
• Le projet peut être consulté sur GitHub et soutenu avec une étoile

[GN⁺]

Avis Hacker News

• Cela peut sembler un petit détail, mais si quelques nouvelles décisions de conception se diffusent dans tout le secteur, cela pourrait entraîner des changements vraiment innovants
  Comme l’a mentionné Karpathy, l’idée clé est de fournir une spec de compétence sur « comment écrire des intégrations », au lieu d’implémenter directement des intégrations comme Slack ou Discord
  On pourrait appeler cela du « développement natif pour Claude » ; l’écosystème semble pouvoir évoluer d’un framework « batteries-included » vers une approche « fork and customize »
  Il reste toutefois beaucoup de problèmes à résoudre, comme la manière de distribuer des specs pour les tests, la validation ou la sécurité
  Je me demande aussi si ce type de changement pourrait se produire au niveau de l’OS. Si chaque instance disposait d’un système immunitaire robuste, on pourrait obtenir un écosystème hétérogène plus résistant aux attaques

  • Chaque utilisateur devrait répéter le même travail, donc cela semble moins efficace. Je pense qu’il vaut mieux implémenter une fois et partager avec tout le monde
  • La force de l’open source, c’est le processus de collaboration et de validation. Les LLM produisent beaucoup de bugs au début, mais les humains aussi. À mon avis, il vaut mieux personnaliser à partir d’une base déjà validée
  • Je me dis qu’on pourrait arriver dans un monde où l’on implémente des fonctionnalités en s’échangeant des fichiers de spec en Markdown plutôt que du code

• Quand on parle d’outils de sécurité ou de sandboxing, il faut absolument expliciter le threat model
  Le risque vient du fait qu’un agent IA peut exécuter du code arbitraire sur un hôte contenant des données secrètes
  Par exemple, supprimer une boîte mail, divulguer un calendrier ou effectuer un virement erroné ne peut pas être empêché par le seul sandboxing
  En plus du sandboxing, il faut donc un contrôle des permissions fin et spécifique à chaque tâche et à chaque outil. Par exemple : « cette requête peut seulement lire Gmail, et ne doit pas pouvoir écrire ni supprimer »

  • Tout à fait d’accord. En plus, il faut du suivi des flux de données entre outils (IFC) et des capacités de diminution de privilèges (ocap). Par exemple, il faut pouvoir exprimer des politiques comme « interdiction d’envoyer des données en dehors du fil d’e-mails d’origine »
  • Comme le disait l’article « Don’t Trust AI Agents », les agents IA doivent être conçus sur un principe de méfiance. Il faut supposer les dysfonctionnements et les prompt injections, et construire une architecture qui limite les dégâts
  • J’ai créé le framework d’agents centré sur le contrôle par politiques smith-core et la passerelle smith-gateway. Mais ce type de discussion sur la conception de la sécurité attire très peu l’attention dans la communauté
  • J’ai lu un billet intéressant : comme le souligne OpenClaw Sandbox, les permissions sont binaires alors que le comportement des LLM est probabiliste ; ces deux concepts entrent donc en conflit de manière fondamentale
  • En réalité, des systèmes d’autorisations existants comme IAM, WIF, Macaroons ou Service Accounts existent déjà. Si vous demandez à l’équipe sécurité, il y aura probablement aussi des solutions exploitables en interne

• J’aime bien NanoClaw. OpenClaw était trop complexe, alors que NanoClaw est beaucoup plus simple
  C’est le premier projet qui utilise Claude Code comme interface de configuration, et ajouter des fonctionnalités est à la fois amusant et efficace

  • Mon instance OpenClaw s’est cassée récemment. Une mise à jour a brisé l’intégration OpenRouter, et le code est beaucoup trop complexe
    En plus, le modèle de sécurité ne convient pas à mon environnement Kubernetes rootless, ce qui me cause des problèmes à chaque fois
    Je suis donc passé à Nullclaw. Le fait de pouvoir apprendre Zig tout en déboguant est aussi intéressant sur le plan pédagogique
  • Je me demande quels workflows on peut faire dans Nanoclaw qu’on ne peut pas facilement créer avec Claude

• La sandbox Docker ressemble au framework container d’Apple
  Sur macOS, c’est un runtime natif bien plus léger que Docker, donc très adapté
  Mais sur Linux, je n’ai pas envie d’utiliser un hyperviseur. L’isolation offerte par les namespaces Linux suffit largement
  Je me demande pourquoi OpenClaw ou NanoClaw ne fournissent pas une image Docker officielle correctement configurée

  • Sur macOS, j’utilise Apple Container, et sur les autres OS, Podman
    Il y a quelques bugs réseau dans Container, mais cela en vaut la peine. Il suffit de corriger la configuration DNS
    J’apprécie de ne pas avoir à installer Claude Code ou Node.js sur l’hôte

• Plus important que le fait d’utiliser ou non un conteneur, c’est ce qu’on cherche à faire
  Tant qu’on n’a pas trouvé comment dépenser les tokens pour des tâches utiles, le runtime reste secondaire
  Du point de vue de la sécurité, placer un LLM dans un conteneur ne suffit pas. Ce qui compte, c’est l’étendue des informations accessibles
  Si l’agent a accès à toutes les données, c’est là que se trouve le vrai danger

  • La sandbox Docker utilise des MicroVM comme couche d’isolation supplémentaire. Ce n’est pas un simple conteneur

• Le cœur du sujet, c’est le contrôle fin des permissions et des politiques
  Il ne suffit pas de définir quels outils peuvent être utilisés ; il faut aussi définir ce qu’ils ont le droit de faire
  Par exemple : lecture seule des e-mails, accès à un dépôt spécifique, plafond de dépenses, etc.
  Le sandboxing Docker seul ne suffit pas pour confier à un LLM des actifs sensibles comme des comptes de messagerie

• La sandbox Docker lance pour chaque agent une MicroVM dédiée et un démon Docker dédié, avec un proxy de sortie flexible
  J’ai fait un peu de rétro-ingénierie et l’implémentation est assez intéressante

• NanoClaw n’est pas un produit fini prêt à l’emploi
  Il faut ajouter soi-même des fonctions comme iMessage via un agent de code
  Autrement dit, Claude joue le rôle du compilateur

  • À une époque, on inspectait directement l’assembleur généré par le compilateur
    Les agents de code en sont encore à ce niveau. Dire récemment que « les agents de code sont devenus bien meilleurs » est exagéré
    Il faut toujours répéter à Claude : « ce n’est pas résolu, refais-le »

• Je travaille sur une idée proche de « claws »
  Au lieu d’intégrations avec des apps de messagerie, l’approche consiste à fournir une TUI chiffrée de bout en bout
  Voir wingthing.ai / dépôt GitHub
  Je réfléchis à la manière de prendre en charge Docker, donc je vais aussi regarder ce projet

• Je me demande quel est le cas d’usage clair de Nano/Open-Claw. Est-ce censé gérer ma vie numérique à ma place ?

  • En fait, c’est simple. Soit un cron job LLM, soit un connecteur de chat comme Telegram ou l’e-mail. Le premier peut être fait avec un cron classique, le second avec du code manuel ou Gemini Gems
  • C’est utile pour automatiser des tâches cognitives répétitives comme les résumés d’e-mails, les rappels d’agenda ou les documents de briefing
  • On peut aussi le relier à une app de tâches et laisser un bot la gérer par messages. Cela aide à gagner en productivité
  • J’utilise NanoClaw comme coach alimentation et sport. Il gère mes objectifs, mes plans de repas, mes listes de courses et mon suivi d’entraînement
    Je l’ai migré vers Apple Container et j’y ai ajouté une mémoire longue durée basée sur LanceDB. Je n’ai plus besoin de répéter les mêmes choses