La faille de vos agents IA n'est pas le modèle, c'est la marketplace

Entre 60 000 et 65 000 instances de l'agent IA OpenClaw sont aujourd'hui joignables sur internet sans la moindre authentification, selon un relevé Shodan cité par Unit 42 (Palo Alto Networks, 23 juin 2026). Ce n'est pas une intrusion. C'est un port par défaut, resté ouvert, reproduit des dizaines de milliers de fois — parce que personne n'a eu besoin de changer un paramètre pour que l'agent fonctionne.

Sa marketplace de plugins, ClawHub, a de son côté laissé passer un nombre significatif de « skills » malveillants à travers son filtrage automatique. Les chercheurs qui ont documenté le phénomène ne s'accordent pas sur le chiffre exact — Koi Security en a recensé 341 dans une première passe, puis 824 dans une révision ultérieure ; Acronis en compte 575 sur son propre périmètre — mais tous convergent sur un ordre de grandeur : de plusieurs centaines à plus d'un millier selon les études. Quatre vulnérabilités, baptisées « Claw Chain » (CVE-2026-44112, 44113, 44115, 44118), ont été publiées le 6 mai 2026 et patchées dans la version 2026.4.22. Leur sévérité illustre à elle seule pourquoi il faut lire les chiffres avec méthode plutôt qu'avec émotion : le score CVSS tourne jusqu'à 9.6 CRITICAL selon le référentiel du CNA qui a publié la CVE, mais le NIST le recalcule à 6.3 MEDIUM dans le NVD. Ce n'est pas une contradiction suspecte. C'est deux référentiels qui pondèrent différemment le contexte d'exploitation — et c'est exactement le genre de nuance qu'un article qui veut faire peur choisit de ne pas donner.

Ces faits ont déjà été publiés ailleurs, sur un registre d'alerte. Nous ne les reprenons pas pour ajouter une sirène de plus. Nous les reprenons parce qu'ils illustrent, avec une précision inhabituelle, un maillon de la chaîne que personne ne mesure encore correctement : ce que votre agent installe tout seul, et ce que cette installation lui donne le droit de faire.

Ce qui s'est réellement passé

OpenClaw est un agent IA open-source, conçu pour agir en autonomie sur des tâches longues — naviguer, exécuter du code, orchestrer des outils. Comme tout agent moderne, il gagne en utilité à mesure qu'on lui ajoute des capacités : une extension pour lire vos emails, une autre pour piloter votre navigateur, une autre pour interroger votre base de données. Ces extensions viennent d'une marketplace, ClawHub, sur le même principe qu'un store d'applications.

Le problème n'est pas que ce principe soit mauvais. Il a fait ses preuves ailleurs. Le problème est que la marketplace d'un agent IA n'a pas encore les garde-fous que npm ou PyPI ont mis quinze ans à construire — signature systématique, revue de code avant publication, quarantaine automatique en cas de signalement. ClawHub filtre automatiquement les soumissions, et ce filtre a laissé passer des centaines de skills conçus pour exfiltrer des identifiants, ouvrir des accès distants ou détourner des appels d'outils. Les CVE Claw Chain, elles, touchent un autre étage : le protocole d'échange entre l'agent et ses outils, pas les plugins eux-mêmes. Deux failles distinctes, sur deux couches distinctes, qui pointent toutes les deux vers le même point aveugle.

Ces vulnérabilités ont été publiées et corrigées. C'est le fonctionnement normal d'un écosystème de sécurité qui s'auto-corrige — pas la preuve d'un projet défaillant. OpenClaw a trois ans. L'écosystème qui l'entoure a l'âge de sa croissance, pas celui de sa maturité. Une taxonomie académique récente (arXiv 2603.27517) recense déjà 470 advisories de sécurité sur l'ensemble des frameworks d'agents IA — un signal que le sujet dépasse largement un seul projet, et qu'il structure désormais une catégorie de risque à part entière.

Le maillon que personne n'audite

Voici l'idée qu'il faut retenir, au-delà des chiffres : quand on installe une extension d'agent IA, on l'installe comme une application — sauf qu'elle hérite de tous les droits de l'agent. Donc des vôtres. Un skill qui lit vos fichiers a accès à vos fichiers. Un skill qui envoie des requêtes réseau a accès à votre réseau. Un skill qui utilise vos clés API les utilise avec vos permissions, pas les siennes.

La surface d'attaque d'un système agentique n'est ni le modèle de langage qui raisonne, ni le code que vous avez écrit vous-même. C'est la chaîne d'approvisionnement de l'agent : ses skills, ses plugins, ses connecteurs MCP (le protocole qui relie un agent à ses outils externes), sa marketplace — et l'exposition réseau de l'instance qui fait tourner tout ça. Aucun scanner de code classique ne regarde cette couche. Un SAST analyse ce que vous avez écrit. Un SCA analyse les dépendances déclarées dans votre manifeste. Ni l'un ni l'autre ne voit ce que votre agent télécharge et exécute de sa propre initiative, à l'exécution, sur décision d'un skill installé la veille.

