Lorsque l’IA peut agir : maîtriser OpenClaw

L’IA agentique a fait irruption dans la conscience collective cette semaine avec l’annonce de Moltbook, un réseau social conçu pour les agents IA basé sur OpenClaw (anciennement Clawdbot et Moltbot). Les conversations qui en ont résulté sur l’identité, la fondation d’une nouvelle religion, l’ingénierie sociale des humains et bien d’autres sujets entre robots ont déclenché de nombreuses inquiétudes.

Pour les responsables informatiques, une chose est claire : l’IA a franchi un cap important. Les outils tels qu’OpenClaw ne se limitent plus à générer des réponses ou des recommandations : ils sont conçus pour agir sur des systèmes réels, avec des autorisations réelles et des conséquences réelles. Ce passage du conseil à l’exécution a suscité un débat public plus large sur l’autonomie, l’intention et même les capacités d’action des machines.

Lorsque les assistants peuvent agir, il est impératif de les gouverner, car toute exécution, contrôle et application sans visibilité est un risque non géré. Ce qui rend OpenClaw digne d’intérêt, ce n’est pas sa nouveauté, mais la façon dont il expose clairement les hypothèses de sécurité qui ne sont plus valables dès lors que les systèmes d’IA peuvent agir de manière autonome.

Qu’est-ce qui change lorsqu’un assistant peut agir ?

OpenClaw appartient à une nouvelle catégorie d’assistants qui se comportent plus comme des couches d’exécution automatisées que comme des chatbots. Contrairement aux outils d’IA traditionnels qui génèrent des recommandations ou du texte, ces agents peuvent utiliser des outils, accéder à des systèmes et effectuer des actions au nom de l’utilisateur, souvent avec une mémoire persistante et des autorisations héritées.

Concrètement, cela signifie que les pratiques courantes dans des domaines tels que les opérations financières, les services informatiques, les ressources humaines, les achats et la sécurité peuvent être lancées et menées à bien directement à partir d’une interface de chat, sans qu’un humain n’ait besoin d’intervenir directement sur les systèmes concernés.

Le changement essentiel ne concerne pas la productivité, mais l’autorité. Il ne s’agit pas de workflows « de contenu ». Ce sont des workflows de décision et d’exécution qui touchent à des systèmes réels, des données réelles et des autorisations réelles. Un simple prompt peut déclencher l’accès à des fichiers, des appels d’API, l’envoi de messages à des tiers ou des modifications de l’état de l’infrastructure. Dès lors qu’un assistant peut agir avec un tel niveau d’autonomie, les hypothèses traditionnelles en matière de sécurité n’ont plus lieu d’être. La gouvernance ne peut plus être une réflexion après coup, car un simple prompt sur un chat peut désormais se traduire directement par des actions ayant un impact à l’échelle de l’entreprise.

Fonctionnement d’OpenClaw : agents orchestrés par une passerelle et réalité de l’installation locale

Pour comprendre pourquoi OpenClaw modifie le modèle de sécurité de l’entreprise, il est utile de comprendre la forme du système.

À un niveau élevé :

1. Les canaux entrants transmettent les demandes des utilisateurs via des plateformes de chat et de messagerie, souvent en dehors des limites traditionnelles des applications d’entreprise.
2. Un service de passerelle central reçoit ces demandes, maintient le contexte de la session et détermine quels outils et quelles intégrations invoquer.
3. La passerelle exécute des actions via l’accès à l’hôte local et les API connectées héritant des autorisations de l’utilisateur, de l’hôte et des intégrations configurées.
4. L’utilisateur prend connaissance des résultats sur le chat, même après plusieurs actions privilégiées réalisées en arrière-plan.

C’est là que l’« installation locale » revêt une importance stratégique. Lorsque la passerelle est exécutée localement, ont réduit certaines dépendances, mais cela permet également de placer toutes les ressources critiques directement sur les terminaux ou les serveurs internes : le service d’exécution persistant, les fichiers de configuration, les logs, les jetons, les décisions d’exposition… Pour l’entreprise, cela introduit un nouveau plan de contrôle souvent invisible dans l’environnement : un plan qui fonctionne en dehors des processus traditionnels d’approvisionnement, de gouvernance des identités et d’examen de la sécurité.

