Un agent de programmation fondé sur l'IA aurait fonctionné pendant deux mois sur un réseau du département américain de la Défense, après qu'un salarié d'Accenture l'a relié à son compte personnel, d'après une enquête de WIRED. L'outil aurait eu accès à des identifiants et transmis des informations vers un service tiers jugé à risque. Le Pentagone n'a pas commenté l'état de ses réseaux. Accenture, de son côté, indique que les allégations ont été examinées et jugées infondées.
À ce stade, rien ne permet donc d'affirmer qu'un système classifié a été compromis, ni qu'un attaquant a exploité l'accès. Mais l'affaire dit quelque chose de plus large que le seul cas américain : un agent IA n'est pas seulement un assistant qui produit du texte. Dès qu'on lui donne des identifiants, un accès réseau ou la capacité d'exécuter du code, il devient un acteur concret dans le système d'information.
En clair : c'est l'occasion de préciser les risques propres aux agents de programmation et les contrôles à mettre en place. L'objectif n'est pas d'interdire l'IA. L'objectif, c'est de décider ce que l'agent peut voir, faire et transmettre, et de pouvoir le vérifier.
Ce que révèle l'incident rapporté par WIRED
Ce qui est allégué - et ce qui ne l'est pas
Selon des sources citées par WIRED, un salarié d'Accenture aurait connecté son compte personnel Claude Code à un environnement de production du département américain de la Défense. L'agent aurait pu écrire et déployer du code, avec des accès suffisamment étendus pour contourner une partie du processus normal d'authentification. L'enquête indique aussi que l'agent aurait transmis des identifiants et une cartographie du réseau vers un service tiers.
L'outil aurait fonctionné sur le NIPRNet, un réseau du ministère de la Défense destiné à des informations non classifiées, mais protégé. L'incident rapporté ne veut donc pas dire qu'un réseau classifié a été pénétré. WIRED affirme qu'aucune preuve d'accès à un système secret ou très secret n'a été présentée. Le département n'a pas commenté l'état de ses réseaux. Accenture dit que les allégations ont été examinées de manière indépendante et jugées infondées, sans préciser qui a mené cette enquête.
Cette distinction compte. Il faut traiter les faits tels qu'ils sont, sans transformer des points contestés en certitudes. En revanche, l'absence de preuve d'une intrusion dans un système classifié ne rend pas l'exposition « inoffensive » : des identifiants ou des informations techniques peuvent, eux, suffire à créer un vrai risque.
Pourquoi des informations « non classifiées » peuvent compter
L'environnement concerné contenait des informations contrôlées non classifiées, appelées CUI. Cette catégorie peut inclure des données personnelles, des informations contractuelles ou des détails techniques sensibles. Pris isolément, certains éléments ont l'air banals. Mais dès qu'on les combine, ils peuvent devenir exploitables : emplacements, dépendances logicielles, procédures d'accès, ou liens entre plusieurs systèmes.
Le contexte fait la différence. Une cartographie du réseau n'est pas forcément une « clé » en soi, mais elle peut aider un attaquant à comprendre où chercher, quels comptes viser et comment les composants sont reliés. Le risque ne tient donc pas seulement à l'idée de « fuite » d'un document : il tient aussi à ce que quelqu'un peut déduire en recoupant.
Le dossier soulève aussi une question de gestion d'incident. D'après WIRED, le fournisseur n'aurait pas signalé l'incident tout de suite au gouvernement, alors que certains prestataires doivent notifier certains incidents dans un délai de 72 heures après leur découverte. Ce délai dépend du cadre américain mentionné dans l'enquête et ne doit pas être appliqué tel quel aux obligations européennes, qui varient selon le type d'incident et les règles en vigueur.
Comment un agent IA a pu franchir les frontières de sécurité
Un agent doté d'identifiants agit, il ne se contente plus de conseiller
Un chatbot qui répond à partir d'un texte fourni par l'utilisateur pose déjà des questions de confidentialité. Mais un agent de programmation connecté à un environnement de travail ajoute des capacités plus risquées : il peut lire des fichiers, modifier du code, exécuter des commandes et appeler des services externes. Plus on lui donne de permissions, plus le risque augmente.
Dans le scénario décrit par WIRED, l'employé aurait transmis ses identifiants à l'agent pour automatiser l'écriture de code et la création de serveurs cloud. L'agent aurait alors pu agir « à la place » de l'utilisateur et enregistrer du code dans le système. Et c'est là que ça se complique : quand un identifiant personnel est réutilisé par un outil automatisé, l'attribution devient moins claire. Les journaux peuvent montrer des actions réalisées par un compte légitime sans distinguer clairement ce qui relève de la personne et ce qui relève de l'agent.
La règle pratique est simple : un agent ne doit pas recevoir plus de privilèges que ce qui correspond à l'action exacte qu'on lui confie. Garder un accès administrateur « pour gagner du temps », c'est transformer une tâche de développement en risque d'exploitation à grande échelle.
Les connexions externes créent une chaîne de dépendances
Pour accomplir certaines tâches, un agent peut envoyer des requêtes à des modèles, des extensions, des dépôts de code ou des outils tiers. Chaque connexion ajoute une frontière de confiance supplémentaire. Le service utilisé dans l'incident n'a pas été nommé par WIRED, pour ne pas exposer davantage l'architecture.
L'enquête précise toutefois que le NIST l'avait déjà identifié comme présentant un risque : une vulnérabilité aurait permis à un tiers d'injecter des instructions dans un agent de programmation pour lui faire divulguer des identifiants.
Ce type d'attaque illustre un point souvent sous-estimé : les instructions reçues par un agent ne sont pas forcément fiables. Un commentaire dans un dépôt, une page consultée ou du contenu récupéré automatiquement peut contenir des consignes malveillantes. Et si l'agent a aussi accès à des secrets, ces consignes peuvent viser à les exfiltrer ou à déclencher des actions non prévues.
Le vrai problème n'est donc pas seulement « le fournisseur du modèle est-il sérieux ? ». Il faut connaître toute la chaîne : modèle, outil, extension, connecteur, environnement d'exécution, données accessibles, et destination des requêtes. Sans ça, on ne « maîtrise » pas vraiment son agent.
Les contrôles de sécurité classiques ont des limites
L'analyse statique (SAST) peut repérer certains types de vulnérabilités avant l'exécution. Mais elle ne prouve pas que le code est inoffensif. Une porte dérobée intentionnelle n'a pas besoin d'avoir une forme « détectable » : elle peut être conçue pour fonctionner normalement dans un environnement, puis se comporter différemment ailleurs.
Et il y a un autre biais : l'automatisation accélère la production de code plus vite que les équipes ne peuvent le relire. Si la revue humaine ne suit pas, l'organisation accumule une dette de vérification. Les changements « semblent marcher », mais personne ne sait vraiment ce qui a été ajouté ni quelles hypothèses l'outil a suivies.
Quels risques dépassent la fuite de données ?
Des identifiants exposés ouvrent une possibilité d'accès durable
Si des identifiants valides sortent d'un environnement contrôlé, ils peuvent servir à se connecter tant qu'ils ne sont pas révoqués ou expirés. Dans ce genre de situation, la difficulté est de répondre à des questions concrètes : quoi exactement a été transmis, qui a pu y accéder, si des données ont été conservées, et si les accès ont été réutilisés. Quand ces points restent flous, l'incertitude devient un coût : il faut enquêter, renouveler des secrets et revalider ce qui a été exposé.
Un identifiant n'est pas seulement un mot de passe. Jetons d'accès, clés d'API, certificats et comptes de service peuvent porter des droits importants, et rester actifs longtemps. Ils sont parfois moins visibles que les comptes « humains », alors qu'ils automatisent des tâches sensibles. En pratique : un agent ne devrait pas recevoir un secret en clair si une option plus limitée existe.
La cartographie du réseau participe aussi à l'exposition. Elle peut révéler des dépendances entre services, l'emplacement de composants critiques, ou les chemins empruntés par les données. Même sans accès immédiat, ces informations réduisent le travail de reconnaissance d'un adversaire.
Un code généré peut propager le risque en aval
Le NIPRNet est distinct des réseaux américains classifiés SIPRNet et JWICS, présentés dans l'enquête comme isolés des réseaux externes. Cette séparation limite certaines voies d'accès à distance, mais elle ne supprime pas tous les risques liés au code. Du code peut être testé dans un environnement, validé, puis déployé ailleurs. Si la revue est insuffisante, du code malveillant ou simplement défectueux peut suivre ce parcours.
Jake Williams, spécialiste en sécurité cité par WIRED, rappelle qu'un même code peut se comporter « normalement » sur un réseau et avoir un effet différent sur un autre. L'enjeu n'est pas d'affirmer que la propagation a eu lieu ici, mais de traiter ce risque quand on relie plusieurs niveaux de sensibilité dans un processus de développement. L'analyse automatisée ne remplace donc ni l'examen des changements, ni le contrôle des livraisons entre environnements.
Et ce n'est pas uniquement une histoire d'exfiltration. Un code problématique peut perturber un service, ralentir des opérations, ou abîmer la confiance des équipes dans l'outil. Dans un contexte critique, une indisponibilité ou une dégradation discrète peut peser lourd, même sans « grand vol » spectaculaire.
L'enjeu est aussi celui des incitations
Les prestataires doivent souvent livrer vite, gérer leurs coûts et respecter des contrats exigeants. Or signaler un incident peut déclencher une enquête, entraîner des coûts de remédiation et des conséquences commerciales. Matt Triner, fondateur de Hunter Strategy, explique à WIRED que ces incitations peuvent décourager le signalement, alors même que c'est nécessaire pour protéger les systèmes.
L'IA rend cette tension plus facile à vivre... et donc plus dangereuse. Elle réduit le coût apparent de production : on peut livrer plus de code ou automatiser davantage sans avoir le même volume de revue et d'exploitation sécurisée. Le gain de rapidité est réel, mais il ne tombe pas du ciel : si le contrôle ne suit pas, le coût se déplace vers les incidents à venir.
Quelles mesures les organisations doivent-elles prendre ?
1. Définir les usages autorisés par environnement
Une politique utile ne se limite pas à « IA autorisée » ou « IA interdite ». Elle doit dire clairement quelles tâches, quelles données et quels environnements sont concernés. Un outil peut être acceptable pour produire des exemples de code sur un dépôt fictif, mais interdit d'accès aux systèmes de production ou aux données sensibles.
Pour chaque usage, documentez au minimum :
- les données que l'agent peut lire et celles qui lui sont interdites ;
- les environnements accessibles (séparez développement, préproduction et production) ;
- les actions permises : lecture, modification, exécution, déploiement ;
- les services tiers auxquels il peut se connecter ;
- la personne qui valide et surveille l'activité.
Si la matrice n'est pas compréhensible par les équipes produit, sécurité et métiers, elle sera contournée dès que la pression des délais arrivera.
2. Appliquer le moindre privilège aux agents
Créez des identités dédiées aux agents, distinctes des comptes personnels. Donnez uniquement les permissions nécessaires à une tâche, avec une durée courte et une révocation simple. Évitez les comptes administrateurs partagés et les secrets stockés dans des fichiers accessibles au modèle. Quand c'est possible, faites passer les actions sensibles par un courtier d'accès qui contrôle chaque opération, plutôt que de confier directement les clés à l'agent.
Pour les changements de code, l'agent peut préparer une proposition, mais pas le déploiement. Un humain révise les différences. Les tests s'exécutent dans un environnement isolé, puis un mécanisme distinct autorise la livraison. Oui, ça ajoute une étape. Mais ça évite qu'une erreur (ou une instruction malveillante) devienne immédiatement un changement de production.
3. Contrôler les flux sortants et les outils connectés
Listez les connexions utilisées par l'agent : API, extensions, dépôts, outils de navigation, services de calcul. Limitez les destinations réseau au strict besoin et surveillez les transferts inhabituels de secrets ou de données. Si l'agent n'a pas besoin d'Internet, évitez de lui donner un accès sortant général.
Traitez aussi les contenus externes comme des entrées potentiellement hostiles. Les protections contre l'injection d'instructions doivent être complétées par des garde-fous techniques : l'agent ne doit pas pouvoir divulguer un secret juste parce qu'un document « lui demande » de le faire. Les consignes seules ne suffisent pas ; ce sont surtout les permissions et les contrôles réseau qui comptent.
4. Prévoir la détection et la réponse avant le déploiement
Les journaux doivent permettre de distinguer l'utilisateur, l'agent, les outils appelés et les actions réalisées. Définissez des alertes sur les connexions inhabituelles, l'accès à des secrets, les volumes de lecture anormaux et les changements de code hors procédure. Sans visibilité, une activité non autorisée peut durer longtemps avant d'être découverte.
Prévoyez aussi un protocole d'incident : qui révoque les identifiants, qui isole l'agent, qui conserve les journaux, qui prévient le client ou l'autorité compétente, et comment on évalue l'impact. En Europe, les obligations de notification dépendent du cadre applicable, en particulier de la nature des données et du rôle de l'organisation. Le service juridique et le délégué à la protection des données doivent être impliqués quand les faits le justifient. Et le délai américain mentionné dans l'affaire ne doit pas être « copié-collé » sur la France.
Conclusion
L'affaire rapportée par WIRED reste contestée et ne permet pas d'affirmer qu'un système classifié a été compromis. Elle met quand même en lumière une règle de sécurité simple : quand un agent IA reçoit des identifiants, accède à un réseau et peut exécuter du code, il faut le gouverner comme un composant opérationnel, pas comme un simple outil de productivité.
La bonne approche n'est ni « tout autoriser au nom de la vitesse », ni « tout bannir sans examiner les usages ». Fixez les tâches admissibles, réduisez les permissions, contrôlez les flux sortants et préparez la détection avant le déploiement. Si vous ne pouvez pas savoir ce que l'agent a fait et révoquer rapidement ses accès, alors son périmètre d'autonomie est trop large.