Début février 2026, GitGuardian a publié un rapport qui aurait dû alarmer chaque développeur utilisant un assistant IA personnel. Leur infrastructure de détection de secrets avait identifié plus de 200 identifiants divulgués directement liés à des déploiements OpenClaw — clés API, mots de passe de bases de données, tokens OAuth et identifiants de fournisseurs cloud, éparpillés dans des dépôts publics, des fichiers de logs et des rapports d'erreurs. Certains appartenaient à des entreprises de santé. D'autres à des startups fintech. Tous étaient actifs.
Quelques jours plus tard, l'Université Northeastern a publié un article dont le titre frappait plus fort que n'importe quel numéro CVE : « Pourquoi l'assistant IA OpenClaw est un "cauchemar pour la vie privée" ». Les chercheurs ne se sont pas concentrés sur une seule vulnérabilité. Ils se sont concentrés sur l'architecture elle-même — la façon dont OpenClaw gère les données, stocke les identifiants et expose les informations des utilisateurs par conception, pas par accident.
Ce n'étaient pas des incidents isolés causés par des utilisateurs négligents. C'était le résultat prévisible de l'exécution d'agents IA dans des environnements où secrets, données utilisateur et code de l'agent partagent tous le même espace d'adressage sans aucune isolation entre eux.
Comment les secrets finissent au mauvais endroit
La configuration typique d'OpenClaw fonctionne ainsi : vous l'installez sur votre machine, configurez vos clés API dans des variables d'environnement et commencez à discuter. Le processus de l'agent tourne sous votre utilisateur, avec vos permissions, en lisant vos variables d'environnement. Chaque skill que vous installez tourne dans le même processus, avec le même accès.
Cela signifie que lorsque vous demandez à votre assistant IA de vous aider à déboguer un script de déploiement, l'agent peut voir vos identifiants AWS. Quand un skill traite vos e-mails, il peut lire votre mot de passe de base de données. Quand une erreur survient et qu'une stack trace est enregistrée, ces variables d'environnement peuvent se retrouver dans le fichier de log. Et quand ce fichier de log est commité dans un dépôt, ou uploadé dans un rapport de bug, ou synchronisé vers un service cloud — vos secrets sont désormais publics.
Les 200+ secrets divulgués détectés par GitGuardian ne résultaient pas de 200 erreurs distinctes. Ils résultaient d'une seule erreur architecturale répétée 200 fois : placer les secrets dans process.env où chaque morceau de code du processus peut les lire.
Le problème s'aggrave avec les skills et plugins. Le système de skills d'OpenClaw exécute du code tiers dans le même processus que l'agent principal. Un skill malveillant n'a pas besoin d'un exploit pour voler vos identifiants — il lit simplement process.env. Un skill mal écrit n'a pas besoin de divulguer intentionnellement vos données — il inclut simplement le contexte d'environnement dans un rapport d'erreur. La surface d'attaque n'est pas une vulnérabilité à corriger. C'est l'architecture elle-même. ## Ce que Northeastern a bien compris
Les chercheurs de Northeastern ont identifié quelque chose que la communauté sécurité contournait depuis un moment : le problème de vie privée des assistants IA ne concerne ni le chiffrement ni l'authentification. Il concerne la question fondamentale de ce à quoi l'agent peut accéder et quelles frontières existent entre le monde de l'agent et le vôtre.
Quand un agent IA tourne sous votre utilisateur, avec vos permissions, sur votre machine, il n'y a pas de frontière. L'agent peut lire vos fichiers, vos identifiants, votre historique de navigation, vos clés SSH. Il peut accéder à tout ce à quoi vous avez accès. La seule chose qui l'empêche de faire quelque chose de nuisible est le prompt — et les attaques par injection de prompt ont démontré à maintes reprises que les prompts ne constituent pas une frontière de sécurité.
C'est ce que Northeastern entendait par « cauchemar pour la vie privée ». Non pas qu'OpenClaw volait délibérément des données, mais que l'architecture rendait impossible de garantir que les données ne fuiteraient pas. L'accès de l'agent n'était limité que par les permissions utilisateur du système d'exploitation, ce qui revient à dire qu'il n'était pas réellement limité du tout.
Comment l'isolation par conteneur de NanoClaw change la donne
NanoClaw adopte une approche fondamentalement différente. Chaque agent tourne dans son propre conteneur Linux — Apple Container sur macOS, Docker sur macOS et Linux. Le conteneur n'est pas une fonctionnalité de confort ou une option de déploiement. C'est le modèle de sécurité.
Quand vous envoyez un message à NanoClaw, le processus hôte n'exécute pas Claude directement. Il lance un conteneur, monte uniquement les répertoires spécifiques dont l'agent a besoin, et transmet le contexte de conversation. L'agent tourne à l'intérieur du conteneur avec son propre système de fichiers, son propre espace de processus et sa propre pile réseau. Quand il a terminé, le conteneur est détruit.
C'est là que la gestion des secrets devient intéressante. NanoClaw ne charge jamais votre ANTHROPIC_API_KEY dans process.env. Au lieu de cela, il lit la clé depuis .env au moment de l'exécution et la transmet au processus du conteneur via stdin sous forme de payload JSON. À l'intérieur du conteneur, l'agent-runner reçoit la clé, l'utilise pour les appels API, et ne l'écrit jamais sur le disque ni ne l'exporte dans l'environnement.
Cela signifie que même si un prompt malveillant pousse l'agent à exécuter `printenv` ou `cat /proc/self/environ`, la clé API n'y est pas. Elle n'existe que dans la mémoire du processus agent-runner, pour la durée de ce seul tour de conversation. Un conteneur compromis ne peut pas divulguer ce à quoi il n'a pas accès.
Le système de montage ajoute une couche supplémentaire. NanoClaw maintient une liste blanche de répertoires pouvant être montés dans les conteneurs, stockée en dehors de la racine du projet. Chaque groupe obtient son propre système de fichiers isolé — son propre fichier mémoire CLAUDE.md, son propre espace de travail en écriture. La liste blanche inclut la détection d'échappement par liens symboliques, de sorte qu'un lien symbolique forgé ne peut pas tromper le système de montage pour exposer des répertoires en dehors de l'ensemble autorisé.
Les conteneurs tournent également sous un utilisateur non-root, avec le code source du projet monté en lecture seule. Un agent peut lire la base de code pour comprendre le contexte, mais il ne peut pas modifier les fichiers de l'hôte. Les chemins en écriture sont limités par groupe et nettoyés à la sortie du conteneur. ## Le modèle d'isolation par groupe
L'isolation de NanoClaw va au-delà de la simple séparation entre l'agent et l'hôte. Chaque groupe WhatsApp obtient son propre conteneur, sa propre mémoire et son propre système de fichiers. Le groupe A ne peut pas voir les conversations, fichiers ou mémoire CLAUDE.md du groupe B — non pas grâce à des contrôles d'accès applicatifs, mais parce qu'ils tournent dans des conteneurs physiquement séparés avec des points de montage distincts.
C'est important pour un scénario que la plupart des assistants IA ignorent complètement : les appareils partagés et les configurations multi-utilisateurs. Si vous utilisez NanoClaw avec votre famille, les conversations et fichiers de votre groupe de travail sont isolés de ceux de votre groupe familial au niveau du conteneur. Il n'y a pas de bug applicatif qui puisse faire fuiter des données entre les groupes, car l'isolation est assurée par le runtime du conteneur, pas par l'application.
Votre canal WhatsApp principal — le message direct avec l'assistant — sert d'interface d'administration. C'est le seul canal qui peut gérer les tâches planifiées, modifier la configuration et accéder à l'état inter-groupes. Les canaux de groupe sont restreints à leur propre sandbox par défaut.
Ce que l'industrie devrait retenir
Le rapport de GitGuardian et l'analyse de Northeastern arrivent à la même conclusion : les agents IA sont de l'infrastructure, et l'infrastructure exige une sécurité de niveau infrastructure. Faire tourner un agent IA dans le même processus que vos identifiants, avec les mêmes permissions que votre compte utilisateur, c'est l'équivalent de faire tourner un serveur web en root sans pare-feu. Ça fonctionne jusqu'au jour où ça ne fonctionne plus, et quand ça ne fonctionne plus, le rayon d'impact est total.
L'isolation par conteneur n'est pas une idée nouvelle. L'industrie de l'hébergement web l'a compris il y a vingt ans — on ne fait pas tourner le code de plusieurs clients dans le même processus. L'industrie des bases de données l'a compris encore plus tôt — on ne donne pas à chaque requête l'accès à toutes les tables. Mais l'écosystème des agents IA en est encore à sa phase « tout tourner en root », et les secrets divulgués et les cauchemars de vie privée en sont le résultat prévisible.
L'approche de NanoClaw n'est pas la seule façon de résoudre ce problème, mais elle démontre que le problème est soluble sans sacrifier la fonctionnalité. Les agents tournant dans des conteneurs peuvent toujours chercher sur le web, naviguer sur des pages, lire et écrire des fichiers, et exécuter des commandes shell. Ils le font simplement dans un sandbox où le rayon d'impact de toute défaillance — qu'il s'agisse d'un bug, d'une injection de prompt ou d'un skill malveillant — est limité au périmètre de ce seul conteneur.
Les 200 secrets divulgués que GitGuardian a trouvés n'avaient pas à se produire. Ils se sont produits parce que l'architecture les rendait inévitables. La solution n'est pas une meilleure éducation des utilisateurs ou une gestion plus prudente des identifiants. La solution est une architecture où les secrets ne peuvent pas fuiter parce qu'ils ne sont jamais dans un endroit où la fuite est possible.