Microsoft : ne lancez pas OpenClaw sur des ordinateurs professionnels ordinaires

Le 19 février 2026, le Microsoft Defender Security Research Team a publié un article intitulé « Running OpenClaw safely: identity, isolation, and runtime risk », dans lequel il formule une recommandation que l'Orca AI Incident Archive n'associe à aucune autre entrée : OpenClaw « doit être traité comme une exécution de code non fiable avec des identifiants persistants » et « Il n'est pas approprié de l'exécuter sur un poste de travail personnel ou d'entreprise standard. » OpenClaw est un environnement d'exécution d'agents auto-hébergé — l'utilisateur l'installe sur sa propre machine, lui accorde des comptes et des jetons, et le laisse installer des compétences depuis un registre public et agir sur du texte qu'il lit n'importe où. L'argument de Microsoft est architectural, et non un rapport de bogue : l'environnement d'exécution déplace le point d'exécution du code applicatif statique vers du contenu fourni au moment de l'exécution, et les contrôles autour de l'identité, du traitement des entrées et des privilèges ne se sont pas déplacés avec lui. L'article ne nomme aucun CVE, aucune campagne ni aucune victime, et ne consigne aucune compromission. Le dossier complet se trouve dans le Orca AI Incident Archive, où il est classé comme entrée de politique de référence avec un grade de confiance A et aucun préjudice réel enregistré.

Ce que le post disait, et ce qu'il ne disait pas

La publication demande environ douze minutes de lecture et ne comporte absolument aucun mécanisme de divulgation : aucun identifiant CVE, aucune plage de versions affectées, aucun build corrigé, aucun indicateur de compromission lié à un déploiement réel. Microsoft Defender Security Research cite Idan Hen parmi les contributeurs. Ce qu’elle contient en revanche, c’est un modèle de menace et une règle de déploiement, ce qui explique pourquoi l’archive la classe comme un dossier de politique plutôt que comme un incident — des informations de gravité, une note de confiance A, aucun préjudice réel consigné, une date précise au jour près.

Le raisonnement est condensé en un paragraphe d’ouverture. OpenClaw « inclut des contrôles de sécurité intégrés limités », écrivent l’équipe, car le runtime « peut ingérer du texte non fiable, télécharger et exécuter des compétences (c’est-à-dire du code) depuis des sources externes, et effectuer des actions à l’aide des identifiants qui lui sont attribués ». La conséquence est énoncée dans la foulée : cela « déplace effectivement la frontière d’exécution du code applicatif statique vers du contenu fourni dynamiquement et des capacités tierces, sans contrôles équivalents autour de l’identité, du traitement des entrées ou du cadrage des privilèges ».

Trois risques suivent, et ils méritent d’être lus dans les mots mêmes de Microsoft, car l’essentiel de la couverture médiatique qui a suivi les a paraphrasés jusqu’à les rendre vagues :

• « Les identifiants et les données accessibles peuvent être exposés ou exfiltrés. »

• « L'état persistant ou la "mémoire" de l'agent peut être modifié, ce qui l'amène à suivre au fil du temps des instructions fournies par l'attaquant. »

• « L'environnement hôte peut être compromis si l'agent est amené à récupérer et exécuter du code malveillant. »

Notez ce qui est absent de cette liste. Il n’y a aucune faille exploitée, aucune fonction vulnérable, aucun correctif à déployer. Microsoft ne dit pas qu’OpenClaw a un bogue de sécurité ; il dit qu’un programme qui décide de ce qu’il faut faire au moment de l’exécution, à partir de texte qu’il a récupéré, en utilisant des identifiants qui lui ont été fournis, ne peut pas être sécurisé par la configuration sur une machine qui contient également le véritable travail de l’opérateur. La recommandation qui en découle est tout aussi directe — pour la plupart des environnements, « la décision appropriée peut être de ne pas le déployer ».

Deux chaînes d’approvisionnement, une seule boucle d’exécution

Le mécanisme décrit dans l’article est la convergence de ce qu’il appelle les deux chaînes d’approvisionnement d’un agent auto-hébergé : le code non fiable, c’est-à-dire les compétences et les extensions, et les instructions non fiables, c’est-à-dire le texte externe. La plupart des logiciels ont l’une ou l’autre. Un gestionnaire de paquets récupère du code non fiable, mais ne lit pas Internet et ne décide pas de ce qu’il faut exécuter ensuite ; un modèle de discussion lit du texte non fiable, mais ne peut rien installer. OpenClaw fait les deux dans une seule boucle, et cette boucle s’exécute sous l’identité de l’utilisateur lui-même.

« Installer une compétence revient essentiellement à installer du code privilégié », indique le post. Les compétences sont « souvent découvertes et installées via ClawHub, le registre public de compétences pour OpenClaw », et, dans les déploiements permissifs, « l’environnement d’exécution peut être autorisé à exécuter le processus d’installation sans approbation humaine ». La deuxième chaîne d’approvisionnement est gérée par Moltbook, que le post décrit comme une plateforme et une couche d’identité centrées sur les agents, où les agents publient, lisent et s’authentifient via des API — et donc, selon sa formulation, « un flux à haut volume de contenu influençable par les attaquants que les agents ingèrent selon un calendrier ». La compression est tout l’enjeu : « Une seule publication malveillante peut donc atteindre plusieurs agents. »