La passerelle démultiplie le rayon d’action

Dans les systèmes d’agents, la passerelle devient le point d’étranglement décisif. Elle négocie les demandes, achemine l’exécution et détient souvent les mêmes secrets et intégrations que ceux sur lesquels s’appuie l’agent. Du point de vue du réseau et de l’exposition, les schémas sont familiers, mais l’impact est amplifié, car la passerelle peut diriger un acteur automatisé qui hérite d’autorisations réelles. Lorsque cette passerelle est mal configurée, exposée ou compromise, le risque ne se limite plus à un seul service en raison de divers facteurs :

• Accessibilité involontaire : une passerelle qui devient accessible en dehors de ses limites prévues devient un point de faiblesse pouvant être ciblé à distance, et non plus seulement un service exposé.
• Faiblesse des portails d’accès : une utilisation incohérente des données d’identification, des jetons partagés ou un changement insuffisamment fréquent peuvent transformer l’« accessibilité » en « contrôlabilité » totale.
• Bruit de découverte : les comportements de découverte LAN (tels que mDNS) peuvent signaler toute présence indésirable et fournir des indications sur l’environnement à toute personne ayant une visibilité sur le réseau local.
• Nuance du canal de contrôle : les connexions interactives de longue durée (WebSockets) associées aux API HTTP augmentent le risque de problèmes de configuration, rendant indispensables l’utilisation d’un proxy inverse, la gestion des en-têtes de confiance et les listes d’autorisation strictes.

Conseils de sécurité du projet OpenClaw et pourquoi cela ne suffit pas pour les entreprises.

La documentation du projet OpenClaw présente des conseils pour renforcer la sécurité. Bien que ces recommandations soient judicieuses, elles soulignent également un problème fondamental : la sûreté du fonctionnement implique une configuration rigoureuse et une hygiène de sécurité continue au niveau de chaque déploiement.

Voici quelques-unes des recommandations les plus pertinentes pour les entreprises :

• Limitez l’exposition par défaut : si la passerelle n’a pas besoin d’être accessible au-delà de l’hôte, évitez d’étendre sa surface d’écoute pour de simples raisons de commodité.
• Considérez l’authentification comme obligatoire : imposez des identifiants forts et leur changement fréquent, et évitez les configurations qui font implicitement confiance à des composants en amont que vous ne contrôlez pas entièrement.
• Réduisez la découverte autant que possible : si la découverte du réseau n’est pas nécessaire pour votre déploiement, désactivez-la ou réduisez-la au minimum.
• Traitez les logs comme des données sensibles : les transcriptions des agents et les sorties des outils peuvent devenir une archive parallèle de secrets et de contexte opérationnel, alors appliquez des contrôles d’accès et de conservation avec le moins de privilèges possible.

Le défi réside dans le fait que même si tous les utilisateurs suivent ces recommandations, les entreprises manqueront toujours de visibilité, d’application cohérente des politiques et d’assurance à grande échelle. Les conseils de renforcement ne remplacent pas la gouvernance centralisée.

Risques liés à la sécurité de l’IA : infiltration de requête, utilisation abusive d’outils et détournement des autorisations

Avec l’arrivée des assistants IA, le mode de défaillance passe de « Le modèle a dit quelque chose de faux » à « Le modèle est convaincu de faire quelque chose de faux ».

Dans un assistant connecté à un outil, l’infiltration de requête peut devenir un mécanisme qui pousse l’agent à :

• Accéder à et extraire des données auxquelles il ne devrait pas toucher.
• Exfiltrer des informations vers des destinations non prévues.
• Exécuter des actions qui semblent légitimes, car elles suivent des workflows approuvés.

Le point crucial est l’héritage des autorisations. L’agent peut agir grâce aux privilèges qu’il a hérité de l’utilisateur, de l’hôte et de tous les systèmes connectés. Cela signifie que le rayon d’action dépend de ce que l’agent peut atteindre, y compris les boîtes mail, les systèmes de fichiers, les navigateurs, les jetons API et les tableaux de bord internes.