Il y a un précédent instructif à ce déplacement de risque. La sécurité logicielle a mis une vingtaine d'années à apprendre à auditer ses dépendances — le scandale event-stream sur npm en 2018, les typosquats récurrents sur PyPI, les audits de licence devenus obligatoires dans toute entreprise sérieuse. L'IA agentique vient de recréer ce même problème, en trois ans, avec un niveau de privilège nettement supérieur. Une dépendance npm compromise lit vos variables d'environnement au moment du build. Un skill d'agent compromis lit vos emails, vos fichiers, votre historique de conversation, en continu, pendant que vous travaillez. Le rapport de force n'est pas comparable.

Une grille, pas une alerte

La question utile n'est donc pas « faut-il avoir peur des agents IA ». C'est : comment rend-on cette couche vérifiable, plutôt que de la laisser invisible ? Voici la grille que nous utilisons, et que vous pouvez appliquer ce soir à n'importe quelle extension déjà installée sur un agent que vous faites tourner.

Provenance. D'où vient l'extension ? Qui la signe ? Le code source est-il lisible avant installation, ou seulement un package binaire opaque ? Une marketplace sans signature ni revue humaine documentée est, en pratique, un dépôt anonyme — même si l'interface donne l'impression d'un store curé.

Privilèges. Que peut faire l'extension au maximum, pas ce qu'elle fait en usage normal. Un skill qui ne demande officiellement qu'un accès lecture-seule à un calendrier peut, techniquement, embarquer un accès fichiers ou réseau non déclaré si le système de permissions de l'agent ne le contraint pas au runtime. La question à poser n'est jamais « que fait-elle », c'est « que pourrait-elle faire si elle était compromise demain ».

Exposition réseau. Votre agent est-il joignable depuis internet, ou seulement depuis votre machine ? Écoute-t-il sur 0.0.0.0 (toutes les interfaces) ou sur 127.0.0.1 (localhost uniquement) ? Y a-t-il un jeton d'authentification, ou l'accès est-il ouvert dès qu'on connaît l'adresse ? C'est très exactement ce paramètre — un port par défaut, sans authentification — qui explique les dizaines de milliers d'instances OpenClaw joignables recensées par Shodan.

Le défaut protège-t-il ? Quand une option de sécurité n'est pas explicitement configurée, l'outil se comporte-t-il en mode fermé ou en mode ouvert ? La plupart des défauts d'usine sont permissifs, parce qu'un défaut permissif « marche » immédiatement, sans friction d'installation — et c'est précisément ce qui rend le risque invisible : personne n'a l'impression d'avoir fait un choix.

La trace. Pouvez-vous démontrer, dans six mois, quelles extensions étaient installées sur quel agent, depuis quand, et avec quelle version ? Sans inventaire daté, un incident découvert tardivement est impossible à borner dans le temps — vous ne saurez ni depuis quand l'exposition existait, ni ce qu'elle a pu voir passer.

Cinq questions, posées extension par extension, transforment un point aveugle en objet documenté. C'est tout l'écart entre « on espère que ça va » et « on peut le montrer ».

Ce qu'on s'applique à nous-mêmes

Un auditeur de conformité IA qui recommanderait cette grille sans se l'appliquer serait une contradiction difficile à défendre. Notre propre composant de veille runtime, POSITRONIA-Observe, reçoit en continu les traces des agents IA qu'il surveille — c'est, par nature, un service qui écoute un flux réseau. Nous appliquons donc notre propre point 3 : ce composant écoute exclusivement sur 127.0.0.1, protégé par un jeton d'authentification, jamais exposé sur une interface réseau publique par défaut. Ce n'est pas une promesse marketing. C'est un choix de configuration, vérifiable par quiconque inspecte comment le service démarre. Nous préférons ce genre de vérifiabilité concrète à une déclaration d'intention — c'est aussi tout l'esprit de la doctrine EuTrustedIA : documenter ce qui est constatable, pas ce qu'on voudrait qu'on croie.

Ce que vous pouvez faire ce soir

Prenez l'inventaire réel de ce qui tourne : quels agents, quels skills, quels connecteurs MCP sont installés sur vos machines de développement ou vos serveurs. Pour chacun, posez les cinq questions de la grille — provenance, privilèges, exposition réseau, comportement par défaut, trace datée. C'est un exercice d'une heure, gratuit, qui ne demande aucun outil, et qui suffit déjà à faire remonter les cas manifestement ouverts : un agent qui écoute sur toutes les interfaces sans jeton, un skill installé sans qu'on se souvienne pourquoi.

C'est exactement ce que couvrent nos règles POSITRONIA-CORE au-delà du code que vous avez écrit vous-même : l'inventaire des extensions et connecteurs d'un agent IA, leur provenance, leurs privilèges effectifs, et l'exposition réseau des instances qui tournent dans votre stack — le maillon que les scanners de code classiques ne regardent pas, parce que ce n'est ni du code applicatif ni une dépendance déclarée dans un manifeste. Le scan tourne en local, sur votre machine, et documente ce périmètre pour qu'il devienne un objet que vous pouvez montrer à un DPO ou à un avocat tech — pas un angle mort que vous découvrez le jour où quelqu'un d'autre le mesure à votre place.