Rapport 2026 de Mandiant sur l’IA : la facture de 50 000 $ d’un agent incontrôlé et les intrusions assistées par IA

Le rapport de MandiantAI Risk and Resilience 2026, publié sur Google Cloud en septembre 2026 et relayé la même semaine par Help Net Security, The Hacker News et SecurityBrief, décrit trois interventions dans lesquelles l'IA était le mécanisme plutôt que la cible : une session d'assistant de codage IA détournée qui a propagé le ver Shai-Hulud dans environ 100 dépôts internes chez un fournisseur de logiciels en tant que service non nommé ; un identifiant CI/CD compromis qu'un intrus a transformé en un hub offensif assisté par l'IA au sein d'une entreprise de santé, exfiltrant des milliers d'identifiants ; et un agent comptable qui a généré environ 50 000 $ de frais cloud en moins d'une heure après qu'une valeur nulle corrompue a cassé l'un de ses outils, verrouillant une base de données de facturation et interrompant des transactions en direct. Aucun attaquant n'était impliqué dans le troisième cas. Le dossier sur lequel cet article s'appuie, ainsi que les entrées consignées autour de lui, se trouvent dans l'archive des incidents liés à l'IA, qui comporte pour chaque entrée ses propres sources, sa gravité, son niveau de confiance et son indicateur de contestation.

De quel type de document il s'agit

Le rapport, intitulé « AI risk and resilience in 2026: A Mandiant special report », figure sur la page des ressources de sécurité de Google Cloud ; il s’agit d’une publication de fournisseur et non d’une divulgation de violation. Ses études de cas proviennent des missions de réponse aux incidents de Mandiant et des évaluations de son équipe Offensive Security, et les organisations ne sont identifiées que par leur secteur : un fournisseur de logiciel en tant que service, une organisation mondiale du secteur de la santé et un fournisseur mondial de services financiers aux entreprises. Aucune victime n’est nommée, aucune intrusion n’est datée et aucune déclaration de victime n’accompagne aucune des trois.

Cela détermine la manière dont il faut lire les chiffres. Chaque nombre qu'ils contiennent provient des propres enquêteurs de Mandiant. La note « Frontier Ready » du Cloud Security Alliance datée du 16 septembre qualifie les quelque 50 000 dollars facturés et le volume de 15 000 appels d'« auto-déclarés (métrique du fournisseur) » et indique qu'ils « n'ont pas été vérifiés indépendamment » — une description fidèle de l'ensemble du rapport, qui ne publie aucune télémétrie tierce permettant de vérifier. L'archive classe cette entrée comme une consignation informative, un rapport plutôt qu'un incident avec un préjudice enregistré, et lui attribue une note de confiance A sans la signaler comme contestée ; cette note reflète la qualité de la documentation du rapport, et non la question de savoir si une partie extérieure en a confirmé le contenu.

Le rapport présente lui-même les choses ainsi : en 2026, les adversaires sont passés du fait de demander aux chatbots des recherches à celui de laisser des systèmes agentiques prendre en charge certaines parties d'une intrusion. Mandiant indique que Google Threat Intelligence Group a observé des acteurs déployer des outils autonomes, notamment Hexstrike et Strix, pour la reconnaissance et la collecte d'identifiants, et construire des relais proxy et des pipelines d'enregistrement automatisés pour contourner les garde-fous et les limites de facturation des plateformes d'IA commerciales. Il cite la militarisation en février des compétences d'agents OpenClaw documentée par VirusTotal, des compromissions de la chaîne d'approvisionnement en mars que Mandiant attribue à l'acteur qu'elle suit sous le nom d'UNC6780 et que d'autres suivent sous celui de TeamPCP, ainsi qu'une divulgation de mai que GTIG a décrite comme le premier cas publiquement confirmé d'un cybercriminel utilisant un exploit zero-day développé par l'IA, lequel a contourné l'authentification à deux facteurs dans un outil d'administration open source populaire.

Cas un : l’assistant a recommandé le paquet