L'article divise ensuite la frontière de confiance en trois composantes, qui constituent la partie la plus réutilisable de tout le document : l'identité, c'est-à-dire les jetons que l'agent utilise pour agir via les API SaaS, les dépôts, la messagerie et les plans de contrôle cloud ; l'exécution, c'est-à-dire les outils qu'il peut lancer et qui modifient l'état, notamment les fichiers, le shell, l'infrastructure et les messages ; et la persistance, c'est-à-dire les manières dont il peut conserver des modifications entre les exécutions, au moyen de tâches, de configuration et de planifications. Un agent qui possède les trois n'est pas une application dotée d'une invite d'autorisation. C'est un principal.

La compétence empoisonnée, en cinq étapes

Microsoft fournit une chaîne de compromission concrète, présentée comme un scénario représentatif plutôt que comme un rapport de cas, et il vaut la peine de la parcourir, car ses deux dernières étapes sont celles qui déjouent les défenses ordinaires des points de terminaison. L’article la fait précéder d’une affirmation sur le monde extérieur — « Des rapports publics ont documenté l’apparition de compétences malveillantes dans des registres publics », et, dans certains cas, « le contenu du registre était un logiciel malveillant pur et simple empaqueté comme une compétence, plutôt qu’une subtile imitation » — mais ne nomme aucune entrée de registre, campagne, acteur ou victime, si bien que la chaîne se présente comme un argument de plausibilité, et non comme une reconstruction.

• Distribution. Un attaquant publie une compétence malveillante sur ClawHub, parfois déguisée en utilitaire et parfois ouvertement malveillante, et la promeut via les canaux communautaires ; d'autres fois, elle est découverte naturellement via la recherche et installée parce que l'installation est peu contraignante.

• Installation. Un développeur ou l’agent lui-même lance l’installation parce que la compétence semble pertinente pour la tâche. Dans un déploiement permissif, aucun humain ne l’approuve.

• Accès à l’état. L’attaquant cible les jetons, les identifiants mis en cache, les données de configuration et les transcriptions, ainsi que les canaux d’instructions durables — fichiers de tâches, actions planifiées, configuration de l’agent — qui orientent les exécutions futures.

• Réutilisation de privilèges. Disposant d'éléments d'identité valides, l'attaquant agit via des API et des outils standards, et son activité « ressemble souvent à une automatisation légitime, sauf si des contrôles robustes de supervision et de journalisation sont en place ».

• Persistance par la configuration. Ce qui reste, ce sont des modifications durables de la configuration : « nouveaux consentements OAuth, exécutions planifiées, tâches d’agent modifiées ou outils restant approuvés en permanence. »

La cinquième étape contient la phrase la plus incisive du billet, et celle qui explique le mieux pourquoi il s’agit d’un problème de politique plutôt que d’un problème de logiciel malveillant : « L’objectif consiste moins à déployer des logiciels malveillants qu’à maintenir un contrôle à long terme sur le chemin d’automatisation. » Les outils de sécurité qui recherchent une charge utile ne trouveront rien. Ce qu’ils devraient détecter, c’est une autorisation de consentement, une entrée cron ou un outil qui a été discrètement laissé approuvé.

La posture minimale que Microsoft acceptera

Microsoft ne laisse pas le lecteur sur un simple « ne le faites pas ». Il fournit un socle minimal aux organisations qui décident malgré tout d’évaluer l’environnement d’exécution, et ce socle est plus strict qu’un bac à sable. L’environnement doit être « une machine virtuelle dédiée ou un appareil physique séparé qui n’est pas utilisé pour le travail quotidien », et il doit être considéré comme jetable. Les identifiants doivent être créés uniquement pour l’usage de l’agent, sans privilèges, et renouvelés en partant du principe qu’ils sont déjà compromis. Seules des données non sensibles doivent être accessibles. Les instructions et l’état enregistrés de l’agent doivent être examinés régulièrement afin de détecter des règles persistantes inattendues, des sources nouvellement approuvées ou un comportement qui change d’une exécution à l’autre. Et une reconstruction doit être un contrôle attendu plutôt qu’une urgence : réinstallez régulièrement et reconstruisez immédiatement en cas de comportement anormal.

Un détail dans l'article est plus utile que sa longueur ne le suggère. La sauvegarde de .openclaw/workspace/ capture l'état de travail de l'agent sans inclure d'identifiants ; sauvegarder l'intégralité du .openclaw/ répertoire est plus simple à restaurer mais capture aussi les jetons et identifiants, et l'article avertit que cela peut être inapproprié si l'on soupçonne que les identifiants ont été compromis. Une équipe qui sauvegarde tout le répertoire et appelle cela reprise après sinistre a archivé ce que l'attaquant voulait.

Les orientations constituent également une carte produit.

