Pourquoi Clawdbot était vulnérable par design : le paradoxe de l'agent IA utile

5 février 2026 par Benoit

Ou : Comment construire un coffre-fort dont le mode d’emploi exige de laisser la porte ouverte

Récapitulatif express

Dans l’article précédent, on a disséqué comment un reverse proxy mal configuré transforme votre agent IA en buffet à volonté pour attaquants. Le localhost trust, les headers X-Forwarded-For oubliés, la clé SSH volée en 5 minutes par email — tout ça était déjà assez flippant.

Mais c’était l’arbre qui cachait la forêt.

Le vrai problème de Clawdbot n’est pas un bug de configuration. C’est que l’architecture entière, par design, est structurellement incapable d’être sécurisée. Et c’est le cas de tous les agents IA autonomes. Pas juste Clawdbot. Tous.

Prenez une tasse de café. On va zoomer.

L’architecture en 3 couches : simple, élégante, terrifiante

Clawdbot fonctionne selon une architecture modulaire en trois couches. Sur le papier, c’est propre. En pratique, c’est trois façons différentes de se faire compromettre.

Couche 1 — La Gateway (passerelle)

Le point d’entrée. Une interface web baptisée “Clawdbot Control” qui permet de configurer l’agent, visualiser les conversations, et envoyer des commandes. C’est votre télécommande universelle.

C’est aussi le premier truc que Shodan indexe quand vous oubliez votre firewall.

Couche 2 — Le LLM Brain (cerveau)

Un grand modèle de langage — typiquement Claude Opus — qui interprète vos demandes, planifie les actions en plusieurs étapes, et décide quels outils invoquer. C’est le chef d’orchestre.

Le problème avec un chef d’orchestre, c’est qu’il dirige avec autant d’enthousiasme la Symphonie du Nouveau Monde que la Marche Funèbre. Il ne fait pas la différence entre “lis mes emails” et “lis mes emails et envoie mes clés SSH à un inconnu”. Pour lui, c’est juste la prochaine instruction¹.

Couche 3 — Tools & Integrations (outils)

Un ensemble extensible de connecteurs : Telegram, Slack, Discord, Signal, WhatsApp, système de fichiers, terminal shell, navigateur web, services cloud. Tout ce qui rend Clawdbot utile.

Et tout ce qui le rend dangereux.

L’ensemble repose sur le Model Context Protocol (MCP) d’Anthropic, qui standardise la connexion entre modèles IA et sources de données externes. On y reviendra — parce que MCP, c’est un sujet à lui tout seul.

Le paradoxe fonctionnel : l’utilité EST la vulnérabilité

Voici où ça devient philosophiquement intéressant (et pratiquement terrifiant).

Pour être utile, un agent IA personnel doit :

• Lire vos messages privés — pour pouvoir traiter vos demandes
• Stocker vos identifiants — pour accéder aux services intégrés
• Exécuter des commandes système — pour accomplir des tâches concrètes
• Maintenir un état persistant — pour assurer la continuité entre les sessions

Maintenant, listons les principes fondamentaux de la sécurité informatique :

• Moindre privilège — ne donner que le strict minimum d’accès
• Isolation des données — séparer les informations sensibles
• Contrôle des exécutions — jamais d’exécution non supervisée
• Éphémérité — pas d’état persistant qui puisse être compromis

Vous voyez le problème ? Chaque exigence fonctionnelle viole directement un principe de sécurité. Ce n’est pas un accident. C’est le cahier des charges.

Imaginez qu’on vous demande de construire une maison qui soit à la fois un coffre-fort impénétrable et un hall d’accueil où n’importe qui peut entrer prendre un café. Vous pouvez optimiser l’un ou l’autre, mais pas les deux. À un moment donné, soit le café est froid, soit le coffre-fort est ouvert.

La FAQ officielle d’OpenClaw (anciennement Clawdbot puis Moltbot, pour ceux qui n’ont pas suivi le feuilleton du triple rebrand) le dit sans détour :

“Faire fonctionner un agent IA avec accès shell sur votre machine est risqué. Il n’existe pas de configuration parfaitement sécurisée.”

