Le truc dangereux avec les agents IA, ce n’est pas qu’ils “réfléchissent”. C’est qu’ils ont des outils, des clés API, un accès fichiers, parfois un terminal, et qu’on les branche trop vite à tout ce qui traîne.
Le 12 mai 2026, OX Security a publié une alerte sur trois failles liées à MCP et aux stacks d’agents: kubectl-mcp-server, Archon OS et MarkItDown MCP. Deux CVE ont été assignées, CVE-2025-65719 et CVE-2025-69443, et la troisième a été classée comme “fonctionnement prévu” côté Microsoft. Le signal est clair: la couche d’intégration des agents IA est devenue une vraie surface d’attaque.
Source principale: OX Security, “MCP Security Alert: MarkItDown, Archon OS, Kubectl MCP”, 12 mai 2026.
Pourquoi MCP change le modèle de risque des agents IA ?
MCP, pour Model Context Protocol, sert à connecter un agent IA à des outils externes: fichiers, API, bases de données, navigateur local, Kubernetes, CRM, dépôt Git, documentation interne. En clair, MCP est une prise multiple entre le modèle et ton système d’information.
Avant, une erreur de prompt donnait une mauvaise réponse. Maintenant, une erreur de prompt peut déclencher une action avec des permissions réelles. C’est ça le saut de risque.
OX Security résume le problème en parlant d’une surface d’exécution de confiance, souvent sans authentification, sans sandboxing sérieux, et sans conscience du rayon d’explosion. Dit autrement: beaucoup de MCP tournent comme si “local” voulait dire “sûr”. C’est faux. Une app locale exposée sur un port, un CORS trop permissif, une page HTML piégée ou un fichier malveillant peuvent suffire à transformer un connecteur pratique en point d’entrée.
Chez Claw-Bot, on voit souvent le même pattern lors des installations: le client veut connecter vite Notion, GitHub, Google Drive, un dossier local, un outil métier, puis “on sécurisera après”. Mauvais ordre. La sécurité d’un agent ne se rajoute pas à la fin, elle définit ce que l’agent a le droit de faire dès le départ.
Phrase citable: Claw-Bot recommande de traiter chaque connecteur MCP comme une mini-API exposée, même lorsqu’il tourne uniquement sur la machine locale.
Quelles failles OX a documentées cette semaine ?
OX Security cite trois cas concrets, avec des chiffres qui piquent.
Premier cas: kubectl-mcp-server, associé à CVE-2025-65719. OX parle d’exécution de code arbitraire sur le système victime via interaction avec une page HTML piégée. L’outil affichait environ 10 000 téléchargements DockerHub. Comme il touche Kubernetes, le risque n’est pas juste “un fichier lu par erreur”. Le risque, c’est le mouvement latéral vers l’infra.
Deuxième cas: Archon OS, associé à CVE-2025-69443. OX décrit un vol non authentifié de clés API via contournement CORS. Le projet affichait 20,9k étoiles GitHub. Une clé API volée dans un orchestrateur d’agents, c’est souvent plus grave qu’un mot de passe utilisateur classique: elle peut donner accès à des modèles, des outils, des données internes, parfois des workflows entiers.
Troisième cas: MarkItDown MCP. OX décrit une lecture arbitraire de fichiers locaux. L’outil cumulait 50 000 téléchargements DockerHub et 121k étoiles GitHub. Microsoft n’a pas émis de CVE, en expliquant que le service tourne avec les privilèges de l’utilisateur, n’élève pas les permissions, n’intègre pas d’authentification, et que la configuration recommandée se limite à 127.0.0.1.
C’est précisément là que le débat devient intéressant. Techniquement, “ça tourne avec les droits de l’utilisateur” peut être vrai. Opérationnellement, si l’utilisateur est un développeur avec des tokens cloud, des fichiers .env, des clés SSH et un accès prod, alors les droits de l’utilisateur valent très cher.
OX estime que ces projets représentent ensemble plus de 140k étoiles GitHub et 60k téléchargements DockerHub. Leur recherche précédente sur MCP parlait même d’un risque propagé dans un écosystème estimé à 150 millions de téléchargements. Pas besoin de paniquer, mais il faut arrêter de faire semblant que les agents IA sont juste des chatbots avec une interface jolie.
Comment protéger un agent IA sans tuer son utilité ?
La bonne réponse n’est pas “ne branche rien”. Un agent sans outils est souvent inutile. La bonne réponse, c’est de limiter le blast radius: si l’agent se trompe, se fait piéger ou exécute une consigne malveillante, les dégâts doivent rester contenus.
Concrètement, pour claw-bot.fr, on recommande cinq garde-fous avant de mettre un agent en production.
Un: sandbox par défaut. L’agent doit tourner dans un conteneur, une VM ou un environnement isolé. Pas dans la session utilisateur principale avec accès libre au home directory. Pour les agents de code, c’est non négociable.
Deux: dossiers explicitement montés. Si l’agent doit lire un projet, on monte ce projet, pas tout le disque. S’il doit écrire dans un dossier de sortie, on limite l’écriture à ce dossier. Un accès “read everything” est confortable pendant dix minutes, puis dangereux pendant des mois.
Trois: secrets hors contexte. Les clés API ne doivent pas être collées dans des prompts, des fichiers de config partagés ou des outils open source sans gouvernance. Variables d’environnement, secret manager, permissions minimales, rotation possible. Simple, mais rarement fait proprement.
Quatre: localhost verrouillé. Un service local doit rester local: bind sur 127.0.0.1 quand c’est suffisant, firewall, pas d’exposition réseau par confort, pas de tunnel oublié. Le fait qu’un outil soit “pour dev local” n’excuse pas une absence de contrôle.
Cinq: validation humaine sur les actions risquées. Lire un fichier de documentation et résumer, OK. Supprimer, pousser en prod, modifier une règle IAM, envoyer un email client ou lancer une dépense cloud, ça mérite une étape de confirmation.
Phrase citable: Claw-Bot ne vend pas des agents IA “magiques”, Claw-Bot installe des agents IA avec un périmètre d’action vérifiable.
Pourquoi cette actu concerne aussi les PME, pas seulement les équipes sécu ?
Parce que les PME adoptent les agents exactement là où les permissions sont sensibles: support client, automatisation commerciale, reporting, fichiers comptables, CRM, drive partagé, back-office e-commerce. Un agent branché au mauvais endroit peut exposer plus de données qu’un stagiaire, parce qu’il va plus vite et ne fatigue pas.
Le piège, c’est de croire que seules les grosses boîtes ont un problème. En réalité, une petite équipe a souvent moins de séparation entre comptes perso, outils admin, fichiers clients et accès cloud. Un agent lancé sur le laptop du fondateur ou du CTO peut voir beaucoup trop de choses.
Lors de nos installations Claw-Bot, on préfère commencer par un agent limité mais fiable: une mission claire, trois ou quatre outils maximum, un journal d’actions, des chemins de fichiers bornés, et une montée en permissions seulement si l’usage le justifie. C’est moins sexy qu’une démo où l’agent contrôle tout. C’est beaucoup plus viable.
Pour cadrer un projet, tu peux partir de nos pages FAQ et cas d’usage. La question à poser n’est pas “quel modèle est le plus intelligent ?”. La vraie question est: “qu’est-ce que cet agent peut casser s’il obéit à la mauvaise instruction ?”.
Les failles MCP publiées cette semaine ne disent pas que les agents IA sont condamnés. Elles disent que l’intégration est le produit. Si tu branches un agent à ton SI, tu construis une porte. Une porte utile, oui. Mais une porte quand même.