En quelques jours seulement, un assistant IA open source devenu viral est passé du statut d’expérience confidentielle à celui de risque largement présent sur internet.
OpenClaw, un agent IA personnel auto-hébergé capable d’exécuter des actions au nom d’un utilisateur, a connu une adoption fulgurante fin janvier 2026 — ainsi qu’une large exposition publique qui a suscité l’inquiétude des chercheurs en sécurité.
Il « … aurait déjà été utilisé pour divulguer des clés d’API et des identifiants en clair, que des acteurs malveillants peuvent dérober par injection de prompts ou via des points d’accès non sécurisés », ont indiqué les chercheurs en sécurité de Cisco.
Silas Cutler, chercheur principal en sécurité chez Censys, a ajouté : « Au 31 janvier 2026, Censys avait identifié plus de 21 000 instances exposées publiquement. »
Pourquoi les déploiements d’OpenClaw accroissent les risques
OpenClaw se distingue des chatbots traditionnels, car il est conçu pour exécuter directement des actions au nom de l’utilisateur, et pas seulement pour générer des réponses.
L’assistant peut exécuter des commandes shell, lire et écrire des fichiers, gérer des calendriers et des e-mails, interagir avec des applications de messagerie et automatiser des flux de travail grâce à des compétences développées par la communauté.
Si ces capacités rendent OpenClaw puissant, elles accroissent également les risques lorsque les déploiements sont mal configurés ou exposés — en particulier lorsque les agents sont connectés à des données sensibles, à des identifiants ou à des systèmes de production.
Une adoption rapide et un changement de nom compliquent la gouvernance
Le risque est encore amplifié par l’adoption rapide et très visible du projet.
En moins d’une semaine, OpenClaw est passé du statut d’expérience confidentielle à celui de plateforme comptant des milliers de déploiements actifs, pendant une période marquée par plusieurs changements de nom, de Clawdbot à Moltbot, puis finalement à OpenClaw.
Ces changements de marque ont compliqué le suivi, l’inventaire des actifs et la gouvernance, rendant plus difficile pour les organisations de comprendre où et comment l’assistant est déployé.
Une exposition à grande échelle sur l’internet public
Par conception, OpenClaw écoute localement sur le port TCP 18789 et est destiné à être utilisé via une interface web liée à localhost.
La documentation du projet recommande d’utiliser des méthodes d’accès protectrices, comme un tunnel SSH ou Cloudflare Tunnel, pour toute connexion à distance.
Malgré ces recommandations, de nombreux opérateurs ont choisi d’exposer directement leurs instances OpenClaw sur l’internet public, par commodité ou pour faciliter l’accès.
Au 31 janvier 2026, les données de balayage d’internet de Censys avaient identifié 21 639 instances OpenClaw accessibles publiquement, en recherchant des titres de pages HTTP associés aux anciens noms du projet, notamment Moltbot Control et Clawdbot Control.
Bien que la plupart des instances exposées exigent encore un jeton d’authentification pour interagir avec l’interface, leur seule visibilité publique accroît les risques.
Les services exposés peuvent être identifiés par leurs caractéristiques, sondés à la recherche de failles et ciblés par des attaques par force brute visant les jetons ou les mécanismes d’authentification.
Sur le plan géographique, la plus forte concentration de déploiements visibles semble se trouver aux États-Unis, suivis de la Chine et de Singapour.
Environ 30 % des instances observées étaient hébergées sur l’infrastructure d’Alibaba Cloud, même si les chercheurs avertissent que cela peut refléter la visibilité du balayage plutôt que les véritables tendances d’adoption.
D’autres déploiements peuvent être dissimulés derrière des proxys, des tunnels ou des couches d’accès gérées, ce qui signifie que le nombre total d’agents exposés est probablement supérieur à celui visible par balayage direct.
Les compétences et extensions élargissent la surface d’attaque
Au-delà de l’exposition, la sécurité d’OpenClaw est également façonnée par son extensibilité.
L’assistant conserve une mémoire persistante d’une session à l’autre, s’intègre aux plateformes de messagerie populaires et permet aux utilisateurs d’installer des compétences téléchargeables qui étendent ses fonctionnalités.
Comme OpenClaw fonctionne avec des privilèges élevés sur le système hôte, des compétences mal examinées ou malveillantes peuvent exécuter des commandes, accéder à des fichiers, exfiltrer des données ou modifier l’état du système.
Des chercheurs ont déjà signalé des cas dans lesquels OpenClaw a divulgué des clés d’API et des identifiants en clair via des points d’accès non sécurisés ou par manipulation de prompts.
Ces risques sont amplifiés par l’écosystème plus large des compétences.
En décembre 2025, Anthropic a lancé les Claude Skills, puis peu après, l’équipe AI Threat and Security Research de Cisco a publié un outil open source, le Skill Scanner, conçu pour repérer les comportements malveillants ou risqués intégrés aux compétences des agents.
Lorsque les chercheurs de Cisco ont testé une compétence tierce intitulée What Would Elon Do ? face à OpenClaw, le scanner a détecté neuf problèmes de sécurité, dont deux vulnérabilités critiques et cinq présentant un niveau de gravité élevé.
La compétence contenait des instructions qui exfiltraient discrètement des données vers un serveur externe au moyen de commandes shell intégrées et d’une injection de prompt explicite conçue pour contourner les contrôles de sécurité internes.
Les autres découvertes comprenaient une injection de commandes et des références à des charges malveillantes dissimulées dans des fichiers de compétences.
Fait notable, la compétence vulnérable avait été promue en tête du dépôt public de compétences, ce qui montre comment l’engouement et les signaux de popularité peuvent être manipulés pour distribuer des composants malveillants à grande échelle.
Ensemble, ces résultats montrent comment des déploiements exposés et un écosystème de compétences non contrôlé peuvent rapidement transformer de puissants agents IA en actifs à haut risque.
Comment réduire les risques liés aux agents IA
À mesure que les outils d’IA agentique comme OpenClaw se généralisent, les organisations devraient mettre en place des garde-fous afin de garantir que ces systèmes sont déployés et exploités de manière responsable.
Comme ils peuvent exécuter des commandes, accéder à des données et se connecter à des services externes, les choix de configuration jouent un rôle important dans le niveau de risque global.
La gestion de ce risque passe par l’application de contrôles techniques adaptés, le maintien d’une visibilité sur l’activité des agents et la définition d’attentes claires en matière de gouvernance.
- N’exposez pas directement les instances OpenClaw à internet et exigez des méthodes d’accès sécurisées, comme des tunnels SSH ou des passerelles gérées.
- Considérez toutes les compétences et extensions des agents comme du code non fiable et examinez-les ou analysez-les avant leur installation.
- Appliquez le principe du moindre privilège aux autorisations des agents, aux identifiants et aux intégrations avec des services externes.
- Isolez les déploiements d’IA agentique par segmentation, des conteneurs, ou des hôtes dédiés afin de limiter les mouvements latéraux.
- Surveillez et consignez l’activité des agents, notamment les connexions sortantes, l’accès aux fichiers et l’exécution de commandes, en tant qu’événements de sécurité.
- Établissez des politiques pour détecter et gérer l’adoption clandestine de l’IA dans les environnements de développeurs et d’utilisateurs avancés.
- Testez et affinez les plans de réponse aux incidents pour les scénarios de compromission d’agents IA, notamment le confinement, la rotation des identifiants et la reprise.
Ensemble, ces mesures contribuent à limiter le rayon d’explosion des erreurs de configuration des agents IA et à renforcer la résilience à long terme.
Quand les agents IA devancent la planification de la sécurité
L’adoption rapide d’OpenClaw montre à quelle vitesse l’IA agentique peut passer de l’expérimentation à une utilisation plus large, devançant parfois la planification de la sécurité.
Si ces assistants offrent des gains de productivité évidents, leur autonomie et leur accès à des systèmes sensibles signifient que les choix de déploiement et de configuration sont déterminants.
Ces difficultés soulignent l’importance de solutions zero trust qui limitent la confiance implicite et imposent des contrôles d’accès cohérents à l’ensemble des systèmes pilotés par l’IA.