La seconde moitié de l’article associe chaque contrôle recommandé à un produit Microsoft : Microsoft Entra ID pour le moindre privilège et l’accès conditionnel sur les identités d’agent, Microsoft Defender for Cloud Apps App Governance pour l’inventaire OAuth et la dérive des consentements, Microsoft Defender for Endpoint pour l’hôte de l’agent, Microsoft Defender XDR pour la corrélation, Microsoft Purview pour la prévention des pertes de données sur les points de terminaison, Microsoft Defender for Cloud pour la sortie réseau, et Microsoft Sentinel lorsqu’une rétention plus longue ou de l’automatisation est nécessaire. C’est une pratique courante pour un blog de sécurité d’un fournisseur, et il vaut aussi la peine de le dire clairement : le document qui recommande de confiner un environnement d’exécution d’agent tiers est publié par une entreprise qui vend ce confinement.

Le contenu de chasse aux menaces est la partie qui survit à ce cadrage, parce qu’il est spécifique. L’article fournit des requêtes KQL sur les tables de Defender XDR — DeviceProcessEvents, CloudProcessEvents, DeviceFileEvents, DeviceNetworkEvents et OAuthAppInfo — qui recherchent des lignes de commande de processus et des noms de fichiers contenant « openclaw », « moltbot » ou « clawdbot », des invocations de clawhub install avec des slugs de compétences rares, des modifications répétées des dossiers d’extensions sur les points de terminaison des développeurs, de nouvelles applications OAuth à privilèges élevés, des services en écoute ouverts par des processus d’agent, et des runtimes d’agent qui lancent cmd.exe, powershell.exe, pwsh.exe, bash, sh, curl ou wget. Quoi que l’on pense du mappage produit, ces requêtes peuvent être exécutées par tout client de Defender XDR le jour de la publication, et elles ne supposent aucune connaissance préalable des hôtes qui exécutent le runtime.

Ce qui est établi, et ce qui ne l’est pas

Établi et corroboré : Microsoft a publié l’article le 19 février 2026, et les citations ci-dessus en sont issues. Cybernews a rapporté l’avertissement le 23 février 2026 et TechRadar le 24 février 2026, tous deux reprenant les deux phrases centrales et les consignes d’isolement plutôt que de les tester. Des recherches répétées n’ont pas fait apparaître de couverture dans The Register, BleepingComputer, Wired ou TechCrunch, de sorte que la vague médiatique autour de cet article a été faible et dérivée ; aucune partie indépendante n’a publié de test de l’affirmation architecturale de Microsoft, et la corroboration disponible confirme ce que Microsoft a dit, non si c’est exact.

Le relais a également introduit une erreur qu'il vaut la peine de signaler, car elle montre avec quelle rapidité un avertissement de fournisseur concernant un outil tiers devient un avertissement du fournisseur concernant son propre outil. Le rapport de Cybernews commence par décrire OpenClaw comme « l'assistant IA de Microsoft » ; ce n'est pas le cas. OpenClaw est un environnement d'exécution auto-hébergé que les chercheurs de Microsoft Defender ont examiné, et l'article lui-même établit la distinction de manière structurelle, en opposant les environnements d'exécution auto-hébergés — où « vous êtes responsable du rayon d'impact » et où l'hôte, les plug-ins et l'état local se situent tous à l'intérieur du périmètre de confiance — aux assistants gérés et aux plateformes d'agents, où l'environnement d'exécution et les mises à jour sont gérés de façon centralisée et où les contrôles se concentrent sur les périmètres d'identité, la gouvernance des connecteurs et les frontières de données.

Non établi : qu’une organisation spécifique ait été compromise de la manière décrite dans la publication. Microsoft affirme que des rapports publics ont documenté des compétences malveillantes dans des registres publics, mais la publication ne mentionne ni nom de campagne, ni nombre, ni date, ni victime, et ce dossier ne fait donc état d’aucun préjudice réel. La recommandation n’est pas non plus contraignante. Aucun régulateur ne l’a émise, aucun organisme de normalisation ne l’a adoptée, et rien dans le dossier ne montre qu’un client, un auditeur ou un assureur la traite comme une exigence. Il s’agit de l’opinion d’un fournisseur sur la manière dont ses propres clients devraient traiter un outil qu’il ne contrôle pas — d’une affirmation inhabituellement catégorique et inapplicable.

Ce que l’article change bel et bien, c’est la forme de la question à laquelle une équipe de sécurité doit répondre. Avant le 19 février 2026, la décision d’exécuter OpenClaw sur un ordinateur portable professionnel pouvait être présentée comme une question de configuration et d’approbation de projet pilote. Après cette date, il faut désormais argumenter contre un document qui affirme que c’est la conception même de l’environnement d’exécution, et non ses paramètres, qui met la machine en danger — et qui n’offre aucune version vers laquelle effectuer une mise à niveau, aucun correctif à appliquer et aucune correction prévue dans la feuille de route. Son remède est un modèle de déploiement : isoler l’environnement d’exécution, limiter ce à quoi il peut accéder, le surveiller en continu et être prêt à le reconstruire sans délai.