Les entreprises doivent partir du principe que tout assistant exposé à du contenu externe finira par ingérer des instructions malveillantes, qu’elles soient ciblées ou opportunistes, et que ces instructions seront transmises par des chemins d’exécution par ailleurs légitimes.

Quand « Ajouter une compétence » devient une décision de confiance

Les assistants IA restent rarement statiques. Une fois que les utilisateurs ont ajouté des compétences, des plugins ou des extensions, l’organisation n’évalue plus un seul outil. Elle hérite d’une logique tierce capable d’influencer ce que l’agent exécute, ce à quoi il peut accéder et son comportement au fil du temps.

C’est là que les risques familiers liés à la chaîne d’approvisionnement refont surface sous une forme plus dangereuse. On se base souvent sur la popularité pour valider un nouvel outil, les add-ons se comportent de manière difficile à prévoir tant qu’ils ne sont pas exécutés et des intégrations apparemment mineures accumulent progressivement des autorisations étendues. Dans un système agentique, ces autorisations sont exercées de manière autonome et par le biais de workflows par ailleurs légitimes.

Les extensions similaires ou chevaux de Troie ajoutent une couche de risque supplémentaire, exploitant la notoriété du nom et la confiance des utilisateurs pour s’exécuter dans l’environnement. La réponse de l’entreprise reflète les leçons durement apprises avec les progiciels et les extensions de navigateur : maintenir l’inventaire, autoriser les composants approuvés, vérifier la provenance et appliquer la politique de manière cohérente.

Vague de chevaux de Troie : faux outils OpenClaw/Clawdbot et diffusion de chevaux de Troie

Chaque fois qu’un outil gagne rapidement en popularité, il fait l’objet d’usurpations d’identité. Les attaquants n’ont pas besoin de compromettre le produit s’ils peuvent distribuer leur propre version et si elle ressemble suffisamment à l’original pour que des utilisateurs l’installent.

C’est justement ce schéma qui se dessine autour d’OpenClaw. Des imitations type cheval de Troie et de fausses extensions exploitent la notoriété de la marque et la curiosité des utilisateurs, renonçant dans certains cas aux outils de surveillance et de gestion à distance ou installant inconsciemment des trojans permettant de contrôler directement le terminal. Cela transforme le défi consistant à gérer un assistant légitime en celui de contenir également un canal de diffusion de logiciels malveillants opportuniste.

Un bon exemple est la fausse extension Clawdbot VS Code signalée en début d’année. Une dynamique similaire a été observée dans l’écosystème OpenClaw plus large, où l’ingénierie sociale a été utilisée pour pousser l’installation de composants en les faisant passer comme indispensables. Dans ces cas, l’agent lui-même devient un vecteur de distribution plutôt que la vulnérabilité principale.

Pour les équipes chargées de la sécurité, le champ du problème se retrouve élargi. Les contrôles doivent distinguer les empreintes d’applications légitimes des variantes suspectes et détecter les signaux en aval tels que les communications sortantes inattendues, les comportements de contrôle à distance et les chaînes d’exécution inhabituelles, et pas seulement une utilisation abusive de l’outil.

Au cœur des intégrations tierces d’OpenClaw : premiers signaux issus de la visibilité SASE

D’après les observations actuelles dans les environnements Cato Networks, l’adoption d’OpenClaw reste limitée à un petit nombre de comptes, mais elle augmente progressivement. Bien que ces données ne reflètent qu’une partie des activités des entreprises, elles fournissent des signaux précurseurs sur la manière dont les assistants IA commencent à s’imposer et dans quels domaines. L’intégration tierce la plus courante observée parallèlement à l’utilisation d’OpenClaw est Google Workspace, suivie de GitHub, X (Twitter) et d’un groupe associé aux opérations médiatiques et publicitaires telles que Chartbeat, TripleLift et AdSafe.

Ces modèles d’intégration donnent un aperçu des premiers cas d’utilisation. La prévalence de Google Workspace suggère une adoption ancrée dans les flux quotidiens liés à la productivité, tels que les e-mails, le calendrier et la coordination basée sur des documents. GitHub indique que les équipes d’ingénieurs logiciels font des expérimentations. La présence de Chartbeat, TripleLift et AdSafe suggère une adoption plus vaste dans les environnements médiatiques et publicitaires.

