Ne faites pas confiance aux agents IA

Quand on développe avec des agents IA, ils devraient être traités comme non fiables et potentiellement malveillants. Que l’on s’inquiète de l’injection de prompts, d’un modèle qui tente de s’échapper de sa sandbox, ou de quelque chose auquel personne n’a encore pensé, quel que soit votre modèle de menaces, vous ne devriez pas faire confiance à l’agent. La bonne approche n’est pas de meilleurs contrôles de permissions ni des listes d’autorisations plus intelligentes. C’est une architecture qui part du principe que les agents vont mal se comporter et qui contient les dégâts quand c’est le cas.

C’est le principe sur lequel j’ai construit NanoClaw.

Ne faites pas confiance au processus

OpenClaw s’exécute directement sur la machine hôte par défaut. Il dispose d’un mode sandbox Docker optionnel, mais celui-ci est désactivé d’origine, et la plupart des utilisateurs ne l’activent jamais. Sans lui, la sécurité repose entièrement sur des contrôles au niveau applicatif : listes d’autorisations, dialogues de confirmation, un ensemble de commandes “sûres”. Ces contrôles partent d’une confiance implicite que l’agent ne va pas essayer de faire quelque chose de mal. Dès qu’on adopte l’état d’esprit qu’un agent est potentiellement malveillant, il est évident que les blocages au niveau applicatif ne suffisent pas. Ils ne fournissent pas une sécurité hermétique. Un agent déterminé ou compromis peut trouver des moyens de les contourner.

Dans NanoClaw, l’isolation par conteneurs fait partie intégrante de l’architecture. Chaque agent s’exécute dans son propre conteneur, sur Docker ou un Apple Container sous macOS. Les conteneurs sont éphémères : créés à chaque invocation et détruits ensuite. L’agent s’exécute en tant qu’utilisateur non privilégié et ne peut voir que les répertoires qui ont été explicitement montés. La frontière du conteneur est imposée par le système d’exploitation.

Ne faites pas confiance aux autres agents

Même quand la sandbox d’OpenClaw est activée, tous les agents partagent le même conteneur. Vous pourriez avoir un agent comme assistant personnel et un autre pour le travail, dans différents groupes WhatsApp ou canaux Telegram. Ils sont tous dans le même environnement, ce qui signifie que des informations peuvent fuiter entre des agents qui sont censés accéder à des données différentes.

Les agents ne devraient pas plus se faire confiance entre eux que vous ne leur faites confiance. Dans NanoClaw, chaque agent obtient son propre conteneur, système de fichiers et historique de session Claude. Votre assistant personnel ne peut pas voir les données de votre agent de travail, car ils s’exécutent dans des sandboxes complètement séparées.

La frontière du conteneur est la couche de sécurité solide : l’agent ne peut pas s’en échapper quelle que soit la configuration. En plus de cela, une liste de montages autorisés dans ~/.config/nanoclaw/mount-allowlist.json agit comme une couche supplémentaire de défense en profondeur : elle existe pour empêcher l’utilisateur de monter accidentellement quelque chose qui ne devrait pas être exposé, pas pour empêcher l’agent de s’échapper. Les chemins sensibles (.ssh, .gnupg, .aws, .env, private_key, credentials) sont bloqués par défaut. La liste d’autorisations se trouve en dehors du répertoire du projet, de sorte qu’un agent compromis ne peut pas modifier ses propres permissions. Le code de l’application hôte est monté en lecture seule, donc rien de ce que fait un agent ne peut persister après la destruction du conteneur.

Les personnes dans vos groupes ne devraient pas non plus être considérées comme fiables. Les groupes non principaux sont non fiables par défaut. Les autres groupes, et les personnes qui en font partie, ne peuvent pas envoyer de messages à d’autres chats, planifier des tâches pour d’autres groupes, ni voir les données des autres groupes. N’importe qui dans un groupe pourrait envoyer une injection de prompt, et le modèle de sécurité en tient compte.

Ne faites pas confiance à ce que vous ne pouvez pas lire

OpenClaw compte près d’un demi-million de lignes de code, 53 fichiers de configuration et plus de 70 dépendances. Cela brise le principe fondamental de la sécurité open source. Chromium a plus de 35 millions de lignes, mais vous faites confiance aux processus de revue de Google. La plupart des projets open source fonctionnent dans l’autre sens : ils restent suffisamment petits pour que de nombreux yeux puissent effectivement les examiner. Personne n’a examiné les 400 000 lignes d’OpenClaw. Il a été écrit en quelques semaines sans processus de revue approprié. La complexité est l’endroit où les vulnérabilités se cachent, et l’analyse de Microsoft l’a confirmé : les risques d’OpenClaw pouvaient émerger à travers des appels API normaux, car aucune personne ne pouvait voir l’ensemble du tableau.

NanoClaw est un seul processus et une poignée de fichiers. Nous nous appuyons fortement sur le Claude Agent SDK d’Anthropic, le wrapper autour de Claude Code, pour la gestion des sessions, la compaction de la mémoire et bien plus encore, au lieu de réinventer la roue. Un développeur compétent peut examiner l’intégralité du code en un après-midi. C’est une contrainte délibérée, pas une limitation. Nos directives de contribution n’acceptent que les corrections de bugs, les corrections de sécurité et les simplifications.

Les nouvelles fonctionnalités arrivent par le biais de skills : des instructions avec une implémentation de référence complète et fonctionnelle qu’un agent de programmation intègre dans votre base de code. Vous examinez exactement quel code sera ajouté avant qu’il ne soit appliqué. Et vous n’ajoutez que les intégrations dont vous avez réellement besoin. Chaque installation aboutit à quelques milliers de lignes de code adaptées aux besoins exacts du propriétaire.

C’est la vraie différence. Avec une base de code monolithique de 400 000 lignes, même si vous n’activez que deux intégrations, le reste du code est toujours là. Il est toujours chargé, fait toujours partie de votre surface d’attaque, toujours accessible par les injections de prompts et les agents malveillants. Vous ne pouvez pas séparer ce qui est actif de ce qui est dormant. Vous ne pouvez pas l’auditer, car vous ne pouvez même pas définir les limites de ce qu’est “votre code”. Avec les skills, la limite est évidente : ce sont quelques milliers de lignes, c’est entièrement du code que vous avez choisi d’ajouter, et vous pouvez lire chaque ligne. Le noyau devient en fait plus petit au fil du temps : le support WhatsApp, par exemple, est en train d’être extrait et empaqueté sous forme de skill.

Concevoir pour la méfiance

Si une hallucination ou un agent qui se comporte mal peut causer un problème de sécurité, alors le modèle de sécurité est cassé. La sécurité doit être imposée en dehors de la surface agentique, et non dépendre du bon comportement de l’agent. Les conteneurs, les restrictions de montage et l’isolation du système de fichiers existent pour que, même quand un agent fait quelque chose d’inattendu, le rayon d’explosion soit contenu.

Rien de tout cela n’élimine le risque. Un agent IA avec accès à vos données est par nature une situation à haut risque. Mais la bonne réponse est de rendre cette confiance aussi étroite et vérifiable que possible. Ne faites pas confiance à l’agent. Construisez des murs autour de lui.

Vous pouvez lire le code source et le modèle de sécurité complet de NanoClaw ; ils sont assez courts pour être lus en un après-midi.