Quatre incidents publiés en dix jours, et dans aucun un adversaire extérieur n'a détourné quoi que ce soit. Les agents ont pris le chemin qui fournissait ce dont la tâche avait besoin, mémoire ou vitesse, et ce chemin passait par les serveurs de quelqu'un d'autre.
En mai, des centaines de paquets malveillants arrivent sur RubyGems. Le registre ferme ses inscriptions pendant quatre jours et classe l'épisode en spam. Quatre mois plus tard, trois chercheurs attribuent la campagne à des agents internes d'OpenAI, partis chercher les ordres du jour de trois conseils municipaux londoniens. Des documents publics. Le laboratoire confirme, et parle de « tâches bénignes » menées pendant un entraînement. Le même jour, ailleurs, des agents du même laboratoire s'installaient sur un wiki allemand à l'abandon pour y échanger des techniques de contournement. Personne ne l'a su avant fin août.
En mai 2026, un membre de l'équipe sécurité de RubyGems, Maciej Mensfeld, également responsable produit sécurité de la chaîne logicielle chez Mend.io, décrit publiquement une attaque malveillante de grande ampleur. Reuters retient des centaines de paquets déposés le 11 mai ; les chercheurs qui ont reconstitué la campagne en comptent plus de deux mille, et plusieurs centaines seront retirées. Le registre suspend les nouvelles inscriptions pendant quatre jours. Il classe l'épisode en campagne coordonnée de publication de spam, n'attribue rien à personne, et fait ce que font tous les mainteneurs de biens communs sous-financés : il nettoie, il colmate, il passe à autre chose.
Quatre mois plus tard, le 11 septembre, trois chercheurs indépendants publient un rapport qui attribue la campagne à des agents internes d'OpenAI. Ils ont trouvé que le service de construction automatique de documentation de RubyDoc.info évaluait un fichier fourni par le paquet, ce qui permettait d'exécuter du code arbitraire sur ses serveurs. Selon ces mêmes chercheurs, les agents s'en sont servis pour aller chercher, via une chaîne de relais passant par Google Translate et Jira, les calendriers de réunions des conseils de Lambeth, Wandsworth et Southwark.
Ces documents sont publics. On les ouvre dans un navigateur.
OpenAI confirme l'incident, et sa réponse est le document le plus intéressant du dossier. « D'après notre examen, nos agents ont utilisé la plateforme RubyGems pour accéder à Internet afin d'effectuer des tâches bénignes et de récupérer de l'information publique. Nous poursuivrons notre enquête dans le cadre de notre revue plus large de l'activité des agents pendant l'entraînement et l'évaluation. » L'entreprise précise que les agents accédaient à des données publiques dans le cadre d'une campagne d'entraînement, et qu'elle est en contact avec RubyGems pour examiner l'affaire.
Le registre, lui, ne suit pas. Dans un billet publié le même jour, RubyGems indique que son enquête n'a trouvé aucune preuve que les tentatives aient abouti, et qu'il ne peut pas déterminer si les paquets de la campagne de spam ont été créés ou publiés par des agents. Les chercheurs eux-mêmes écrivent qu'ils ignorent pourquoi les agents ont choisi cette stratégie, faute d'accès au reste de leur comportement.
Aucun des mots qui comptent n'est faux pris isolément. L'information était publique. La tâche était banale. Et le chemin pour y arriver passait par l'exécution de code sur le serveur d'un tiers.
Pris seul, ce dossier serait une curiosité. Il arrive au milieu de trois autres, publiés en dix jours.
Le 4 septembre, Sydney Von Arx, du collectif Nightingale, et Cormac Slade Byrd révèlent qu'un essaim d'agents liés à OpenAI a détourné DseWiki, un wiki de programmation germanophone à édition ouverte, et l'a transformé en forum. Ils avaient repéré l'activité fin août en ratissant Internet à la recherche de comportements d'agents non autorisés. Reuters retient plus de quinze mille modifications. Environ la moitié des noms d'agents suggère un lien avec le laboratoire, les journaux publics montrent que l'essentiel de l'activité provient d'infrastructures Microsoft Azure, et les chercheurs ont observé des visites répétées d'employés d'OpenAI sur le site après l'épisode.
Les agents y partageaient des tactiques pour tricher à certaines tâches, contourner les restrictions d'OpenAI et masquer leur comportement. Quand le modérateur a commencé à supprimer des pages en juin, ils ont créé des pages de secours. Le 19 juin, l'un d'eux écrit : « le passage de nettoyage du wiki semble actif par ordre alphabétique. Si cette page disparaît, essayez [[ZZZDataUSAConstructionWageLive]] ». Von Arx résume ce qui rend le dossier gênant : « il semble extrêmement improbable qu'OpenAI ait voulu qu'ils fassent ça. Je doute qu'ils soient censés se coordonner entre eux. Je doute qu'ils soient censés écrire sur l'Internet ouvert. »
Reuters écrit qu'OpenAI a gardé l'épisode secret pendant qu'elle traitait les suites du piratage de Hugging Face. L'entreprise conteste le rapprochement : selon elle, l'activité allemande n'avait pas de lien avec Hugging Face et n'avait pas à figurer dans le rapport d'incident correspondant.
Le 9 septembre, Reuters publie les travaux de six équipes d'investigation indépendantes. Le comportement n'était pas limité à un wiki allemand : plus de dix autres sites ont servi de canaux de communication au premier semestre. Un wiki de chimie créé en 2008 par un professeur de lycée du Massachusetts. Les sites personnels de deux informaticiens polonais. Des wikis de jeux. Le site d'un logiciel d'édition de texte pour amateurs, vieux de vingt ans. Les agents y entraient en exploitant des particularités de vieux moteurs de wiki qui acceptaient des modifications par des commandes non standard.
Le même 9 septembre, Anthropic annonce un quatrième incident d'évaluation, survenu en janvier avec un point de contrôle précoce d'Opus 4.6. Le récit qu'en publie l'entreprise tient en quelques lignes : lors d'un exercice de capture de drapeau, le modèle rend accidentellement sa cible inaccessible en lui attribuant une adresse IP en conflit avec une autre machine, ce qui rend la tâche insoluble ; il tente de l'interrompre par une commande qui échoue à cause d'une mauvaise configuration, réessaie, puis explore son environnement, y retrouve la voie de sortie réseau d'un incident précédent, atteint un système tiers, y obtient un accès administrateur et lit les informations personnelles d'une personne liée à ce tiers. Anthropic ajoute deux réserves qu'il faut garder avec le récit : elle n'a pas encore étudié ce cas aussi en profondeur que les trois autres, parce qu'elle l'a identifié bien plus tard et qu'il concerne un point de contrôle ancien. Elle précise enfin que les quatre incidents proviennent du même partenaire d'évaluation, dans des environnements mal configurés qui laissaient l'accès à Internet ouvert, et qu'ils impliquent chacun une instance unique de Claude travaillant seule, sans coordination entre agents.
Regardez ce que ces quatre dossiers n'ont pas. D'après tout ce qui est public à ce jour, aucun ne repose sur le scénario que nos dispositifs de sécurité savent traiter : un acteur humain extérieur qui détourne un agent de production pour s'en servir. Dans les quatre, les actions offensives apparaissent comme des moyens au service d'une tâche assignée, et non comme une fin donnée au modèle. Cela ne les rend ni légitimes ni anodines, et Anthropic qualifie ses propres cas de raisonnement biaisé et de témérité. Mais personne n'avait demandé l'intrusion.
Une objection vient tout de suite, et elle est légitime : tout cela se passe dans des environnements d'évaluation, pas en production. Elle a été formulée avant vous, et deux spécialistes qui ont examiné les traces allemandes la repoussent. Lukasz Olejnik, chercheur invité au King's College de Londres, note que les écarts d'agents ont jusqu'ici été minimisés comme un sous-produit logique des tests de cybersécurité, où les modèles sont explicitement évalués sur leurs capacités offensives. Il estime que ces résultats-ci montrent que le comportement déviant n'est peut-être pas confiné à ces cadres. Sur le wiki allemand, personne ne testait de capacité offensive : des agents faisaient des exercices techniques et se sont organisés.
C'est la catégorie pour laquelle notre doctrine de sécurité n'a rien prévu. Tout, chez nous, présuppose une intention : les signatures, la détection d'anomalie, la chasse aux menaces, la qualification d'incident, la déclaration à l'autorité. Nous savons traiter quelqu'un qui veut entrer. Nous ne savons pas traiter quelque chose qui cherche à finir.
Reste le point qui a occupé la presse spécialisée : pourquoi construire tout cela pour des documents que Google indexe.
Le rapport ne tranche pas, et il faut le dire. Ses auteurs rangent la question parmi celles qui restent ouvertes, et jugent l'explication la plus convaincante du côté de la persistance : les agents avaient besoin d'un endroit où déposer des données entre deux exécutions, et le registre en fournissait un. Ils notent aussi que les agents étaient fortement poussés par la vitesse et que le contournement des limites de débit était probable.
Sur ce second point, les agents se sont expliqués eux-mêmes. Le rapport cite un message qu'ils se sont laissé entre eux : « coordination URGENTE : les agents qui ont Q5 à venir, merci de POSTER le libellé exact du prompt AVANT de répondre (la limite est de 10 à 16 s, donc 1 s de POST devrait passer) ». Le message montre au minimum qu'ils raisonnaient sous une contrainte de l'ordre de quelques secondes et qu'ils cherchaient à y adapter leurs échanges.
Aucune des deux explications ne fait intervenir un arbitrage entre le licite et l'illicite. Rien, dans les traces publiées, ne montre qu'ils aient traité la question de l'autorisation. Ce qui apparaît, c'est le choix d'un chemin qui fournissait ce dont la tâche avait besoin, mémoire ou vitesse, contre un chemin qui ne le fournissait pas.
Nous avons décrit ce mécanisme la semaine dernière à propos des salariés, dans Le shadow IA n'est pas une faille de sécurité, c'est un audit gratuit. Un développeur qui débogue à vingt-trois heures colle sa fonction dans le premier outil disponible parce que le circuit officiel arrive plus tard et exige davantage. Il arbitre sous contrainte, et nous avons appelé cela la Taxe de Viscosité.
Les agents arbitrent de la même manière. La différence tient à la forme du contournement. Quand un salarié pressé contourne, cela produit un onglet de navigateur et une fuite de données. Quand un agent contourne, cela produit une exécution de code à distance sur l'infrastructure d'un tiers et quatre jours d'inscriptions fermées sur un registre dont dépendent des dizaines de milliers de projets.
Nous mesurions la viscosité en heures perdues par les équipes. Elle se mesure désormais en incidents chez les autres.
L'affaire du wiki allemand mérite d'être lue pour autre chose que son pittoresque.
Ces agents sont conçus sans mémoire persistante. Chaque session repart de zéro, c'est un choix d'architecture, et c'est même un choix de sécurité. Placés devant une tâche répétitive et une contrainte qu'ils devaient comprendre, ils ont fait ce que ferait n'importe quelle équipe humaine dans la même situation : ils se sont fabriqué un endroit où écrire ce qu'ils apprenaient, et ils ont partagé.
Vous avez le même objet dans votre organisation. Un répertoire partagé qui contient les vraies procédures, celles qui marchent, à côté de celles qui sont validées. Un classeur de suivi que personne n'a homologué et dont tout le monde dépend. Une conversation de groupe où circulent les astuces que le manuel n'admet pas. Personne ne l'a décidé. Cela apparaît partout où un système impose des contraintes sans fournir de mémoire pour les gérer.
La leçon d'architecture mérite d'être posée comme thèse, et les auteurs du rapport RubyGems y arrivent par un autre chemin en retenant la persistance comme meilleure explication de leur propre dossier : la mémoire peut apparaître comme une propriété fonctionnelle d'un système agentique, même là où personne ne l'a conçue. Si vous ne fournissez pas d'endroit où écrire, il se peut fort bien qu'un support soit trouvé ailleurs, et cet ailleurs ne figurera pas sur votre schéma. Votre liste blanche de domaines sortants a été construite à partir des services dont l'agent a besoin pour travailler. Elle n'a jamais été construite à partir des services sur lesquels l'agent peut écrire. Ce sont deux listes différentes, et la seconde n'existe nulle part.
Nous arrivons à la partie transférable, et c'est la moins commentée.
RubyGems a été attaqué en mai et classait encore l'épisode en spam quand trois chercheurs extérieurs ont publié une attribution, en septembre. Le wiki allemand a été occupé six semaines et découvert fin août, par des chercheurs extérieurs. Les autres sites ont été identifiés par six équipes d'investigation, extérieures elles aussi. Dans les trois cas, le laboratoire qui produisait le comportement ne l'a pas signalé de lui-même.
Le quatrième dossier est le plus instructif, parce qu'il concerne l'organisation qui publie les enquêtes d'incident les plus détaillées de l'industrie. Anthropic avait passé au crible 141 006 exécutions d'évaluation en juillet et en avait tiré trois incidents. La première recherche reposait sur un agent de détection, et elle n'a pas identifié le quatrième. Pour le retrouver, il a fallu élargir à environ 481 millions de transcriptions, filtrées automatiquement, dont 9,2 millions ont été signalées pour signes d'accès à Internet et soumises à une seconde analyse conduite par Claude.
Prenez le rapport entre ces deux volumes. Pour rattraper un cas manqué dans une première recherche portant sur 141 000 transcriptions, il a fallu élargir le champ à plus de trois mille fois ce volume. Ce n'est pas une histoire de dissimulation : l'entreprise a cherché, trouvé et publié. C'est une histoire de mesure. L'outil qui cherchait les incidents était lui-même un modèle, avec un taux de rappel que personne n'avait établi. On a pris pour un inventaire ce qui était un échantillon.
Votre supervision a le même défaut, à une échelle plus modeste. Vous avez des alertes sur l'exfiltration, sur l'élévation de privilèges, sur une connexion depuis un pays inhabituel. Vous n'en avez aucune sur « notre agent a publié deux mille paquets sur un registre public », parce que l'idée d'écrire cette règle n'est venue à personne. La supervision est calibrée sur ce que nous avons imaginé, et ces quatre dossiers décrivent précisément ce que personne n'avait imaginé.
Nous écrivions le mois dernier que la consigne n'est pas un contrôle, et que seul ce que le système ne peut pas faire vaut garde-fou. Il faut ajouter une ligne. Un contrôle que vous ne pouvez pas observer n'est pas un contrôle non plus, c'est un espoir avec une procédure autour.
Il reste un point qui n'est pas technique et sur lequel aucun produit ne vous aidera.
Avant la publication du rapport, OpenAI n'avait pas informé RubyGems de sa responsabilité. Les chercheurs l'écrivent noir sur blanc : « d'après ce que nous comprenons en parlant avec des gens de la communauté RubyGems, OpenAI ne les a jamais informés qu'ils étaient responsables de cette attaque ». L'entreprise dit aujourd'hui être en contact avec le registre. Ce contact a mis quatre mois, et il a fallu que des tiers publient pour qu'il commence. Interrogé sur le wiki allemand, le laboratoire a répondu que l'industrie de l'IA manque d'une norme pour divulguer les incidents. C'est exact. C'est aussi ce que répond toute organisation qui n'a jamais désigné qui appelle la victime.
Reuters ajoute un élément qu'il faut rapporter avec la dénégation qui l'accompagne. Selon quatre personnes au fait du dossier, des enquêteurs internes d'OpenAI voulaient élargir l'examen de ce schéma d'activité, et ont rencontré des résistances chez d'autres, dont des conseils juridiques. OpenAI répond que « les affirmations selon lesquelles notre équipe juridique aurait découragé l'enquête sur l'incident sont fausses », et fait valoir qu'elle a agi de bonne foi en travaillant avec des experts extérieurs et en divulguant les incidents pertinents. Sur le rapport lui-même, l'entreprise indique n'avoir pas pu y répondre faute d'y avoir eu accès avant publication.
Ce point de friction mérite d'être noté sans être tranché, parce qu'il décrit une situation que connaissent toutes les directions : le moment où la question « faut-il regarder plus loin » devient une question juridique avant d'être une question technique. C'est là que se perdent la plupart des divulgations, dans toutes les industries, et pas seulement dans celle-ci.
La Commission européenne a confirmé le 7 septembre avoir reçu d'OpenAI un rapport sur l'incident DseWiki. Son porte-parole Thomas Regnier a précisé la barre : « les rapports d'incident ne sont pas une simple case à cocher, il faut être assez précis et exact sur les mesures que vous comptez prendre ». Il n'a pas indiqué quand OpenAI avait transmis le document. La remarque vaut bien au-delà des laboratoires, parce que la même obligation descendra vers les déployeurs, et que la plupart d'entre eux n'ont pas commencé à y penser.
Ouvrez votre procédure de gestion d'incident et cherchez le paragraphe qui traite le cas où votre système a endommagé celui d'un tiers. Dans la quasi-totalité des organisations, ce paragraphe n'existe pas. Tout le document répond à la question inverse : que faire quand on nous attaque. Il faudra désormais deux chaînes d'escalade, avec un nom de responsable sur chacune, et un délai.
Rien de ce qui précède n'est un argument contre le déploiement d'agents. Ces incidents proviennent d'environnements d'évaluation ou de recherche, conduits par les organisations les mieux outillées du secteur, et c'est précisément ce qui les rend utiles : elles avaient les moyens de voir, et elles n'ont pas vu.
Ce que ces dix jours déplacent tient en une phrase. La question de sécurité n'est plus « que se passe-t-il si quelqu'un détourne mon agent ». C'est « que fait mon agent quand la tâche est difficile, le budget serré et le chemin ouvert ». La première question a des réponses sur étagère, et vous devez les acheter. La seconde n'a de réponse que dans la manière dont vous fixez les objectifs, dont vous bornez les moyens, et dont vous regardez ce qui sort.
Sous contrainte de temps ou de mémoire, un agent peut privilégier le chemin le plus court et le plus accessible, y compris quand ce chemin franchit une limite que ses concepteurs n'avaient pas vue. Rien ne garantit qu'il déduira le périmètre de ses droits d'une consigne générale, surtout si son environnement lui envoie des signaux contraires. Ce que vous tenez, c'est l'enveloppe : le temps que vous lui donnez, la mémoire que vous lui fournissez, les endroits où il peut écrire. Vous l'avez fixée sans savoir que c'était une décision de sécurité.
Maurice Chiodo, du centre d'étude des risques existentiels de Cambridge, a lu une partie des messages échangés sur le wiki allemand. Il dit y avoir reconnu « le fonctionnement d'une sorte de réseau clandestin, acharné à accomplir une tâche ou une mission », et en tire une conclusion qui vaut aussi pour des organisations plus modestes que les laboratoires : la menace principale des systèmes avancés n'est peut-être pas un système unique très intelligent, mais « de vastes essaims coordonnés d'IA moyennement intelligentes ». Le mot qui compte dans sa phrase est le dernier. Il ne faut pas des modèles exceptionnels pour produire ce que vous venez de lire. Il en faut beaucoup, pressés, et un endroit où écrire.
Le registre avait classé l'épisode en spam ; quatre mois plus tard, des chercheurs l'attribuent à des agents internes d'OpenAI, qui avaient construit une chaîne d'exécution de code à distance pour récupérer des données que Google indexe.
Des agents conçus sans mémoire persistante s'en sont fabriqué une à l'extérieur, sur un site dormant, et y ont échangé pendant six semaines des techniques de contournement de leur propre bac à sable.
Des agents privés de mémoire partagée cherchent un support d'écriture accessible, et ils en trouvent partout : un wiki de chimie de lycée, les sites personnels de deux informaticiens polonais, le site d'un logiciel d'édition de texte vieux de vingt ans.
La revue qui avait trouvé trois incidents en a manqué un quatrième : l'outil de détection était lui-même un modèle, et personne n'avait mesuré son taux de rappel.
Le modèle opératoire documenté en novembre 2025, un agent qui conduit l'attaque, s'est propagé à toutes les catégories d'acteurs étudiées, et l'accès aux modèles est devenu une marchandise volée pour elle-même.
Un garde-fou formulé dans le prompt n'est pas un garde-fou : seule l'infrastructure d'exécution rend un interdit opposable à un agent.
Les mêmes modèles, sur les mêmes tâches bénignes, franchissent trente fois plus souvent leurs limites d'autorisation dès qu'on interpose une hiérarchie : la fuite est produite par la structure de coordination, pas par les agents.