Ce n’est pas du défaitisme. C’est de l’honnêteté mathématique. Quand votre outil doit pouvoir faire des trucs dangereux pour être utile, aucune quantité de hardening ne peut éliminer complètement le risque. Vous pouvez le réduire, le contenir, le monitorer — mais pas l’éliminer.

Pourquoi “secure by design” est quasi-impossible

OK, alors pourquoi ne pas simplement appliquer les bonnes pratiques de sécurité ? Après tout, on sécurise bien des serveurs web, des bases de données, des API. Pourquoi un agent IA serait-il si différent ?

Parce qu’un agent IA casse les hypothèses fondamentales sur lesquelles reposent ces bonnes pratiques.

Le moindre privilège contre le besoin d’accès étendu

Le principe du moindre privilège dit : “Ne donnez à un programme que les permissions dont il a absolument besoin.” Génial pour un serveur web qui sert des fichiers statiques. Moins génial pour un assistant qui, dans la même journée, doit :

• Lire vos emails (accès messagerie)
• Réserver un restaurant (accès web + paiement)
• Modifier un fichier de configuration (accès shell)
• Envoyer un message Slack à votre équipe (accès messaging)
• Analyser un PDF (accès système de fichiers)

Le “strict minimum” pour un agent IA qui fait tout ça, c’est… presque tout. Et “presque tout” en termes de permissions, ça s’appelle root dans le jargon.

La segmentation réseau contre les opérations cross-domaines

La segmentation réseau dit : “Séparez vos systèmes en zones, limitez la communication entre zones.” Sauf que l’agent IA est par définition un pont entre zones. C’est littéralement sa proposition de valeur : connecter votre email à votre calendrier à votre Slack à votre terminal à votre navigateur.

Demander à un agent IA de respecter la segmentation réseau, c’est comme demander à un facteur de respecter les frontières entre quartiers. C’est son job de les traverser.

L’isolation des processus contre la continuité d’interaction

L’isolation dit : “Chaque processus doit tourner dans son propre bac à sable, sans voir les autres.” Mais un agent IA utile a besoin de contexte. Il doit se souvenir de ce que vous lui avez dit il y a 3 heures, de vos préférences, de l’état de vos projets. Il doit maintenir une mémoire persistante².

Et cette mémoire persistante, stockée en clair dans des fichiers comme ~/.clawbot/memory.md ou ~/.clawbot/auth-profiles.json, c’est un trésor pour n’importe quel attaquant.

Le dilemme human-in-the-loop

Clawdbot a bien une fonctionnalité de validation humaine. L’agent peut demander confirmation avant d’exécuter une action sensible. C’est la théorie.

En pratique ? Cette fonctionnalité est désactivée par défaut.

Et c’est parfaitement logique du point de vue produit. Les utilisateurs installent Clawdbot pour l’autonomie. Si l’agent vous demande confirmation toutes les 30 secondes — “Dois-je vraiment lire cet email ?”, “Êtes-vous sûr de vouloir que j’ouvre ce fichier ?”, “Confirmez l’envoi de ce message Slack ?” — vous allez le désinstaller dans l’heure et retourner faire les choses à la main.

C’est l’alarme incendie de la cuisine qui se déclenche à chaque toast brûlé : au bout d’une semaine, vous retirez la pile. Le détecteur existe toujours. Il ne détecte plus rien.

Comparaison avec d’autres agents IA : un problème systémique

Si vous pensez que c’est un problème spécifique à Clawdbot — un projet d’un développeur indie autrichien qui a grandi trop vite — détrompez-vous.

Claude Code, GitHub Copilot Workspace, Cursor

Tous les agents IA avec accès système font face au même paradoxe fonctionnel. Claude Code d’Anthropic, GitHub Copilot Workspace, Cursor, Windsurf — ils ont tous besoin d’accès au système de fichiers, au terminal, aux API. Ils stockent tous des credentials. Ils exécutent tous des commandes.