Une nuance importante est à noter entre l’étendue et l’intensité. Google Workspace apparaît sur un plus grand nombre de comptes, tandis que Chartbeat est observé dans moins d’environnements, mais avec une utilisation plus intensive. Ce modèle indique qu’un petit groupe d’utilisateurs expérimentés automatisent des boucles opérationnelles répétitives plutôt qu’un déploiement à grande échelle au sein de l’organisation.

La figure 1 illustre la répartition en pourcentage de l’activité réseau liée à OpenClaw par intégration, sur la base des observations effectuées jusqu’au 1er février 2026.

Figure 1 : Empreinte de l’intégration sur les comptes ayant adopté OpenClaw (au 1er février 2026)

Gouverner OpenClaw dans l’entreprise : voir, contrôler, bloquer

OpenClaw met en évidence une catégorie de risques qui affectent les utilisateurs, les appareils, les réseaux et les applications. Son adoption concerne tous les utilisateurs et tous les sites, tandis que son impact touche l’utilisation des applications, l’exposition du réseau et le transfert de données. Cette combinaison doit obliger les équipes informatiques à avoir une visibilité centralisée et à appliquer des politiques de sécurité.

Une approche efficace en matière de gouvernance repose sur trois principes fondamentaux :

• Voir : les organisations doivent avoir une visibilité sur l’IA fantôme, notamment sur les utilisateurs qui exécutent des assistants IA, depuis quel endroit et avec quels modèles comportementaux. Sans cette base de référence, les décisions politiques relèvent de la conjecture.
• Contrôler : les équipes de sécurité doivent pouvoir autoriser OpenClaw uniquement dans le cadre de projets pilotes très strictement contrôlés et limités. Elles doivent pouvoir restreindre l’utilisation en fonction de la posture ou du contexte de l’appareil, ou refuser tout accès. Dans de nombreux cas, le contrôle le plus simple, à savoir bloquer toute utilisation non contrôlée, permet de réduire les risques le plus rapidement.
• Bloquer : lorsque des installateurs similaires, des extensions trojanisées ou des composants compromis commencent à communiquer vers l’extérieur, les protections au niveau de la couche réseau peuvent mettre en évidence des modèles de commande et de contrôle suspects et des comportements d’exécution anormaux.

Dans la pratique, cela signifie également qu’il faut traiter les assistants IA comme des applications identifiables, et non comme des outils locaux opaques. Si les équipes informatiques peuvent les reconnaître et les contrôler de manière cohérente dans toute l’organisation, elles n’auront plus à choisir entre expérimentation incontrôlée et interdiction générale.

Faire progresser la recherche sur les menaces liées à l’IA

Pour comprendre et atténuer les risques liés à l’IA agentielle, il ne suffit pas de recourir à l’analyse traditionnelle de la sécurité des applications ou des réseaux. Il faut mener des recherches ciblées sur la manière dont l’injection rapide, l’exfiltration de données et l’utilisation frauduleuse des agents autonomes se manifestent réellement dans des environnements réels.

Il s’agit d’un domaine dans lequel Cato Networks investit activement. L’intégration d’Aim Security en 2025 élargit les capacités de Cato Networks pour recherche les menaces natives de l’IA, complétant la visibilité et l’application basées sur le SASE par une connaissance plus approfondie du comportement des agents, des chemins d’exécution et des nouveaux modèles abusifs. Ces travaux alimentent le développement continu de capacités d’inspection et de politiques tenant compte de l’IA, conçues pour les réalités décrites dans ce blog.

Un guide pratique pour la gouvernance d’OpenClaw

OpenClaw est un indicateur utile de l’orientation que prend le monde du travail : des assistants toujours disponibles, connectés à des outils et capables d’agir. Cette même capacité transforme cependant l’IA agentielle en un défi concernant la sécurité et la gouvernance, car la couche d’exécution est réelle et le rayon d’action n’est pas théorique.

Il est essentiel que la gouvernance d’entreprise soit réfléchie, qu’elle combine visibilité, contrôle et protection multicouche, tout en tenant compte à la fois des outils légitimes et de la présence inévitable des imitateurs.