Quand l’IA Devient la Red Team : Ce que l’Affaire NSA-Mythos Révèle sur la Sécurité de Votre Entreprise
Une seule phrase a voyagé d’un directeur d’agence de renseignement à un discours au Sénat, puis à un article de magazine, avant de faire le tour des réseaux sociaux mondiaux — et à son arrivée, elle était passée d’un argument politique à une alerte géopolitique : l’IA aurait piraté la NSA.
En réalité, l’histoire s’est révélée à la fois moins spectaculaire et plus inquiétante que la version virale. Moins spectaculaire, car le modèle Mythos d’Anthropic fonctionnait dans une réplique des systèmes de la NSA lors d’un exercice red team autorisé, aux côtés d’autres outils de sécurité, avec des ingénieurs présents. Plus inquiétante, car la capacité démontrée — découvrir et enchaîner des vulnérabilités dans un environnement classifié complexe en quelques heures au lieu de plusieurs semaines — est bien réelle, documentée et de plus en plus accessible à des organisations vérifiées dans le monde entier.
Cette distinction est essentielle pour la façon dont les entreprises envisagent leur posture de sécurité. La question n’est pas de savoir si Mythos a compromis la NSA. La vraie question est de comprendre ce que cela implique qu’une IA puisse détecter chaque faiblesse d’un système comme celui de la NSA plus vite que n’importe quelle équipe humaine — et ce que votre organisation doit faire dès maintenant.
Points clés à retenir
1. L’histoire « L’IA a piraté la NSA » était un exercice red team, pas une compromission réelle
Le modèle Mythos d’Anthropic a été utilisé avec d’autres outils dans une réplique de l’environnement NSA lors d’un test de sécurité autorisé — la version virale était une déformation, mais la capacité sous-jacente démontrée est bien réelle et lourde de conséquences.
2. L’IA enchaîne les vulnérabilités à la vitesse de la machine
Ce que les équipes red team humaines mettent des semaines à accomplir, les systèmes assistés par IA l’ont réalisé en quelques heures — découvrant et reliant plusieurs chemins d’attaque dans une réplique d’environnement classifié complexe, à une vitesse inédite dans la sécurité offensive.
3. Les capacités défensives et offensives de l’IA sont indissociables
La NSA a utilisé Mythos pour analyser son propre environnement à la recherche de faiblesses avant que des adversaires ne les trouvent — la même capacité d’IA qui menace la posture de sécurité des entreprises est celle qui peut la défendre, à condition qu’elle fonctionne dans un cadre gouverné et contrôlé.
4. L’accès non gouverné de l’IA aux données sensibles est le véritable risque de sécurité
Les entreprises qui donnent aux systèmes d’IA un accès illimité à leurs référentiels sensibles créent exactement l’exposition que les red teams autorisées exploitent — la gouvernance des données IA en mode zero trust est la réponse architecturale, pas une interdiction totale de l’IA.
5. Les cadres de conformité du secteur de la défense montrent déjà la voie
L’autorisation FedRAMP, la certification CMMC 2.0 et la conformité DFARS imposent un accès contrôlé et audité aux données sensibles au niveau de chaque requête — c’est le modèle que chaque entreprise devrait appliquer aux systèmes d’IA traitant des données sensibles.
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?
Pour en savoir plus :
Ce qui s’est réellement passé — et pourquoi la clarification est importante
Tout a commencé avec le directeur de la NSA et chef de l’U.S. Cyber Command, le général Joshua Rudd, qui a déclaré au sénateur Mark Warner que Mythos « a franchi presque tous nos systèmes classifiés en quelques heures, pas en semaines ». Le sénateur Warner a cité cette déclaration lors d’une session de la commission du renseignement du Sénat pour défendre l’idée de tests obligatoires avant la sortie des modèles d’IA de pointe — son propos était que les entreprises d’IA comme Anthropic devraient pouvoir « aller à fond » dans le développement des capacités, précisément parce que leurs pratiques de sécurité rigoureuses rendent possible ce type de test contrôlé.
Shashank Joshi, de The Economist, a repris la citation dans un briefing de juin 2026 sur la politique américaine en matière d’IA. À partir de là, la phrase a totalement perdu son contexte. Lorsqu’elle a atteint les réseaux sociaux à grande échelle, « exercice red team autorisé sur une réplique d’environnement classifié » était devenu « l’IA a compromis les systèmes actifs de la NSA ». Joshi a ensuite reconnu sur les réseaux sociaux qu’il aurait dû apporter plus de précisions, soulignant que l’exploit avait été réalisé dans des conditions spécifiques, avec d’autres outils. L’analyste en sécurité Kyle Chase et d’autres connaissant le fonctionnement des exercices red team ont rapidement réagi publiquement contre cette version virale.
La reconstitution la plus crédible — confirmée par des professionnels de la sécurité et corroborée par Axios sur l’utilisation réelle de Mythos par la NSA — est que la NSA a placé le modèle dans une réplique de son environnement classifié et lui a demandé de détecter et d’enchaîner les vulnérabilités. Il l’a fait à une vitesse bien supérieure à celle des équipes red team humaines. Parler de compromission des systèmes actifs de la NSA revient à écrire « bâtiment en feu » après un exercice incendie. L’exercice révèle ce qui se passerait si l’incendie était réel. C’est précisément ce qui compte.
Le véritable enseignement : la découverte de vulnérabilités par l’IA n’est plus théorique
Oubliez le titre. Ce que démontre l’exercice, c’est un changement réel du paysage de la sécurité. Les menaces persistantes avancées que les défenseurs tentent de détecter depuis des années disposent désormais d’outils d’IA capables d’accélérer chaque phase d’une attaque — reconnaissance, identification des vulnérabilités, enchaînement des chemins d’attaque et mouvements latéraux — bien au-delà de ce que les analystes humains peuvent suivre.
Trois catégories de capacités sont les plus pertinentes pour les équipes de sécurité des entreprises.
Découverte de vulnérabilités à grande échelle. Les red teamers humains identifient les vulnérabilités manuellement, système par système. Les outils assistés par IA peuvent analyser des environnements dans leur ensemble, détectant les erreurs de configuration, les CVE non corrigées et les failles logiques sur des milliers d’actifs en même temps. L’avantage de vitesse n’est pas marginal. Il s’agit d’un changement de catégorie.
Raisonnement sur les chemins d’attaque. Trouver une vulnérabilité isolée est une chose. Enchaîner plusieurs vulnérabilités pour créer un chemin d’attaque viable qui contourne les défenses en couches exige un raisonnement sophistiqué sur la topologie réseau, les autorisations d’accès et les interdépendances systèmes. Les modèles d’IA entraînés sur la recherche en sécurité, les bases d’exploits et la documentation système peuvent raisonner sur ces chaînes comme seuls les ingénieurs red team expérimentés le faisaient auparavant.
Tests itératifs en environnement contrôlé. Mythos n’a pas opéré sur des systèmes actifs — il a travaillé sur une réplique. C’est exactement ainsi que fonctionnent les programmes de détection de vulnérabilités responsables : déployer un environnement, le tester de façon intensive, identifier les failles avant les adversaires. La même capacité d’IA démontrée lors de l’exercice NSA est utilisée aujourd’hui par environ 150 institutions dans plus de 15 pays via le programme Project Glasswing d’Anthropic. Ces institutions ont identifié collectivement plus de 10 000 vulnérabilités critiques ou majeures dans leurs propres environnements.
Ce dernier chiffre mérite d’être souligné. Les agences gouvernementales, les institutions financières et les entreprises technologiques utilisent déjà la détection de vulnérabilités assistée par IA pour renforcer leur propre infrastructure. La capacité red team n’est pas à venir. Elle est déjà déployée.
Ce que cela implique pour la sécurité des données en entreprise
L’exercice de la NSA clarifie un point que les équipes de sécurité traitaient comme un problème futur : le risque IA est un enjeu de sécurité immédiat qui exige une réponse architecturale, pas un simple élément de roadmap.
La question centrale, c’est l’accès. Les systèmes d’IA capables de détecter et d’enchaîner des vulnérabilités ont besoin de données — données de configuration, topologie réseau, code, logs, documentation. Plus un système d’IA a accès aux référentiels de données de l’entreprise, plus il devient dangereux en cas de mauvaise utilisation ou de compromission. À l’inverse, un système d’IA bien gouverné, avec un accès restreint et audité, est exactement ce dont les organisations ont besoin pour détecter les vulnérabilités de leur propre infrastructure avant les attaquants. La classification des données est le prérequis : une organisation incapable d’identifier quels référentiels contiennent des données sensibles ne peut pas imposer les limites d’accès qu’exige la gouvernance IA.
C’est là que l’architecture zero trust prend tout son sens. Les modèles de sécurité traditionnels accordent aux systèmes d’IA un accès large dès qu’ils s’authentifient — on suppose que si un système est autorisé à se connecter, il peut tout voir dans son périmètre. L’exercice de la NSA a démontré pourquoi cette hypothèse est dangereuse. Un système d’IA ayant accès à un environnement complexe peut l’explorer dans son ensemble en quelques heures.
La protection des données en mode zero trust inverse ce modèle. Ne faites jamais confiance à l’identité ou à l’intention d’un système d’IA. Vérifiez toujours au niveau de chaque requête. Chaque opération est authentifiée, évaluée selon la politique, et enregistrée avant que la donnée ne soit renvoyée. La question n’est pas de savoir si un système d’IA a été authentifié une fois à la connexion — mais si chaque opération de données effectuée par l’IA est autorisée, conforme à la politique et traçable avec attribution complète.
Pour les entreprises qui gèrent des référentiels de données sensibles — données clients réglementées, propriété intellectuelle, dossiers médicaux, informations de défense — le principe architectural est clair : les systèmes d’IA ont besoin d’un accès gouverné, pas d’un accès libre. La capacité qui rend l’IA dangereuse comme outil red team est la même qui la rend utile pour la défense. La différence, c’est le contrôle.
La couche de données IA gouvernée dont votre organisation a besoin
Les mêmes principes appliqués par la NSA lors de son exercice red team — accès contrôlé, périmètre restreint, opérations surveillées — sont accessibles aux entreprises via des plateformes IA gouvernées. La gouvernance des données IA consiste à veiller à ce que les systèmes d’IA n’accèdent qu’aux données pour lesquelles ils sont explicitement autorisés, que chaque opération soit enregistrée avec attribution complète, et que l’application des politiques se fasse au niveau de chaque requête, et non à la connexion.
La Kiteworks AI Data Gateway propose un pont sécurisé entre les systèmes d’IA et les référentiels de données d’entreprise, permettant les workflows RAG (Retrieval-Augmented Generation) et autres opérations IA avec un accès aux données en mode zero trust. Chaque requête de données émanant d’un système d’IA est authentifiée, évaluée en temps réel selon les politiques ABAC, et enregistrée avant tout retour de données. Un système d’IA passant par l’AI Data Gateway ne peut pas accéder à des données pour lesquelles il n’a pas d’autorisation explicite. Les contrôles de minimisation des données garantissent que l’IA ne reçoit que le minimum nécessaire pour la tâche — le rate limiting empêche toute extraction massive même en cas de compromission du système d’IA.
Le Kiteworks Secure MCP Server étend cette gouvernance aux assistants IA interactifs comme Claude et Microsoft Copilot via le protocole standard Model Context Protocol. Les assistants IA qui gèrent des fichiers, interrogent des référentiels de documents ou automatisent des workflows le font avec la même application des politiques que l’accès humain — avec une authentification OAuth 2.0 stockant les identifiants dans le trousseau du système d’exploitation, jamais exposés au modèle d’IA lui-même.
Aucune de ces capacités ne considère l’IA comme un acteur de confiance une fois connectée. Toutes traitent les requêtes IA comme le fait l’architecture zero trust pour chaque type d’accès : non authentifiées et non autorisées jusqu’à preuve du contraire. Ce n’est pas une fonctionnalité. C’est le principe fondateur, et c’est exactement ce que démontre l’exercice de la NSA.
Ce que la conformité du secteur de la défense exige déjà
Les cadres de conformité du secteur de la défense existent précisément pour des scénarios comme celui révélé par l’exercice de la NSA. La conformité CMMC 2.0 impose aux sous-traitants de la défense de prouver un accès contrôlé aux CUI (Controlled Unclassified Information), avec des traces d’audit complètes et une application documentée des politiques sur tous les canaux de circulation des données. La conformité FedRAMP exige des contrôles de sécurité continus avec une surveillance en temps réel et des logs d’audit sans limitation de débit.
Ces cadres précèdent la vague actuelle de capacités IA. Mais leurs exigences correspondent directement au problème révélé par l’exercice Mythos. Si un système d’IA ayant accès à un référentiel CUI peut découvrir et enchaîner des vulnérabilités en quelques heures, alors tout sous-traitant de la défense sans gouvernance IA zero trust présente à la fois un déficit de conformité et un déficit de sécurité — un risque qu’un adversaire motivé pourrait exploiter avant qu’un analyste humain ne détecte une activité anormale.
La clause DFARS 252.204-7012 impose un reporting d’incident sous 72 heures pour les systèmes d’information couverts. L’ITAR impose des restrictions géographiques sur l’accès aux données techniques contrôlées. Ces obligations spécifiques autour de l’accès IA aux données ne sont pas encore toutes intégrées dans les politiques de gouvernance IA de la plupart des organisations. Le rapport prévisionnel 2026 de Kiteworks identifie les lacunes de gouvernance IA comme l’un des défis majeurs de sécurité à traiter à court terme — et l’histoire de la NSA en donne une illustration concrète et visible.
Les entreprises qui l’auront compris en premier — que la gouvernance IA n’est pas un problème d’IA mais un problème de sécurité des données, et que les cadres conçus pour les environnements les plus sensibles fournissent déjà le bon modèle — seront mieux positionnées, tant sur le plan concurrentiel que sécuritaire.
Partir du principe que l’IA sera utilisée contre vous — et s’y préparer
L’exercice de la NSA impose une discussion que les équipes de sécurité repoussaient. Le calcul de la réponse à incident a changé. « Partir du principe que l’on est déjà compromis » est un principe fondateur du zero trust depuis des années — il s’agit de concevoir les contrôles en considérant que les attaquants sont déjà à l’intérieur. L’exercice Mythos ajoute une variante : partir du principe d’une attaque assistée par IA.
Un attaquant disposant d’un modèle IA performant et d’un premier accès à votre environnement peut cartographier votre surface d’attaque, découvrir des vulnérabilités en chaîne et identifier des chemins vers vos données les plus sensibles bien plus vite que votre équipe sécurité ne peut réagir par analyse manuelle. Les systèmes de détection conçus pour repérer des mouvements latéraux à vitesse humaine risquent de ne pas réagir assez vite face à la rapidité de reconnaissance et d’exploitation de l’IA.
La réponse concrète est architecturale, pas réactive. Déployez l’échange de données zero trust sur tous les canaux de circulation des données sensibles. Veillez à ce que chaque système d’IA opérant sur des données d’entreprise voie ses accès évalués à chaque requête, pas seulement à la connexion. Maintenez des journaux d’audit complets et en temps réel, directement reliés à votre SIEM — sans limitation de débit, sans délai, sans nécessiter de licence premium pour accéder aux logs lors d’une enquête active.
La NSA a compris un point clé : on ne protège que ce que l’on voit, et on ne voit que ce que l’on journalise. Ce principe s’applique aussi à l’accès IA dans votre entreprise. Si un système d’IA interroge des centaines de documents sensibles en une heure, vous devez savoir ce à quoi il a accédé, ce qui a été retourné, sous quelle autorisation et via quelle politique. Sans cette visibilité, vos capacités de réponse à incident sont aveugles face à la catégorie d’attaque la plus rapide désormais en usage.
Les entreprises qui bâtissent aujourd’hui une infrastructure IA gouvernée — avant qu’un incident ne les y contraigne — pourront utiliser l’IA comme une véritable capacité défensive, et non comme un risque non quantifié. Une architecture de Réseau de données privé qui applique ces contrôles à chaque canal de communication de contenu — la messagerie électronique, le partage et le transfert de fichiers sécurisés, et les intégrations IA — garantit qu’aucun canal n’opère hors du périmètre de gouvernance.
Pour en savoir plus sur la gouvernance de l’accès IA à vos données sensibles avec l’architecture zero trust, réservez votre démo sans attendre.
Foire aux questions
Non. La déclaration largement relayée était une déformation d’un exercice red team autorisé. Le directeur de la NSA, le général Joshua Rudd, a déclaré au sénateur Mark Warner que Mythos « a franchi presque tous nos systèmes classifiés en quelques heures, pas en semaines » — mais le journaliste ayant publié la citation a ensuite précisé que l’exercice avait été mené sur une réplique des systèmes de la NSA, et non sur l’infrastructure opérationnelle réelle, et que Mythos avait été utilisé avec d’autres outils de sécurité. La nuance est essentielle : un exercice red team sur une réplique contrôlée est une pratique défensive standard, pas une compromission malveillante. La capacité démontrée — détecter et enchaîner des vulnérabilités à la vitesse de l’IA — est bien réelle et significative. Les entreprises doivent se concentrer sur ce que l’exercice révèle de la découverte de vulnérabilités assistée par IA, et non sur la véracité de la version virale. La gouvernance des données IA et les cadres zero trust generative AI existent pour répondre au risque réel mis en lumière par l’exercice. Les organisations souhaitant évaluer leur propre exposition doivent commencer par une analyse des risques de chaque système d’IA ayant accès à des référentiels de données sensibles.
Project Glasswing est le programme d’accès contrôlé d’Anthropic pour Mythos — son modèle d’IA le plus avancé. Parce que les capacités offensives du modèle sont jugées trop dangereuses pour une diffusion générale, Anthropic ne le distribue qu’à des organisations de défense et de sécurité vérifiées, sous conditions strictes. En juin 2026, le programme comptait environ 150 institutions dans plus de 15 pays. Ces organisations ont collectivement identifié plus de 10 000 vulnérabilités critiques ou majeures dans leurs propres environnements grâce à Mythos. Pour les équipes de sécurité en entreprise, Project Glasswing est un modèle de gouvernance : accès contrôlé, cas d’usage autorisés, périmètre restreint, opérations surveillées, et responsabilité explicite pour chaque requête. C’est cette architecture que les entreprises doivent appliquer à leurs déploiements IA. La Kiteworks AI Data Gateway met en œuvre ce modèle zero trust pour les workflows RAG et l’accès IA aux données, garantissant que les systèmes d’IA opèrent uniquement dans des limites explicitement autorisées, avec une traçabilité complète pour chaque opération. La même discipline de gestion des risques de sécurité qui régit les décisions d’accès à Project Glasswing doit encadrer chaque système d’IA accédant à des données sensibles d’entreprise.
L’exercice de la NSA montre que la capacité d’attaque assistée par IA doit désormais figurer dans les modèles de menace des entreprises comme un risque actuel, et non futur. Les équipes de sécurité doivent anticiper des adversaires capables de cartographier la surface d’attaque et d’enchaîner les vulnérabilités plus vite que les analystes humains ne peuvent répondre aux alertes. Cela implique que l’architecture défensive doit égaler la rapidité offensive. Les systèmes de détection doivent fournir des flux SIEM en temps réel, sans limitation de débit — des logs retardés sont inutiles pour contenir une intrusion à la vitesse de l’IA. L’architecture zero trust limite le rayon d’action si un attaquant obtient un premier accès, car les mouvements latéraux assistés par IA ne sont dangereux que dans la mesure des accès disponibles. L’application des politiques au niveau de chaque requête, plutôt qu’à la connexion, est le point de contrôle critique — chaque opération de données, y compris celles des systèmes d’IA, doit être évaluée et journalisée en temps réel. Les organisations doivent également revoir leur posture de gestion des risques supply chain, car les attaques assistées par IA ciblant les intégrations de fournisseurs tiers représentent un vecteur particulièrement risqué.
Les mêmes cadres qui régissent l’accès humain aux données sensibles s’appliquent à l’accès IA — et les régulateurs le rappellent de plus en plus clairement. Pour les sous-traitants de la défense, la conformité CMMC 2.0 impose un accès contrôlé aux CUI avec des traces d’audit complètes — des obligations qui s’étendent directement aux systèmes d’IA interrogeant ces données. FedRAMP exige des contrôles de sécurité continus et une surveillance en temps réel pour les services cloud fédéraux. La conformité HIPAA impose des mesures techniques pour l’accès aux informations médicales protégées, qu’il s’agisse d’un humain ou d’une IA. Le RGPD exige une base légale documentée pour tout traitement de données, y compris la récupération par IA. Concrètement, les organisations ne peuvent pas considérer l’accès IA aux données comme hors du périmètre de conformité. Chaque système d’IA interrogeant un référentiel sensible doit générer la même traçabilité et la même documentation d’application des politiques qu’un accès humain — et la plateforme Kiteworks produit automatiquement cette documentation pour chaque opération IA sur chaque canal. Les organisations gérant des obligations de gouvernance sur plusieurs cadres réglementaires constateront que l’infrastructure IA conforme fournit une couche d’application unifiée qui répond simultanément à plusieurs exigences.
Trois actions apportent le plus d’impact sécurité à court terme. Premièrement, réalisez un audit des accès IA aux données : identifiez chaque système d’IA de votre environnement pouvant interroger des référentiels sensibles, et vérifiez si ces requêtes sont encadrées par une application des politiques zero trust au niveau de chaque requête ou simplement par une authentification à la connexion. L’authentification à la connexion seule ne suffit pas. Deuxièmement, assurez-vous que vos journaux d’audit sont complets et en temps réel. Si un attaquant assisté par IA parcourt votre environnement en quelques heures, des logs retardés, limités ou incomplets ne permettront pas une réponse à incident à la vitesse requise. La protection des données zero trust exige une visibilité en temps réel — sans cela, aucune enquête efficace n’est possible. Troisièmement, mettez en place le même modèle de gouvernance que Project Glasswing : accès contrôlé, autorisation explicite, périmètre restreint et opérations surveillées pour chaque système d’IA accédant à des données sensibles. Le CISO Dashboard offre à la direction sécurité une visibilité unifiée et en temps réel sur tous les accès IA aux données, indispensable pour détecter des activités anormales à la vitesse des menaces assistées par IA. Kiteworks secure data exchange fournit l’infrastructure pour appliquer ces trois mesures immédiatement, avec un moteur de politique unique et un journal d’audit consolidé sur chaque canal et chaque intégration IA.
Ressources complémentaires
- Article de blog
Stratégies Zero Trust pour une protection abordable de la confidentialité IA - Article de blog
Comment 77 % des organisations échouent sur la sécurité des données IA - eBook
AI Governance Gap : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025 - Article de blog
Il n’existe pas de « –dangerously-skip-permissions » pour vos données - Article de blog
Les régulateurs ne se demandent plus si vous avez une politique IA. Ils veulent la preuve qu’elle fonctionne.