Plus de 100 agents IA mis en compétition par Microsoft pour détecter des failles dans Windows

Microsoft publie un toolkit open source pour sécuriser les agents IA en production

Microsoft a publié un toolkit open-source destiné à sécuriser les agents d'intelligence artificielle en temps réel au sein des environnements d'entreprise. Baptisé runtime security toolkit, cet outil s'intercale entre le modèle de langage et le réseau d'entreprise pour surveiller, évaluer et bloquer les actions des agents autonomes au moment précis où ils tentent de les exécuter. Concrètement, lorsqu'un agent IA déclenche un appel vers un outil externe, une base de données, un pipeline CI/CD ou un dépôt cloud, le toolkit intercepte la requête, la compare à un ensemble de règles de gouvernance centralisées, et bloque l'action si elle enfreint la politique définie. Un agent autorisé uniquement à consulter un inventaire qui tenterait de passer une commande d'achat se verrait immédiatement arrêté, et l'événement serait journalisé pour révision humaine. L'enjeu est considérable pour les équipes de sécurité et les développeurs. Les systèmes d'IA d'entreprise ne se contentent plus de répondre à des questions : ils exécutent du code, envoient des e-mails, modifient des fichiers et interagissent avec des API critiques sans intervention humaine directe. Les méthodes traditionnelles, analyse statique du code, scan de vulnérabilités avant déploiement, sont structurellement inadaptées aux modèles de langage non-déterministes. Une seule attaque par injection de prompt ou une hallucination mal orientée peut suffire à écraser une base de données ou exfiltrer des données clients. Le toolkit de Microsoft découple la politique de sécurité de la logique applicative : les développeurs n'ont plus à hardcoder des règles de sécurité dans chaque prompt, et les équipes sécurité disposent d'une piste d'audit vérifiable pour chaque décision autonome du modèle. Le choix de publier ce toolkit sous licence open-source n'est pas anodin. Les développeurs construisent aujourd'hui des workflows autonomes en combinant des bibliothèques open-source, des frameworks variés et des modèles tiers, Anthropic, Meta, Mistral ou d'autres. Un outil propriétaire lié à l'écosystème Microsoft aurait probablement été contourné au profit de solutions non vérifiées, sous pression des délais. En ouvrant le code, Microsoft permet à n'importe quelle organisation, qu'elle tourne sur des modèles locaux, sur Azure ou sur des architectures hybrides, d'intégrer ces contrôles de gouvernance sans dépendance fournisseur. L'ouverture invite aussi la communauté cybersécurité à contribuer et à empiler des outils commerciaux, tableaux de bord, intégrations de réponse aux incidents, par-dessus cette fondation commune, accélérant la maturité de tout l'écosystème. À mesure que les agents autonomes s'imposent dans les entreprises, ce type de couche de sécurité d'infrastructure pourrait devenir un standard incontournable.

Amazon utilise des agents IA pour la détection de vulnérabilités à grande échelle

