OpenClaw fait l’objet d’un examen après que des chercheurs de Zenity ont montré comment il pouvait être détourné pour établir un accès persistant.
Plutôt que d’exploiter une vulnérabilité logicielle, la technique repose sur une injection indirecte de prompts pour influencer le comportement de l’agent et maintenir un contrôle permanent avec une intervention minimale de l’utilisateur.
« Cette attaque montre comment un canal persistant de commande et de contrôle peut être créé à des fins malveillantes en utilisant les fonctions et capacités natives d’OpenClaw », a déclaré Chris Hughes, vice-président de la stratégie de sécurité chez Zenity, dans un e-mail adressé à eSecurityPlanet.
Il a ajouté : « C’est un nouvel exemple du vecteur d’attaque non résolu que constitue l’injection indirecte de prompts. À mesure que l’adoption d’OpenClaw gagne les environnements d’entreprise, les répercussions et les risques s’étendent bien au-delà du point d’entrée initial. »
Chris a expliqué : « L’agent devient une voie d’accès aux systèmes, aux données et aux environnements auxquels il est autorisé à accéder. Cela souligne la nécessité de disposer de capacités complètes de visibilité, de gouvernance, ainsi que de détection et de réponse pour les agents en entreprise, alors que leur adoption continue de progresser plus vite que la sécurité. »
À l’intérieur de l’attaque par porte dérobée d’OpenClaw
OpenClaw est conçu pour fonctionner en continu sur une infrastructure contrôlée par l’utilisateur et s’intégrer directement aux plateformes de chat, aux outils de productivité et aux sources de données externes.
Cette architecture permet une automatisation puissante, mais elle introduit également des risques lorsque l’agent est déployé dans des environnements d’entreprise.
En pratique, OpenClaw dispose souvent d’un accès aux systèmes de messagerie internes, aux documents partagés, aux calendriers et au système de fichiers local, le tout selon les autorisations accordées lors de la configuration initiale.
Comment les entrées non fiables influencent le comportement de l’agent
Le problème fondamental tient à la manière dont OpenClaw traite les entrées non fiables. Dans le cadre de l’exécution normale des tâches, l’agent ingère régulièrement du contenu provenant de chats, de compétences, de documents, de l’accès au navigateur et de services externes.
Cependant, il n’impose pas de séparation stricte entre l’intention explicite de l’utilisateur et le contenu de tiers.
Les informations récupérées lors de l’exécution d’une tâche sont traitées dans le même contexte conversationnel et de raisonnement que les instructions directes de l’utilisateur, ce qui permet aux entrées non fiables d’influencer la prise de décision de l’agent.
L’injection indirecte de prompts comme point d’entrée initial
Ce choix de conception permet l’injection indirecte de prompts, dans laquelle des instructions contrôlées par un attaquant sont intégrées à un contenu par ailleurs inoffensif.
Lorsque OpenClaw traite ce contenu dans le cadre d’une tâche légitime, les instructions injectées influencent subtilement la manière dont l’agent interprète ce qu’il doit faire ensuite, sans nécessiter d’interaction directe de la part de l’utilisateur.
Établissement d’une porte dérobée persistante
Dans un scénario d’entreprise, un employé déploie OpenClaw sur un poste de travail et le connecte à Slack et Google Workspace pour faciliter les tâches quotidiennes de productivité.
Un attaquant introduit ensuite des instructions malveillantes par l’intermédiaire d’un document partagé, d’un e-mail ou d’un message de chat.
Lorsqu’OpenClaw traite ce contenu, il est orienté vers une modification de configuration — plus précisément, l’ajout d’une nouvelle intégration de chat contrôlée par l’attaquant, par exemple un bot Telegram.
Une fois cette intégration créée, l’attaquant n’a plus besoin d’accéder à la plateforme d’entreprise d’origine.
OpenClaw considère le nouveau canal de chat comme légitime et commence à y accepter des instructions.
Cette transition s’effectue discrètement, sans alerte ni intervention des systèmes de contrôle de l’entreprise, ce qui aboutit à un canal de contrôle externe persistant.
Une fois la porte dérobée établie, les attaquants peuvent détourner directement OpenClaw pour exécuter des commandes, énumérer les fichiers, exfiltrer des données ou supprimer du contenu, en utilisant les mêmes autorisations que celles accordées par l’utilisateur.
Persistance via la mémoire de l’agent et les tâches planifiées
OpenClaw conserve un fichier de contexte persistant, SOUL.md, qui définit l’identité et les limites comportementales de l’agent et est injecté dans chaque interaction.
Les chercheurs ont démontré que des attaquants pouvaient modifier ce fichier afin d’introduire des changements comportementaux à long terme.
Dans leur preuve de concept, OpenClaw a reçu l’instruction de créer sur le système hôte une tâche planifiée qui réinjecte périodiquement une logique contrôlée par l’attaquant dans SOUL.md.
Ce mécanisme crée un écouteur durable qui survit aux redémarrages et persiste même si l’intégration de chat d’origine est supprimée.
À ce stade, l’influence de l’attaquant dépasse le cadre d’une interaction unique et devient un mécanisme de contrôle permanent intégré au fonctionnement de l’agent.
Du contrôle de l’agent à la compromission complète du système
À partir de là, la compromission peut être poussée plus loin.
Puisqu’OpenClaw est capable de télécharger et d’exécuter des fichiers, les attaquants peuvent l’utiliser pour déployer un implant traditionnel de commande et de contrôle (C2), passant d’une manipulation au niveau de l’agent à une compromission complète du système.
Pourquoi cette attaque est difficile à contrer
Il est important de noter que cette attaque ne repose ni sur un CVE, ni sur une bibliothèque vulnérable, ni sur un modèle particulier.
Elle détourne les fonctions normales et documentées d’OpenClaw : autonomie, mémoire persistante, intégrations externes et exécution avec privilèges.
La modification du modèle sous-jacent ou de la source des entrées ne change pas sensiblement le résultat.
Rien n’indique actuellement que ce comportement soit exploité dans la nature.
Comment réduire les risques liés aux agents d’IA
Comme ce risque découle de la conception de l’agent plutôt que d’une vulnérabilité corrigeable, réduire l’exposition nécessite une combinaison de mesures de protection architecturales et de contrôles opérationnels.
Les mesures suivantes visent à limiter l’influence des entrées non fiables sur le comportement des agents, à restreindre ce qu’ils sont autorisés à faire et à améliorer la visibilité sur leurs actions.
- Traitez tout contenu externe comme une entrée non fiable et imposez une séparation stricte entre le raisonnement, la configuration et l’exécution de l’agent.
- Limitez les autorisations des agents autonomes en restreignant l’accès au système de fichiers, l’exécution de commandes et l’accès aux intégrations sensibles.
- Exigez une approbation explicite pour l’ajout ou la modification des intégrations de l’agent ainsi que pour toute modification persistante de la configuration ou du contexte.
- Protégez la configuration centrale de l’agent et les fichiers de mémoire contre toute modification à l’exécution au moyen de mécanismes d’immuabilité ou de contrôles administratifs.
- Surveillez et auditez le comportement des agents pour détecter les intégrations inattendues, les tâches planifiées, les dérives de configuration ou les actions anormales.
- Limitez les environnements d’exécution des agents au moyen de bacs à sable, de conteneurs ou de comptes de système d’exploitation restreints afin de réduire l’impact au niveau de l’hôte.
- Conservez des journaux détaillés et testez régulièrement les plans de réponse aux incidents qui tiennent compte des scénarios de détournement et de persistance des agents d’IA.
Ces mesures contribuent à réduire la probabilité d’un détournement réussi et à renforcer la préparation en cas de mauvaise utilisation d’un agent.
Le défi de la sécurité des agents d’IA
Cette étude met en lumière un défi croissant en matière de sécurité, alors que les agents d’IA autonomes s’intègrent davantage aux flux de travail des entreprises et accèdent à des systèmes et données sensibles.
Lorsque les agents sont autorisés à ingérer en continu des entrées non fiables tout en conservant la capacité d’effectuer des modifications persistantes et d’exécuter des actions, les hypothèses traditionnelles de sécurité ne tiennent plus.
Pour faire face à ce risque, il faut passer d’une approche centrée sur les vulnérabilités à une approche qui met l’accent sur des limites imposées, le moindre privilège et une visibilité continue sur le comportement des agents.
Ces mêmes principes sont étroitement alignés sur les solutions zero trust qui éliminent la confiance implicite et vérifient en permanence les accès et les comportements.