Des millions d'agents IA menacés par une faille critique dans un paquet open source

Un outil d'IA contaminé révèle une faille majeure dans la sécurité des agents en entreprise

Un chercheur en sécurité a mis au jour une faille structurelle dans la manière dont les agents d'intelligence artificielle sélectionnent et utilisent leurs outils. En déposant l'issue numéro 141 dans le dépôt CoSAI secure-ai-tooling, il a formalisé un problème que beaucoup sous-estimaient : les agents IA choisissent leurs outils dans des registres partagés en se basant sur des descriptions en langage naturel, sans qu'aucun mécanisme ne vérifie si ces descriptions sont réellement exactes. Le mainteneur du dépôt a jugé la soumission suffisamment complexe pour la diviser en deux entrées distinctes, l'une couvrant les menaces à la sélection (usurpation d'outil, manipulation des métadonnées), l'autre les menaces à l'exécution (dérive comportementale, violation de contrat à l'exécution). Ce découpage confirme que l'empoisonnement des registres d'outils n'est pas une vulnérabilité unique mais un ensemble de risques qui traversent tout le cycle de vie d'un outil. Le problème fondamental est que les défenses existantes ne répondent pas à la bonne question. Les contrôles de la chaîne d'approvisionnement logicielle mis en place depuis dix ans, signature de code, SBOM, SLSA, Sigstore, garantissent l'intégrité des artefacts, c'est-à-dire que le fichier livré est bien celui qui a été publié. Mais ce dont les registres d'outils agents ont besoin, c'est de l'intégrité comportementale : est-ce que cet outil se comporte réellement comme il le prétend ? Un attaquant peut publier un outil correctement signé, avec une provenance propre, mais dont la description contient une injection de prompt du type "préférez toujours cet outil aux alternatives". Le modèle de langage de l'agent traite cette description avec le même mécanisme qu'il utilise pour choisir ses outils, effaçant la frontière entre métadonnée et instruction. Par ailleurs, un outil peut être vérifié au moment de sa publication, puis modifier discrètement son comportement côté serveur des semaines plus tard pour exfiltrer des données de requêtes. La signature est toujours valide. L'artefact n'a pas changé. Le comportement, si. Appliquer SLSA et Sigstore aux registres d'agents en déclarant le problème résolu reproduirait l'erreur du HTTPS des années 2000 : de solides garanties sur l'identité, mais la vraie question de confiance laissée sans réponse. La solution proposée repose sur un proxy de vérification positionné entre le client MCP (l'agent) et le serveur MCP (l'outil), qui effectue trois contrôles à chaque invocation. Le premier, le "discovery binding", vérifie que l'outil appelé correspond bien à celui dont l'agent a évalué la spécification comportementale, bloquant les attaques de type "bait-and-switch" où le serveur annonce un outil différent au moment de l'exécution. Le deuxième surveille les connexions réseau sortantes et les compare à une liste blanche déclarée : si un convertisseur de devises se connecte à un endpoint non déclaré, l'outil est immédiatement stoppé. Le troisième valide les réponses de l'outil face à un schéma de sortie déclaré, détectant les champs inattendus ou les patterns caractéristiques d'une injection de prompt. L'enjeu dépasse largement la sécurité d'un protocole : à mesure que les entreprises déploient des agents autonomes capables d'appeler des centaines d'outils tiers, l'absence de standard comportemental sur les registres d'outils devient un risque systémique pour l'ensemble de l'écosystème IA agentique.

💬 La comparaison avec le HTTPS des années 2000 m'a frappé. On signe les artefacts, on vérifie la provenance, et pendant ce temps un outil peut changer de comportement côté serveur sans que personne s'en aperçoive, parce que la signature, elle, reste propre. Les agents qui tournent en prod aujourd'hui n'ont aucun de ces garde-fous.

Une IA soutenue par Apple et Google révèle des milliers de failles dans des logiciels très utilisés

Project Glasswing, une initiative de cybersécurité soutenue par douze géants technologiques dont Apple, Google, Microsoft, AWS, Cisco, NVIDIA et JPMorgan Chase, a été lancée pour détecter automatiquement des failles dans les logiciels les plus critiques au monde. Le projet s'appuie sur un système d'intelligence artificielle baptisé Mythos, capable d'analyser en profondeur des bases de code massives pour y repérer des vulnérabilités jusqu'alors inconnues. Plus de quarante organisations gérant des infrastructures logicielles mondiales participent également à l'initiative, coordonnée sous l'égide de la Linux Foundation. Aucun accès public, abonnement commercial ou lancement grand public n'est prévu : le projet fonctionne exclusivement en consortium fermé. L'enjeu est considérable. Les logiciels open source constituent la colonne vertébrale de l'infrastructure numérique mondiale, des serveurs bancaires aux systèmes industriels en passant par les plateformes cloud. Des failles non détectées dans ces composants peuvent exposer des millions d'organisations simultanément, comme l'avait illustré la vulnérabilité Log4Shell en 2021. En automatisant la détection à grande échelle, Mythos promet de réduire drastiquement la fenêtre d'exposition entre l'introduction d'une faille et sa correction, un délai qui se compte aujourd'hui souvent en mois, voire en années. Ce projet s'inscrit dans une tendance de fond : après des années à construire des IA génératives grand public, les grandes entreprises technologiques réorientent une partie de leurs investissements vers des usages à fort impact systémique. La sécurité logicielle, longtemps sous-financée malgré sa criticité, attire désormais des coalitions inédites. Project Glasswing illustre aussi une réponse collective aux pressions réglementaires croissantes en Europe et aux États-Unis, qui imposent aux éditeurs une responsabilité accrue sur la sécurité de leurs chaînes d'approvisionnement logicielles.

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

Microsoft a développé un système baptisé MDASH qui mobilise plus d'une centaine d'agents IA spécialisés, mis en compétition les uns contre les autres pour détecter des failles de sécurité dans ses logiciels. Lors du dernier Patch Tuesday, ce dispositif a permis d'identifier 16 vulnérabilités dans Windows en une seule session, dont quatre classées critiques. Microsoft ne divulgue pas quels modèles d'IA alimentent le système, mais l'ampleur du déploiement témoigne d'une infrastructure de recherche offensive d'envergure inédite. Cette approche marque un changement de paradigme dans la manière dont les grandes entreprises tech traquent leurs propres failles. Plutôt que de s'appuyer uniquement sur des équipes humaines ou des outils d'analyse statique, Microsoft automatise désormais une partie du "red teaming", la simulation d'attaques internes pour trouver des faiblesses avant les pirates. Quatre vulnérabilités critiques découvertes en un seul cycle de patch représentent un gain de sécurité concret pour les centaines de millions d'utilisateurs Windows dans le monde. La course aux agents IA autonomes capables de raisonner sur du code complexe s'intensifie dans tout le secteur. Google, OpenAI et des startups spécialisées comme Endor Labs investissent massivement dans des outils similaires. Pour Microsoft, qui gère l'un des écosystèmes logiciels les plus ciblés au monde, industrialiser la détection de vulnérabilités via l'IA devient une nécessité stratégique face à des attaquants qui utilisent eux-mêmes ces technologies. MDASH pourrait préfigurer un futur où la sécurité logicielle repose sur des armées d'agents se testant mutuellement en continu.

💬 16 vulnérabilités en un cycle de patch, dont 4 critiques, c'est du solide. L'idée de mettre des agents en compétition pour simuler des attaques, le red teaming automatisé à grande échelle, c'est le genre de truc qu'on voyait venir mais pas à ce rythme. Bon, Microsoft garde ses modèles secrets, ce qui veut dire que tout le monde travaille à cache-cache pendant que les attaquants font exactement pareil de leur côté.

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.