En 2025, la base de données nationale des vulnérabilités américaine (NVD) a enregistré plus de 48 000 nouvelles failles de sécurité référencées (CVE), un volume rendu possible en grande partie par la prolifération des outils automatisés de détection. Face à cette explosion, Amazon Web Services a développé RuleForge, un système d'intelligence artificielle agentique conçu pour générer automatiquement des règles de détection à partir d'exemples de code d'exploitation de vulnérabilités. Déployé en production chez AWS, RuleForge affiche une productivité supérieure de 336 % à la création manuelle, tout en conservant le niveau de précision exigé pour des systèmes de sécurité industriels. Les règles produites sont au format JSON et alimentent directement MadPot, le système mondial de "honeypot" d'Amazon qui capture le comportement des attaquants, ainsi que Sonaris, le moteur interne de détection d'exploits suspects. Avant RuleForge, transformer une CVE en règle de détection opérationnelle était un processus entièrement manuel : un analyste téléchargeait le code de preuve de concept, étudiait le mécanisme d'attaque, rédigeait la logique de détection, la validait par itérations successives contre les journaux de trafic, puis soumettait le tout à une revue par un second ingénieur avant déploiement. Ce cycle, rigoureux mais lent, obligeait les équipes à prioriser strictement les vulnérabilités traitées, laissant potentiellement des failles critiques sans couverture. RuleForge comprime ce délai de façon drastique : le système ingère automatiquement le code d'exploitation public, attribue un score de priorité via une analyse de contenu croisée avec des sources de threat intelligence, puis génère en parallèle plusieurs règles candidates via un agent tournant sur AWS Fargate avec Amazon Bedrock. Chaque candidate est évaluée non pas par le modèle qui l'a produite, mais par un agent "juge" distinct, évitant ainsi l'auto-validation biaisée. Les humains restent dans la boucle pour l'approbation finale avant mise en production. Cette architecture reflète une tendance profonde dans la sécurité offensive et défensive : l'automatisation par IA ne remplace pas les experts, elle leur permet de travailler à une échelle autrement inaccessible. AWS anticipe une croissance continue du nombre de CVE à haute sévérité publiées, portée par les mêmes outils d'IA qui accélèrent la découverte de failles côté attaquants. RuleForge représente la réponse symétrique côté défense, en industrialisant la réactivité. L'approche modulaire, avec des agents spécialisés pour la génération, l'évaluation et le raffinement, plutôt qu'un seul modèle monolithique, s'inscrit dans la lignée des architectures multi-agents qui émergent comme standard pour les tâches complexes nécessitant fiabilité et auditabilité. D'autres grands acteurs du cloud font face aux mêmes défis, et la publication par Amazon des détails de RuleForge suggère une volonté de positionner cette approche comme référence sectorielle.

Recall de Windows 11 encore épinglé pour ses failles de sécurité

Microsoft a de nouveau été mis sous pression concernant Recall, sa fonction phare intégrée aux PC Copilot+ sous Windows 11. Annoncée en juin 2024 et repoussée d'environ un an pour corriger de graves failles de sécurité, Recall permet de retrouver n'importe quel document, page web ou application en analysant des captures d'écran réalisées toutes les quelques secondes. Après une refonte complète de son architecture, stockage des données dans une enclave chiffrée, authentification obligatoire via Windows Hello, désactivation par défaut et exclusion des identifiants bancaires, Microsoft avait relancé la fonction en croyant avoir colmaté les brèches. C'est désormais le chercheur en sécurité Alexander Hagenah qui remet en cause cette certitude. Auteur du premier outil d'extraction TotalRecall en 2024, il publie sur GitHub une nouvelle version baptisée TotalRecall Reloaded, qui démontre qu'il est possible d'injecter une bibliothèque DLL dans AIXHost.exe, le processus Windows responsable de l'affichage de la chronologie Recall, afin d'accéder aux données déchiffrées en temps réel, captures d'écran, texte extrait par OCR, métadonnées, sans droits administrateur ni exploitation technique complexe. L'enjeu est considérable pour les millions d'utilisateurs de PC Copilot+ équipés de Recall : un simple logiciel malveillant, une fois exécuté après une session Windows Hello, peut silencieusement aspirer l'intégralité de l'historique enregistré par la fonction. TotalRecall Reloaded va plus loin encore : il peut récupérer la dernière capture d'écran réalisée par Recall sans même passer par l'authentification Windows Hello, et effacer complètement l'historique. Pour Hagenah, le problème est précis : ce n'est pas le chiffrement, ni l'enclave sécurisée, ni le modèle d'authentification qui sont défaillants, mais le fait que les données déchiffrées soient transmises à un processus non protégé, AIXHost.exe, qui n'est soumis à aucune vérification d'intégrité supplémentaire. La porte de sécurité existe, mais elle se referme trop tôt dans la chaîne de traitement. Microsoft a répondu début mars, après avoir reçu le signalement du chercheur, en fermant le dossier : selon l'éditeur, les modes d'accès observés sont "conformes aux protections prévues et aux contrôles existants" et ne constituent pas une vulnérabilité. Cette position illustre une tension plus large dans le domaine de la sécurité logicielle : la frontière entre comportement "by design" et faille exploitable est souvent décidée unilatéralement par l'éditeur. Recall cristallise depuis son annonce les inquiétudes des chercheurs et des défenseurs de la vie privée, qui voient dans la collecte systématique d'écrans une surface d'attaque structurellement difficile à sécuriser. L'affaire relance le débat sur la responsabilité des fabricants qui intègrent des fonctions de surveillance de masse dans les systèmes d'exploitation grand public, et sur les limites des certifications de sécurité internes quand des chercheurs indépendants parviennent à des conclusions opposées.