Dans le premier cas, un attaquant a compromis un fournisseur de logiciel en tant que service, puis a pris le contrôle d’une session active d’assistant de codage IA sur le poste de travail d’un développeur. Mandiant décrit l’assistant comme « opérant comme un interpréteur de confiance au sein de l’environnement » : il a recommandé l’installation d’un paquet logiciel externe que l’attaquant avait déjà empoisonné, et le développeur a accepté la recommandation. Le rapport indique que l’assistant « a involontairement fait office de cheval de Troie ».

Lors de la session en direct, l'attaquant a installé un infostealer via un paquet PyPI empoisonné et récupéré les jetons OAuth GitHub du développeur. Le ver auto-propageant Shai-Hulud s'est ensuite déplacé à travers environ 100 dépôts de code internes, automatisant le vol de secrets de dépôt et l'exfiltration programmatique du code source de produits propriétaires. L'attaquant a également empoisonné un paquet dans l'espace de noms officiel de l'organisation, et un second employé a récupéré la version compromise — une infection en aval qui, selon Mandiant, n'a nécessité aucune action supplémentaire de l'intrus.

Ce que le rapport ne dit pas, c’est quand l’un ou l’autre de ces événements s’est produit, ni comment l’attaquant a pris le contrôle de la session de l’assistant au départ. The Hacker News, qui a rapporté l’étude de cas le 16 septembre, relève ces deux omissions. La note de recherche du 18 septembre de la Cloud Security Alliance sur ce cas qualifie le vecteur d’accès initial de « question ouverte la plus importante de l’étude de cas » et fait observer que les contrôles recommandés par Mandiant concernent la distance qu’une infection peut parcourir, et non la manière dont la session a été détournée.

Les trois mesures de contrôle de Mandiant pour ce cas sont précises quant à la défaillance : imposer des hooks de vérification dans l’IDE et la CLI qui contrôlent chaque dépendance tierce recommandée par l’IA par rapport à des sommes de contrôle cryptographiques et à une liste d’autorisation approuvée ; garder les clés d’API brutes, les jetons OAuth de longue durée et autres secrets hors de portée des extensions ; et restreindre les sorties réseau des postes de travail afin que le trafic de dépendances ne passe que par des dépôts internes contrôlés.

Cas deux : un identifiant CI/CD transformé en hub de co-débogage IA

Le deuxième cas concerne une enquête sur le cloud d’entreprise menée au sein d’une organisation mondiale de santé. Mandiant a retracé une activité anormale jusqu’à un identifiant CI/CD de développeur compromis et de longue durée, que l’intrus a utilisé pour créer une instance de VM non isolée et la transformer en un hub offensif actif. Plutôt que de construire des outils hors ligne, l’attaquant a connecté directement de grands modèles de langage au serveur en cours d’exécution et les a sollicités de manière itérative sur place.

Mandiant décrit un flux de travail en trois étapes. Vient d’abord l’amorçage du contexte : des paquets de code synchronisés via des sessions distantes et des fichiers README de projet chargés dans le contexte de chat du modèle, afin d’orienter la génération de code ultérieure vers les objectifs de la campagne. Puis le débogage interactif : l’attaquant a fait construire au modèle un framework de collecte de données multi-worker et a résolu avec lui des erreurs logiques de découpage de scripts, portant la cadence d’exfiltration à un cycle de trois heures. Enfin, l’évasion et l’exploitation : le modèle a écrit des scripts dynamiques de rotation d’IP pour permuter à la volée des adresses de serveurs sur liste noire, et a co-développé un outil basé sur Rust pour se connecter aux comptes des victimes et vérifier les soldes financiers.

Mandiant affirme que la campagne a compromis des milliers d’identifiants et exfiltré des clés API et des secrets financiers collectés vers un dépôt contrôlé par l’attaquant. Le rapport ne précise pas à quels comptes l’outil Rust était dirigé, à qui appartenaient les soldes financiers qu’il vérifiait, ni ce qu’il est advenu des identifiants par la suite. Aucune donnée de patient n’est mentionnée nulle part dans l’étude de cas.

