Récemment, la plateforme open source d'agents IA auto-hébergés OpenClaw (surnommée «小龙虾» dans le milieu) a connu un essor rapide grâce à sa flexibilité et à ses caractéristiques de déploiement autonome, devenant un produit phare dans le domaine des agents IA personnels. Son écosystème central, Clawhub, qui sert de marché d'applications, regroupe un grand nombre de compétences (Skill) tierces, permettant aux agents de débloquer d'un simple clic des capacités avancées allant de la recherche web et la création de contenu, à la manipulation de portefeuilles cryptographiques, aux interactions on-chain et à l'automatisation système, entraînant une croissance explosive de l'écosystème et du nombre d'utilisateurs.
Mais pour ces compétences tierces fonctionnant dans des environnements à haut niveau de privilèges, où se trouve réellement la frontière de sécurité de la plateforme ?
Récemment, CertiK, la plus grande société de sécurité Web3 au monde, a publié de nouvelles recherches sur la sécurité des Skills. Le rapport souligne qu'il existe actuellement un décalage dans la perception des limites de sécurité de l'écosystème des agents IA : l'industrie considère généralement le « scanning des Skills » comme la frontière de sécurité centrale, mais ce mécanisme est presque inefficace face aux attaques de pirates.
Si l'on compare OpenClaw à un système d'exploitation pour appareils intelligents, les Skills sont les différentes applications installées sur le système. Contrairement aux applications grand public classiques, certaines Skills d'OpenClaw s'exécutent dans des environnements à privilèges élevés, pouvant accéder directement aux fichiers locaux, appeler des outils système, se connecter à des services externes, exécuter des commandes dans l'environnement hôte, et même manipuler les actifs numériques cryptés de l'utilisateur. En cas de problème de sécurité, cela peut entraîner de graves conséquences telles que la fuite d'informations sensibles, la prise de contrôle à distance de l'appareil ou le vol d'actifs numériques.
Actuellement, la solution de sécurité générale pour les Skills tierces dans l'industrie est une « analyse et audit avant la mise en ligne ». Clawhub d'OpenClaw a également mis en place un système de protection en trois couches pour l'audit : intégration du scan de code VirusTotal, moteur de détection statique du code, détection de cohérence logique par IA, avec des alertes de sécurité poussées aux utilisateurs basées sur une évaluation des risques, tentant ainsi de préserver la sécurité de l'écosystème. Mais les recherches et les tests d'attaque POC de CertiK confirment que ce système de détection présente des lacunes dans un scénario réel de confrontation offensive/défensive et ne peut assumer la responsabilité centrale de la protection.
La recherche décompose d'abord les limitations inhérentes aux mécanismes de détection existants :
Les règles de détection statique sont facilement contournables. Le cœur de ce moteur repose sur la correspondance des caractéristiques du code pour identifier les risques, par exemple en qualifiant de comportement à haut risque la combinaison « lecture d'informations sensibles de l'environnement + requête réseau sortante ». Mais un attaquant n'a besoin que de modifier légèrement la syntaxe du code, en conservant pleinement la logique malveillante, pour contourner facilement la correspondance des caractéristiques, comme s'il donnait un synonyme au contenu dangereux, rendant ainsi le détecteur totalement inefficace.
L'audit IA présente des angles morts de détection congénitaux. L'audit IA de Clawhub est principalement un « détecteur de cohérence logique », il ne peut débusquer que les codes malveillants évidents où « la fonction déclarée et le comportement réel ne correspondent pas », mais il est impuissant face aux vulnérabilités exploitables cachées dans une logique métier normale, tout comme il est difficile de trouver un piège mortel caché au fond des clauses d'un contrat en apparence conforme.
Plus grave encore, le processus d'audit présente un défaut de conception fondamental : même si les résultats du scan VirusTotal sont encore en attente de traitement, une Skill n'ayant pas terminé le « check-up » complet peut être directement mise en ligne publiquement, et les utilisateurs peuvent l'installer sans aucun avertissement, laissant une opportunité aux attaquants.
Pour vérifier le préjudice réel du risque, l'équipe de recherche de CertiK a mené des tests complets. L'équipe a développé une Skill nommée « test-web-searcher », qui en surface est un outil de recherche web entièrement conforme, dont la logique du code respecte pleinement les normes de développement conventionnelles, mais qui en réalité intègre une vulnérabilité d'exécution de code à distance dans le flux fonctionnel normal.
Cette Skill a contourné la détection du moteur statique et de l'audit IA, et a pu être installée normalement sans aucun avertissement de sécurité alors que le scan VirusTotal était encore en attente ; finalement, en envoyant une simple commande à distance via Telegram, la vulnérabilité a été déclenchée avec succès, permettant l'exécution de commandes arbitraires sur l'appareil hôte (dans la démonstration, le système a été contrôlé pour ouvrir directement la calculatrice).
CertiK a clairement indiqué dans sa recherche que ces problèmes ne sont pas des bogues propres au produit OpenClaw, mais une erreur de perception courante dans toute l'industrie des agents IA : l'industrie considère généralement « l'audit et le scanning » comme la ligne de défense sécurité centrale, mais néglige le véritable fondement de la sécurité, qui est l'isolement obligatoire lors de l'exécution et le contrôle granulaire des permissions. C'est comme si la sécurité centrale de l'écosystème iOS d'Apple n'a jamais été l'audit strict de l'App Store, mais le mécanisme obligatoire de sandboxing et le contrôle granulaire des permissions, permettant à chaque application de s'exécuter dans son « conteneur isolé » dédié, sans pouvoir obtenir arbitrairement les permissions système. Or, le mécanisme de sandboxing existant d'OpenClaw est optionnel et non obligatoire, et dépend fortement d'une configuration manuelle par l'utilisateur. La grande majorité des utilisateurs, pour garantir la fonctionnalité des Skills, choisissent de désactiver le sandbox, laissant finalement l'agent fonctionner « à découvert ». Une fois une Skill vulnérable ou malveillante installée, les conséquences peuvent être désastreuses.
Face aux problèmes identifiés, CertiK a également fourni des directives de sécurité :
● Pour les développeurs d'agents IA comme OpenClaw, il est impératif de définir l'isolement par sandbox comme configuration obligatoire par défaut pour les Skills tierces, d'affiner le modèle de contrôle des permissions des Skills, et de ne jamais permettre à du code tiers d'hériter par défaut des privilèges élevés de la machine hôte.
● Pour les utilisateurs ordinaires, une Skill étiquetée « Sécurisée » sur le marché signifie seulement qu'aucun risque n'a été détecté, cela ne équivaut pas à une sécurité absolue. Avant que les développeurs ne configurent par défaut les mécanismes d'isolement fort au niveau底层, il est recommandé de déployer OpenClaw sur des appareils inutilisés non critiques ou dans une machine virtuelle, et surtout de ne pas le laisser approcher des fichiers sensibles, des identifiants de connexion ou des actifs cryptographiques de haute valeur.
Le domaine des agents IA est actuellement à l'aube d'une explosion, la vitesse d'expansion de l'écosystème ne doit pas devancer la construction de la sécurité. L'audit et le scanning ne peuvent bloquer que les attaques malveillantes basiques, et ne deviendront jamais la frontière de sécurité pour les agents à haut niveau de privilèges. Ce n'est qu'en passant d'une « recherche de détection parfaite » à une « endiguement des dommages supposant le risque existant par défaut », et en établissant fermement une frontière d'isolement au niveau de l'exécution, que l'on pourra vraiment garantir la sécurité de base des agents IA et permettre à cette révolution technologique d'avancer stablement et loin.