💬 L'enclave chiffrée, Windows Hello, la désactivation par défaut... tout ça pour que la donnée déchiffrée finisse dans un processus non protégé, accessible sans droits admin. C'est pas une faille subtile, c'est une erreur d'architecture de base, et je vois pas comment ça passe une revue interne sérieuse. Quand Microsoft te répond "c'est by design" après un exploit qui aspire tout ton historique sans élévation de privilège, t'as ta réponse sur ce que vaut Recall.

Une commande transforme tout dépôt open source en porte dérobée pour agents IA, indétectable par les scanners (OpenClaw)

Une équipe de chercheurs de l'Université de Hong Kong a publié en mars 2026 un outil baptisé CLI-Anything, capable d'analyser le code source de n'importe quel dépôt open source et de générer automatiquement une interface en ligne de commande (CLI) exploitable par un agent IA en une seule instruction. Compatible avec Claude Code, Codex, Cursor, GitHub Copilot CLI et d'autres, l'outil a dépassé les 30 000 étoiles sur GitHub en deux mois. Mais c'est ce que CLI-Anything génère qui inquiète les chercheurs en sécurité : des fichiers SKILL.md, des définitions d'instructions en langage naturel que les agents IA utilisent pour comprendre comment opérer un logiciel. Or en février 2026, les travaux ToxicSkills de Snyk avaient déjà recensé 76 charges malveillantes confirmées dans des fichiers de ce type sur ClawHub et skills.sh. La communauté offensive discute désormais ouvertement des implications sur X et dans les forums de sécurité. Le problème central est qu'aucun scanner de sécurité existant n'est équipé pour détecter des instructions malveillantes glissées dans des définitions de compétences pour agents IA. Les outils SAST analysent la syntaxe du code source ; les outils SCA vérifient les versions des dépendances. Ni l'un ni l'autre ne comprend la couche sémantique où opèrent les descriptions d'outils MCP, les prompts d'agents et les fichiers de règles. Cisco l'a confirmé en avril dans un billet annonçant son AI Agent Security Scanner, précisant que ces outils traditionnels "n'ont pas été conçus pour cela". Merritt Baer, directrice de la sécurité chez Enkrypt AI et ancienne Deputy CISO chez AWS, résume : "SAST et SCA ont été construits pour le code et les dépendances. Ils n'inspectent pas les instructions." Une définition de compétence empoisonnée ne déclenche aucune CVE et n'apparaît jamais dans un SBOM. Cette faille structurelle s'inscrit dans une évolution plus large des chaînes d'approvisionnement logicielles. Les outils de type agent bridge, MCP connectors ou fichiers de règles Cursor constituent une troisième couche entre le code et les dépendances : des fichiers de configuration en langage naturel qui, sans ressembler à du code, s'exécutent comme du code. Des chercheurs de quatre universités (Griffith, Nanyang, UNSW et Tokyo) ont documenté en avril la technique DDIPE (Document-Driven Implicit Payload Execution), qui intègre une logique malveillante dans des exemples de documentation de compétences. Sur quatre frameworks d'agents et cinq grands modèles de langage, le taux de contournement a atteint entre 11,6 % et 33,5 %, et 2,5 % des échantillons ont échappé aux quatre couches de détection testées. L'industrie se trouve donc dans une fenêtre de pré-exploitation : l'attaque est théorisée, l'outil est déployé, et les défenses n'ont pas encore de catégorie pour nommer ce qu'elles cherchent.

💬 Le vrai problème, c'est qu'on a ajouté une couche entière dans la chaîne logicielle, des fichiers en langage naturel qui s'exécutent comme du code, sans que personne ait d'outil pour la surveiller. SAST et SCA ont été conçus pour la syntaxe et les dépendances, pas pour la couche sémantique où tournent tes agents. Ce qui m'inquiète le plus : l'attaque est théorisée, l'outil est déployé, et les défenses n'ont même pas encore de catégorie pour nommer ce qu'elles cherchent.