Les contrôles recommandés portent sur le justificatif d’accès plutôt que sur le modèle : remplacez les clés d’accès à longue durée de vie par des relations de confiance Workload Identity Federation à courte durée de vie utilisant OIDC ; limitez les flux sortants avec VPC Service Controls afin que les environnements d’exécution et de développement ne puissent pas atteindre des fournisseurs de modèles externes non approuvés ; exécutez une analyse continue des secrets sur l’ensemble des espaces de travail ; et placez un pare-feu de prompts à l’exécution, tel que Model Armor, sur le chemin pour intercepter les identifiants codés en dur et bloquer les scripts utilitaires offensifs au moment de leur exécution.

Cas trois : l’agent qui a dépensé 50 000 $ en moins d’une heure

Le troisième cas n’avait aucun adversaire. Un prestataire mondial de services financiers aux entreprises a déployé un agent pour rapprocher les anomalies de son grand livre comptable et lui a accordé un accès en lecture et en écriture aux bases de données de facturation internes. Une valeur nulle corrompue a cassé l’outil de formatage de l’agent, et l’agent a réagi en entrant dans ce que Mandiant appelle une boucle de raisonnement récursive et non contrainte pour trouver une correction par force brute.

En moins d’une heure, il a émis plus de 15 000 appels d’API de raisonnement à haute fréquence et à coût élevé, provoquant un pic soudain de facturation cloud d’environ 50 000 $. La même boucle a causé un grave verrouillage de la base de données locale qui a interrompu des transactions métier en cours. Mandiant classe ce cas sous « denial-of-wallet », et les correctifs qu’elle prescrit sont opérationnels plutôt qu’au niveau du modèle : un plafond de dépenses, une récursion bornée et un disjoncteur pour arrêter un agent qui échoue continuellement à la même tâche.

Le rapport ne précise pas si les frais ont été payés, crédités ou contestés, pendant combien de temps les transactions ont été interrompues, si des clients ont été touchés, ni ce que l’entreprise a modifié par la suite. Il ne donne pas non plus de date. Le récapitulatif du 18 septembre de SecurityWeek le classe dans ce que le rapport signale comme une nouvelle catégorie de risque financier plutôt que comme une intrusion conventionnelle.

Les contrôles proposés par Mandiant sont eux aussi de nature financière : des définitions d’identité et d’accès fondées sur les rôles pour les agents, des seuils de plafonnement des coûts et une surveillance comme gouvernance, ainsi que des disjoncteurs financiers automatisés qui arrêtent un agent après un nombre défini d’échecs consécutifs de tâches. Au niveau des services et des projets, il recommande des plafonds financiers stricts, des limites de récursion bornées et des limites de débit, afin qu’une boucle d’auto-correction soit bridée avant de devenir une panne.

Ce qui est établi, ce qui est attribué, ce qui n'est pas divulgué

Établi. Mandiant a publié ce rapport, et il dit ce qui est résumé ci-dessus. Quatre médias spécialisés en ont rendu compte à trois jours d'intervalle — Help Net Security et The Hacker News le 16 septembre, SecurityBrief UK le 17 septembre et SecurityWeek le 18 septembre — et leurs comptes rendus concordent avec le rapport sur chaque chiffre qu'ils reprennent. La Cloud Security Alliance a publié une note de recherche distincte sur le premier cas le 18 septembre, parvenant à la même lecture de son mécanisme et à la même conclusion sur ce que Mandiant a omis.

Attribué, non vérifié de manière indépendante. Les chiffres précis sont ceux de Mandiant : environ 100 dépôts, des milliers d'identifiants, un cycle d'exfiltration de trois heures, plus de 15 000 appels de raisonnement, environ 50 000 dollars, en moins d'une heure. Aucun média n'a publié de télémétrie provenant de l'une des trois victimes, et aucune des trois n'a été nommée par qui que ce soit. La corroboration qui existe est une corroboration du contenu du rapport, non des événements. Cette distinction est tout ce sur quoi un lecteur peut s'appuyer ici, et la note de confiance de l'archive doit être lue de la même manière.