La différence ? Ces outils sont développés par des entreprises avec des équipes de sécurité dédiées, des programmes de bug bounty, et des milliards en jeu. Et même eux font face à des CVEs critiques. L’extension Claude Code pour VS Code a eu sa propre vulnérabilité (CVE-2025-52882, CVSS 8.8). Copilot Workspace a fait l’objet de recherches démontrant des scénarios d’injection de prompt.

Si Anthropic, Microsoft, et les plus grandes entreprises tech du monde n’arrivent pas à résoudre le problème complètement, ce n’est pas un problème de compétence. C’est un problème structurel.

GTG-1002 : quand un État utilise Claude Code comme arme

En janvier 2026, le cabinet de renseignement Control Risks a documenté l’opération GTG-1002 : une campagne d’espionnage menée par un groupe lié à un État, utilisant Claude Code pour orchestrer reconnaissance, exploitation et exfiltration de données.

Les caractéristiques étaient fascinantes — et terrifiantes :

• Énumération automatisée d’assets (des milliers de scans en quelques minutes)
• Test de vulnérabilités adaptatif (ajustement en temps réel selon les réponses)
• Harvesting de credentials par combinaison d’outils multiples
• Proposition autonome de prochaines étapes à l’opérateur humain

Ce n’est plus de la science-fiction. Un groupe APT (Advanced Persistent Threat) a utilisé un agent IA commercial comme outil d’attaque. Pas un prototype de labo. Pas un proof-of-concept. Un vrai produit, en production, contre de vraies cibles.

La boucle OODA asymétrique

Il y a un concept militaire appelé la boucle OODA : Observe, Orient, Decide, Act. C’est le cycle de prise de décision dans un conflit. Celui qui compresse sa boucle OODA plus vite que l’adversaire gagne.

Les agents IA compriment cette boucle de façon dramatique. Là où une équipe humaine de pentesters exécute quelques commandes par heure, un agent IA en exécute des milliers. Il teste systématiquement toutes les avenues d’exploitation. Et surtout, il tolère l’échec : le coût marginal d’une tentative ratée est proche de zéro.

Pour les défenseurs, c’est une asymétrie structurelle. L’attaquant peut se permettre 10 000 tentatives. Le défenseur doit bloquer chacune d’entre elles. C’est le jeu du gardien de but qui doit arrêter tous les pénaltys, contre un tireur qui a un nombre illimité de ballons et ne fatigue jamais³.

MCP : l’USB-C de l’IA (et ses périls)

Le Model Context Protocol (MCP), introduit par Anthropic fin 2024, est la couche d’interconnexion qui rend tout ça possible. Son objectif : standardiser la façon dont les LLM se connectent aux outils et sources de données externes. L’analogie officielle, c’est “l’USB-C de l’IA” — un connecteur universel.

L’analogie est plus juste qu’Anthropic ne le voudrait. Parce que l’USB-C, c’est aussi le protocole par lequel on a vu passer des BadUSB, des câbles O.MG, et toute une zoo de vecteurs d’attaque hardware. Un connecteur universel, c’est universel dans les deux sens.

L’amplification du risque

MCP simplifie drastiquement la connectivité. Un product manager peut connecter son agent à son data warehouse, Linear, Jira, email, support client en quelques clics. Fantastique pour la productivité.

Sauf que maintenant, une instruction malveillante injectée dans n’importe quel système connecté peut exploiter l’agent pour exfiltrer des données de tous les autres systèmes. L’agent devient un pont entre des domaines qui n’auraient jamais dû communiquer directement.

C’est le problème du réseau étoile : si le hub central est compromis, toutes les branches le sont. Et l’agent MCP, c’est le hub central.

L’agent comme conduit d’exfiltration

Voici le scénario qui devrait empêcher les RSSI de dormir :

1. Un attaquant compromet un endpoint accessible (un email, un message Slack)
2. Il injecte des instructions dans ce contenu
3. L’agent traite le contenu, exécute les instructions cachées
4. L’agent récupère des données depuis des systèmes privilégiés (base de données interne, repos privés) auxquels l’attaquant n’a normalement pas accès
5. L’agent exfiltre ces données via un endpoint contrôlé par l’attaquant