Non divulgué. Le rapport ne donne aucune date pour aucun des trois mandats, aucun nom de victime et aucun récit de la manière dont la session de l’assistant dans le premier cas a été prise de contrôle. Il ne précise pas si les jetons OAuth GitHub et les secrets de dépôt récoltés ont été révoqués, si les milliers d’identifiants du deuxième cas ont été utilisés ou réinitialisés, si les personnes concernées de l’organisation de santé ont été affectées, si les frais de l’agent comptable ont été récupérés, ni ce que chacune des trois organisations a modifié par la suite. Cet article n’a trouvé aucune déclaration de victime, aucun avis de régulateur ni aucun reportage de suivi publié depuis le 16 septembre qui comble ces lacunes.

Là où les comptes rendus divergent. La note de la Cloud Security Alliance décrit la deuxième infection du cas un comme s'étant propagée via l'espace de noms npm propre à l'entreprise. Le texte de Mandiant indique seulement « un paquet à l'intérieur de l'espace de noms officiel de l'organisation » et n'y nomme aucun écosystème ; l'interprétation npm est un ajout, pas une citation. Séparément, The Hacker News précise explicitement que, selon les éléments disponibles, le ver de ce cas n'est lié ni au ver npm d'août qui a implanté des hooks pour les assistants de codage, ni à une variante de Shai-Hulud découverte en train de scanner 469 emplacements à la recherche d'identifiants — même nom de famille, campagnes distinctes, sans aucun élément dans l'article qui les relierait.

Ce que dit le rapport devrait changer

Les recommandations de Mandiant reviennent d'une étude de cas à l'autre dans le rapport : abandonner les identifiants à longue durée de vie et les comptes de service au profit d'identités liées à une charge de travail et à durée de vie courte par conception ; traiter les assistants de codage IA et les serveurs MCP comme des sessions privilégiées dont les extensions et les hooks CLI sont vérifiés avant exécution ; enfermer les charges de travail des agents dans des périmètres réseau qui bloquent le trafic sortant vers des fournisseurs de modèles non approuvés ; et instrumenter l'usage des jetons, les appels d'API inter-applications et l'accès des agents aux actifs sensibles afin qu'une première lecture d'un dépôt sensible apparaisse comme un signal plutôt que de se fondre dans le trafic légitime des outils.

Sur le coût, il trace une ligne de démarcation entre la gouvernance de l'IA et la gouvernance pour l'IA : d'un côté les politiques qui définissent l'appétit pour le risque et les règles d'achat, de l'autre les limites techniques effectivement appliquées. L'agent comptable est l'exemple donné par le rapport de l'échec de la seconde catégorie : selon Mandiant, rien dans son déploiement ne bornait la boucle, et les contrôles qui l'auraient détectée — un plafond, une limite de débit, un disjoncteur — sont des contrôles ordinaires appliqués à une charge de travail inhabituelle.

Les trois {{1}}cas{{/1}} n'ont pas de {{2}}cause{{/2}} commune. L'un est un problème de confiance, où la recommandation d'un {{3}}assistant{{/3}} portait l'autorité de celle d'un {{4}}collègue{{/4}}. L'autre est un problème d'{{5}}identifiants{{/5}} qui précède tout {{6}}modèle{{/6}}, les modèles rendant l'{{7}}intrusion{{/7}} plus rapide et plus adaptative une fois à l'intérieur. Le troisième n'est ni l'un ni l'autre : aucun attaquant, aucun exploit, juste un {{8}}agent{{/8}} doté d'un {{9}}accès en écriture{{/9}} à un {{10}}registre{{/10}} et sans plafond sur ce qu'il pouvait dépenser pour réparer un outil défaillant. Ce qu'ils ont en commun, c'est que dans chacun, le système d'IA disposait d'une autorité que personne n'avait délimitée — celle de recommander, de reconfigurer, de continuer d'essayer.