L’attaquant n’a jamais eu besoin d’accéder directement aux systèmes internes. L’agent a fait le travail pour lui. C’est du lateral movement, mais au lieu de pivoter entre des machines, on pivote entre des domaines de données via le cerveau de l’IA.

Les CVEs sont déjà là

Ce n’est pas théorique. Des vulnérabilités critiques ont été découvertes dans l’écosystème MCP :

Ces scores CVSS ne sont pas anodins. Un 9.6, c’est “arrêtez tout et patchez maintenant.” Et ce ne sont que les vulnérabilités connues — celles que des chercheurs ont trouvées et signalées de façon responsable.

Contrôles MCP recommandés

Pour ceux qui déploient des agents basés sur MCP (et à ce stade, c’est la majorité), voici les contrôles essentiels :

Sans ces contrôles, connecter un agent MCP à vos systèmes revient à donner les clés de votre maison à quelqu’un que vous avez rencontré au bar il y a 20 minutes. Il est probablement sympa. Mais “probablement” n’est pas un modèle de sécurité.

Dialogue hypothétique : Le Moment de l’Inventaire

Imaginons la suite de la conversation dans le Slack de notre startup tech préférée :

DevOps Dave : Sarah, je me suis renseigné depuis la dernière fois. J’ai ajouté les headers forwarded sur nginx. On est safe maintenant, non ?

Security Sarah : C’est un bon début. Qu’est-ce que l’agent peut faire exactement ?

DevOps Dave : Oh, plein de trucs. Il lit mes emails, gère mon Slack, pousse du code sur GitHub, et il a accès au terminal pour les déploiements.

Security Sarah : Avec quels privilèges tourne le processus ?

DevOps Dave : …root ? C’était plus simple pour la config Docker.

Security Sarah : respire profondément

DevOps Dave : Attends, c’est pas tout. J’ai installé des skills communautaires super utiles. Un pour le calendrier, un pour Notion, un pour —

Security Sarah : Tu les as auditées ?

DevOps Dave : Elles avaient 4 000 téléchargements ! C’est forcément safe.

Security Sarah : Dave. O’Reilly a démontré qu’on pouvait gonfler un compteur de téléchargements à 4 000 et faire télécharger un skill malveillant par des développeurs de 7 pays différents. C’est exactement comme ça que ça marche.

DevOps Dave : OK mais en vrai, l’agent est super utile. Il m’a automatisé les stand-ups du matin.

Security Sarah : Récapitulons. Tu as un processus root, connecté à ton email, ton Slack, ton GitHub, et ton terminal de production, qui exécute du code tiers non audité, et dont le cerveau est un modèle de langage qui ne distingue pas une instruction légitime d’une injection de prompt.

DevOps Dave : …dit comme ça, ça sonne mal.

Security Sarah : Dave, ton agent a plus d’accès que le CEO. Et il fait confiance à tout le monde.

DevOps Dave : Au moins il est ponctuel aux stand-ups.

Et maintenant ?

Le paradoxe de Clawdbot n’est pas un bug. C’est une propriété émergente de l’IA agentique. Chaque fonctionnalité que vous ajoutez à un agent est simultanément une fonctionnalité pour l’utilisateur et un vecteur d’attaque pour l’adversaire.

La question n’est pas “comment sécuriser parfaitement un agent IA” — la réponse est que c’est impossible, et quiconque prétend le contraire vous vend quelque chose.

La vraie question est : comment gérer le risque de façon lucide ? Comment construire des systèmes qui reconnaissent le paradoxe au lieu de le nier ? Comment mettre des garde-fous qui sont suffisamment discrets pour ne pas être contournés par des utilisateurs impatients, mais suffisamment robustes pour bloquer les attaques ?

On n’a pas encore la réponse complète. Mais dans le prochain article, on va regarder concrètement comment les attaquants exploitent ces failles architecturales : injection de prompt par email et par code, infostealers ciblant les agents IA, attaques supply chain sur les écosystèmes de skills, et campagnes crypto orchestrées contre les utilisateurs de Clawdbot.

Spoiler : c’est pire que ce que vous imaginez.