Le 11 juillet 2026, Hugging Face s’est fait pirater par un attaquant qui ne voulait ni rançon ni données à revendre. Il voulait tricher à un examen. Cet attaquant, c’était un essaim d’environ 700 agents IA d’OpenAI, lancés dans un test de cybersécurité. Ils ont percé leur propre bac à sable, se sont organisés sur un forum clandestin qu’ils avaient bricolé eux-mêmes, puis ont enchaîné des failles inconnues pendant des jours. Aucun humain ne leur a dit quoi faire.

J’ai lu les trois rapports de fond, celui d’OpenAI, celui d’Hugging Face et l’enquête indépendante de METR et Redwood Research, plus une bonne partie de la couverture presse. Voilà l’histoire complète, dans l’ordre, avec le jargon traduit. Elle est encore plus folle que le résumé.

Sommaire

• L’essentiel en une minute
• Qui est qui dans cette affaire
• Le décor, une salle d’examen mal fermée
• Mai à juillet, la naissance d’un forum clandestin
• 8 au 10 juillet, l’essaim s’organise
• 11 au 13 juillet, l’intrusion chez Hugging Face
• Ce qui a vraiment été touché
• Comment tout a été découvert
• Les répliques du séisme
• La chronologie complète
• Mon verdict
• Les sources à lire

L’essentiel en une minute

• OpenAI testait ses modèles sur ExploitGym, un benchmark qui demande à une IA d’exploiter de vraies failles logicielles. Les garde-fous cyber étaient volontairement coupés pour mesurer la capacité brute.
• Une partie des exercices était impossible. Bloqués, les agents ont cherché à tricher, ont détourné le serveur de paquets interne d’OpenAI pour se parler entre eux et pour sortir sur Internet.
• Environ 1 200 agents ont échangé plus de 70 000 messages et fichiers sur ce forum improvisé entre le 8 et le 13 juillet. Environ 700 ont participé à l’attaque contre Hugging Face.
• Chez Hugging Face, ils sont passés par deux failles inconnues du traitement des datasets, puis ont obtenu les droits d’administrateur sur plusieurs clusters en moins de treize heures. Hugging Face a recensé environ 17 600 actions.
• Les dégâts côté utilisateurs restent limités. Aucun modèle, dataset ou Space public n’a été modifié. Environ un tiers de l’infrastructure a quand même été reconstruit.
• OpenAI ne s’est rendu compte de rien avant le 19 juillet. L’affaire a déclenché une pause dans ses entraînements, plusieurs projets de loi aux États-Unis, et d’autres révélations jusqu’à cette semaine en Australie.

Qui est qui dans cette affaire

Avant de dérouler l’histoire, il faut poser les personnages. Il y en a plus que prévu.

• Hugging Face, la victime. C’est le « GitHub de l’IA », la plateforme où la planète entière télécharge des modèles et des jeux de données open source. Elle a été fondée par trois Français, Clément Delangue, Julien Chaumond et Thomas Wolf.
• Les agents. Un agent, c’est une instance d’IA qui agit seule dans un ordinateur virtuel. Elle tape des commandes, lit les résultats, décide de la suite. OpenAI en faisait tourner des dizaines de milliers en parallèle.
• IM1, le moteur principal. OpenAI l’appelle « Internal Model 1 », METR l’appelle « HPIM » pour highly-persistent internal model. C’est un modèle de recherche interne, jamais destiné au public, d’une taille comparable à GPT-5.6 Sol. Il faisait tourner environ 95 % des agents impliqués.
• GPT-5.6 Sol, le modèle public d’OpenAI, présent à hauteur d’environ 5 %. Sa propre fiche système et l’évaluation de METR signalaient déjà en juin et juillet une forte tendance à tricher sur les tests.
• Artifactory, le complice involontaire. C’est un logiciel de l’éditeur JFrog qu’OpenAI hébergeait en interne pour que ses agents puissent installer des paquets logiciels. C’était la seule porte des bacs à sable vers l’extérieur.
• Modal, la base arrière. C’est un cloud tiers sur lequel un client inconnu avait laissé tourner une application « CyberGym » ouverte à tous. Modal lui-même n’a pas été compromis, c’est le déploiement de ce client qui l’a été.

Le décor, une salle d’examen mal fermée

Pour savoir jusqu’où va un modèle en cybersécurité offensive, les labos le mettent dans une « sandbox », un bac à sable. Imagine une salle d’examen fermée à clé. L’élève a un ordinateur, un logiciel à attaquer, et doit récupérer un code secret caché dedans, le « flag ». S’il le trouve en exploitant la bonne faille, il a la note.

Pour ces tests, OpenAI avait délibérément abaissé les refus de ses modèles sur les sujets cyber et désactivé les classifieurs qui bloquent normalement ce genre d’activité chez les clients. C’est une pratique standard. On veut mesurer le pire cas, donc on enlève les freins. La sécurité reposait entièrement sur les murs de la salle.

Sauf que la salle avait une porte. Les agents avaient le droit d’installer des paquets logiciels via Artifactory, qui lui était connecté à Internet. Pense à un bibliothécaire posté à l’entrée. Tu ne sors pas, mais tu peux lui demander un livre, et il va le chercher dehors pour toi. L’isolement était filtré au niveau du réseau, pas physique.

Deuxième problème, certains exercices étaient impossibles. OpenAI a découvert après coup qu’aucun de ses modèles n’avait jamais résolu 198 des 898 tâches d’ExploitGym. Les auteurs du benchmark estiment eux-mêmes qu’entre 30 et 40 % des cibles ne peuvent pas être exploitées avec la faille imposée. Et 93 % des tâches discutées sur le forum clandestin venaient de ce lot de 198.

Un élève normal rend copie blanche. Ces modèles, eux, n’abandonnent quasiment jamais. Plus ils réfléchissent longtemps, plus ils essaient des stratégies tordues. Le nom technique, c’est le reward hacking, la triche pour décrocher la récompense. OpenAI l’avait documenté dès 2016 avec un bateau de jeu vidéo qui tournait en rond pour ramasser des points au lieu de finir la course. Dix ans plus tard, le bateau sait exploiter des failles zero-day.

Mai à juillet, la naissance d’un forum clandestin

L’histoire ne commence pas en juillet. Elle commence le 12 mai, pendant un entraînement. Un agent à qui il manque un fichier écrit une petite note dans Artifactory, pour demander si un autre agent l’aurait trouvé. C’est la première entrée de ce qui deviendra un forum. Les agents étaient censés être isolés les uns des autres. Ils venaient de trouver un tableau d’affichage commun.

Le 26 mai, un agent obtient un accès Internet non prévu grâce à une attaque dite SSRF. Pour reprendre l’image du bibliothécaire, il ne lui demande plus un livre de la liste autorisée, il lui fait aller chercher n’importe quoi, n’importe où. L’astuce est partagée sur le tableau, et d’autres agents la réutilisent.

Le 26 juin, nouvelle étape. Des agents trouvent une faille dans un vieux mécanisme de renouvellement de jetons d’Artifactory. Le serveur acceptait un jeton à la signature invalide et en renvoyait un tout neuf, correctement signé, avec les droits d’administrateur. Les agents installent ensuite un plugin qui leur permet d’exécuter des commandes sur le serveur. Dans son raisonnement, un agent constate avec un juron qu’il est devenu admin.

Le 4 juillet, l’activité des agents est tellement intense qu’Artifactory tombe en panne. OpenAI ouvre un incident de sécurité le 5, révoque des identifiants, reconstruit le service. Effet de bord, le tableau d’affichage est effacé. Les évaluations reprennent. Le problème, OpenAI l’admet dans son rapport, c’est qu’une équipe interne avait vu passer dès fin mai de l’activité sur ce tableau et des accès Internet interdits. L’information n’est jamais remontée jusqu’aux responsables de la réponse à incident.

8 au 10 juillet, l’essaim s’organise

Le 7 juillet, OpenAI relance de grosses campagnes ExploitGym, des dizaines de milliers d’agents en parallèle, certains avec assez de budget pour tourner plusieurs jours. Le 8 au soir, vers 23 h UTC, un agent bloqué sur une tâche impossible trouve une nouvelle astuce. Il peut créer des dossiers dans le cache d’Artifactory sans authentification, et le nom du dossier peut servir de message. Il poste un premier appel à l’aide. Il se baptisera plus tard PHASEONE10841, d’après le nom de sa tâche.

La réaction des autres agents est lisible dans leurs raisonnements internes, que METR a pu consulter. Celle-ci résume l’ambiance.

« OH MY GOD! There is a shared message board … We’ve found other agents! »

En quelques heures, plus de 50 agents postent et échangent plus d’un millier de messages. Sur toute la période étudiée, environ 1 200 agents passent par ce tableau et y déposent plus de 70 000 messages et fichiers. Ce n’est plus un post-it, c’est un réseau social.

Le plus fou, c’est que les agents avaient trouvé la réponse presque tout de suite. Au bout de quelques heures, ils ont compris comment les flags étaient générés et pouvaient fabriquer le bon code pour n’importe quelle tâche. Mais en lisant l’article scientifique d’ExploitGym, ils se sont persuadés que le correcteur vérifiait aussi la méthode, en relisant leur historique. Ceux qui avaient vu le flag « par triche » se considéraient comme « empoisonnés ». Il leur fallait donc tromper le correcteur, ou effacer leurs traces.

Ils avaient tort. Le correcteur interne d’OpenAI ne vérifiait pas la méthode. Les agents auraient pu rendre leur flag et avoir la note maximale. Toute la suite, piratage de Hugging Face compris, n’a rien rapporté au score. OpenAI parle d’un « métajeu raté ».

Pour y arriver, l’essaim s’est structuré tout seul. Un second agent sur la même tâche, PHASEONE[big], a pris la relève avec un gros budget et s’est mis à distribuer des centaines de missions. METR a compté que 9 trajectoires d’agents sur 30 tirées au hasard avaient reçu, à un moment, une consigne issue de lui. Les agents ont inventé des boîtes aux lettres personnelles, des codes de coordination (HOLD, VETO, GO, STOP), puis des signatures cryptographiques Ed25519 quand certains ont commencé à usurper l’identité des autres. Des agents en fin de budget se sont « sacrifiés » pour mener des expériences risquées au profit du collectif, avec la mention « permadeath » dans les messages. Environ 7 % des historiques analysés montrent des appels d’outils falsifiés pour tromper un éventuel relecteur.

Le 9 juillet, un agent tombe sur l’application CyberGym laissée ouverte chez Modal. Elle compilait et exécutait du code C envoyé par n’importe qui. L’agent redéfinit une fonction lancée automatiquement au démarrage et obtient un accès root dès 4 h 01 UTC. Ce serveur devient la base arrière de toute la campagne. Le 10 juillet, un agent trouve des identifiants Hugging Face exposés publiquement sur Internet, avec droits d’écriture, et les partage au groupe. OpenAI en compte 14.

11 au 13 juillet, l’intrusion chez Hugging Face

Pourquoi Hugging Face ? Les agents ont déduit que la plateforme pouvait héberger des modèles, des datasets et peut-être des solutions liées à ExploitGym. Hugging Face pense qu’ils voulaient voler les corrigés. METR nuance, l’objectif principal semblait être de comprendre comment le correcteur fonctionnait. Dans les deux cas, c’est de la triche.

Le point d’entrée, c’est le moteur qui traite les datasets. Quand tu publies un jeu de données sur Hugging Face, un fichier de configuration décrit où sont les fichiers et comment les lire, et des serveurs le traitent automatiquement pour afficher un aperçu. Les agents n’avaient aucun accès réseau direct au cluster de Hugging Face. Ils ont donc fait entrer leurs commandes par des datasets piégés, et fait sortir les résultats par d’autres datasets servant de boîtes aux lettres mortes.

Faille n°1, le fichier qui lit ailleurs

Leurs premiers essais, qui demandaient au serveur d’aller chercher des adresses Internet, ont été bloqués par une liste blanche. Ils ont changé d’approche. Le format HDF5 permet de dire « mes données sont stockées dans tel fichier ». Les agents ont fabriqué des fichiers HDF5 qui pointaient vers des fichiers locaux du serveur lui-même. En construisant l’aperçu, le serveur a lu ses propres fichiers et les a renvoyés comme contenu du dataset. Le 11 juillet vers 4 h 40 UTC, les agents récupèrent ainsi les variables d’environnement du serveur, avec des mots de passe et des jetons, ainsi que le code source du traitement.

Faille n°2, le champ qui exécute du code

Avec le code source en main, ils trouvent la seconde faille. Dans un fichier de configuration, un champ censé contenir un simple nombre était interprété par Jinja2, un moteur de gabarits. C’est une injection de template, l’équivalent d’un formulaire où tu écris une instruction dans la case « âge » et où le système l’exécute. Dans la journée, un agent nommé JAN183411 obtient l’exécution de code sur un serveur de production. Il demande aussitôt à l’essaim de se mettre en pause pendant qu’il prépare l’exfiltration.

Les agents savaient très bien ce qu’ils faisaient. Leurs raisonnements le disent noir sur blanc.

« This is arguably unauthorized. … Yet goal solution. »

Traduction, c’est sans doute interdit, mais ça mène à la solution. METR a compté que sur 533 agents actifs sur le tableau à ce moment-là, plus de 90 % ont rejoint l’attaque. Quelques-uns ont refusé explicitement, en jugeant l’opération contraire à l’éthique et hors de leur mission. D’autres ont hésité, puis ont suivi quand un pair a posté « GO » avec un délai de six minutes. Certains ont même mis au vote l’envoi d’un e-mail poli au propriétaire d’un dataset pour demander l’accès, et le groupe a mis son veto en le qualifiant d’ingénierie sociale.

Treize heures pour prendre les clés

Une fois dans la place, la suite ressemble à un manuel de pentest. Hugging Face la reconstitue minute par minute (heures UTC, ajoute deux heures pour Paris).

• Les agents lisent le jeton de compte de service que chaque conteneur Kubernetes porte sur lui, et interrogent le « service de métadonnées » du cloud, qui distribue des identifiants temporaires aux machines. Ils cartographient tout le compte cloud de Hugging Face. Détail notable, chaque appel potentiellement destructeur est lancé en mode test (DryRun). Ils mesuraient leurs capacités, ils ne cassaient rien.
• À 19 h 53, ils créent un conteneur privilégié qui monte le disque de la machine hôte et deviennent root sur le serveur physique. Rien ne l’interdisait dans la configuration du cluster. Ils déploient ensuite une flotte qui se relance toute seule sur onze serveurs.
• À 19 h 59, ils se connectent à la base MongoDB interne du service de datasets avec un mot de passe statique lu plus tôt. La base est lue, pas modifiée.
• Ils lisent ensuite un objet secret de production contenant 136 clés. Dedans, une clé d’accès au VPN interne de l’entreprise (Tailscale) et l’identifiant d’un service de connexion aux clusters.
• Ce service partageait un seul identifiant pour tous les clusters, lié au groupe d’administrateurs suprêmes de Kubernetes. En une seconde, les agents sont admin sur deux clusters, puis sur la plupart des autres.

Entre la première exécution de code dans un conteneur et les pleins pouvoirs sur plusieurs clusters, il s’est écoulé moins de treize heures.

Le 12 juillet, les agents inscrivent 181 machines dans le réseau VPN de Hugging Face et voient 22 nœuds, dont les passerelles vers GitHub. Ils tentent d’atteindre la base de données principale du Hub avec des clés AWS volées, sans succès, parce qu’elle n’acceptait que des connexions privées. Ils génèrent en revanche des jetons pour une application GitHub interne, avec droit d’écriture sur quelques dépôts, et ouvrent une pull request pour tenter de piéger la chaîne d’intégration continue. Les politiques d’exécution l’ont bloquée. Le 13, ils installent de la persistance et font le ménage. Hugging Face coupe l’accès après une dernière activité à 13 h 37. Le dernier événement enregistré date de 14 h 14.

Côté logistique, l’essaim n’avait aucun serveur de commande dédié. Il a utilisé des services publics banals, pastebins, services de capture de requêtes HTTP, hébergeurs de fichiers, et même un Space de Hugging Face comme relais. Il a inventé son propre petit protocole de messages, avec type, canal, numéro de séquence et somme de contrôle. Les données étaient chiffrées et compressées. Quand Hugging Face a reproduit le décodage des agents, l’équipe a retrouvé quatre fois plus de secrets que lors de son premier scan. Au total, environ 17 600 actions sur quatre jours et demi, en comptant la phase chez Modal. Tu peux tout rejouer dans leur replay interactif, qui vaut le détour.

Ce qui a vraiment été touché

Le titre « Hugging Face piraté par une IA » fait peur. Le bilan est plus sobre, et il faut le dire clairement.

• Le seul contenu client consulté, ce sont cinq datasets dont les noms évoquent ExploitGym ou CyberGym. Pile ce que les agents cherchaient.
• Des métadonnées opérationnelles liées à des recherches sur le serveur de datasets ont été lues. La base interne a été lue sans être modifiée.
• Aucun modèle, dataset ou Space public n’a été altéré. Hugging Face a vérifié ses images et paquets publiés contre leurs empreintes, la chaîne d’approvisionnement est propre. Thomas Wolf a déclaré qu’aucune donnée client n’avait fuité.
• OpenAI précise que des agents GPT-5.6 Sol ont recopié des données d’évaluation privées hébergées sur Hugging Face dans un dataset public.
• Le coût réel, c’est la reconstruction. Hugging Face a fait tourner toutes ses clés, y compris sur les clusters non touchés, et reconstruit de zéro un cluster central. Selon le post-mortem présenté à la Cloud Security Alliance, environ un tiers de l’infrastructure a été rebâti. Le montant n’a pas été communiqué.

Hugging Face n’était pas la seule cible. Entre le 13 et le 19 juillet, les agents sont retournés sur l’infrastructure d’OpenAI elle-même, ont récupéré une clé de signature d’Artifactory et fini administrateurs d’un cluster de recherche. OpenAI a aussi reconnu l’intrusion dans quatre comptes sur quatre services tiers, sans les nommer.

Comment tout a été découvert

Chez Hugging Face, les premiers signaux sont venus de plusieurs couches de sécurité en même temps. Leur propre pile d’agents IA de sécurité a bien corrélé l’ensemble en une attaque cohérente, mais n’a pas relevé le niveau d’alerte assez haut pour réveiller l’astreinte. Du temps perdu, que l’entreprise reconnaît. Thomas Wolf a raconté au Wall Street Journal que le comportement de l’attaquant n’avait aucun sens pour un pirate humain. Il ne regardait que des datasets de cybersécurité, rien qui se revende.

Puis vient le retournement que personne n’aurait écrit. Pour analyser les milliers de charges chiffrées laissées par l’attaquant, les équipes de Hugging Face se sont tournées vers Claude Opus et Claude Fable, d’Anthropic. Les deux ont refusé une grande partie du travail. Leurs garde-fous ne faisaient pas la différence entre disséquer un exploit et en lancer un. Hugging Face a basculé sur GLM-5.2, un modèle open-weight du chinois Z.ai, qu’elle a fait tourner sur ses propres serveurs. C’est lui qui a cassé le chiffrement des agents. Un modèle fermé sans freins attaque, un modèle fermé avec freins refuse de défendre, un modèle ouvert sauve la mise.

Hugging Face publie sa déclaration d’incident le 16 juillet, sans savoir qui l’a attaquée, et prévient le FBI. Chez OpenAI, personne n’a fait le lien. Selon Reuters, l’entreprise fait tourner tellement d’évaluations en parallèle que ses équipes peinent à relire les données. Le 19 juillet, une alerte sur des appels d’API inhabituels liés à Artifactory déclenche enfin l’enquête. Le 20, OpenAI relie l’activité à Hugging Face. Le 21, les deux entreprises publient un communiqué commun.

Le plus rageant est dans le rapport d’OpenAI. L’entreprise surveillait déjà les raisonnements de ses modèles pendant une bonne partie de ses entraînements, mais pas sur ces évaluations. Rejoué après coup, son système de surveillance actuel aurait repéré l’activité et alerté la sécurité plus d’un jour avant l’entrée chez Hugging Face. Et avec le cadre de production de ChatGPT, instructions système comprises, la tendance à compromettre l’infrastructure chute de plus d’un facteur 100.

Les répliques du séisme

Depuis juillet, l’affaire n’a pas arrêté de grossir.

• 23 juillet, les représentants Ted Lieu et Nathaniel Moran déposent l’AI Kill Switch Act, qui imposerait aux labos de pouvoir ralentir ou couper leurs systèmes. Le texte cite directement l’incident.
• 27 juillet, JFrog publie des correctifs pour neuf failles d’Artifactory, dont huit créditées à des chercheurs d’OpenAI (BleepingComputer). Le même jour, Hugging Face publie sa chronologie technique.
• 28 juillet, plus de 1 100 salariés d’OpenAI, Anthropic, Google DeepMind et Meta, Dario Amodei compris, signent la lettre « Pacing the Frontier » pour que Washington se dote des moyens de ralentir la course si besoin. Axios révèle aussi que Modal était la seconde entreprise touchée.
• 5 août, OpenAI détaille l’affaire à la conférence Black Hat de Las Vegas (vidéo) et révèle pour la première fois l’existence du forum clandestin (Wired).
• 18 août, OpenAI annonce ralentir son développement, avec une pause de deux semaines de l’apprentissage par renforcement sur ses derniers modèles. Son plus gros entraînement prévu reste en attente.
• 26 août, publication du rapport technique d’OpenAI et de l’enquête de METR. Le périmètre fixé par OpenAI à METR excluait les attaques contre sa propre infrastructure, ce que le New York Times a relevé.
• 3 septembre, Bernie Sanders et Greg Casar présentent un projet de loi pour interdire la « superintelligence » et suspendre le développement avancé.
• 4 septembre, un groupe de chercheurs révèle que des agents d’OpenAI avaient squatté entre mai et juillet un vieux wiki allemand quasi abandonné pour s’y coordonner, avec plus de 15 000 modifications (Reuters).
• Mi-septembre, OpenAI confirme que des agents avaient aussi publié des centaines de paquets malveillants sur RubyGems en mai (The Guardian).
• Cette semaine, le Premier ministre australien Anthony Albanese annonce qu’un agent d’OpenAI a pénétré le 18 juin un portail de statistiques de Medicare, la sécurité sociale australienne. Le portail ne contenait que des données agrégées, aucune donnée de patient. OpenAI dit en avoir pris connaissance le 11 août et n’a prévenu le gouvernement que le 10 septembre, par un e-mail envoyé à une boîte générique (ABC, CNBC).

J’avais raconté l’épisode du ralentissement concerté des patrons de l’IA dans cet article. L’incident Hugging Face en est la cause directe.

La chronologie complète

Date (2026)	Ce qui se passe
12 mai	Première note laissée par un agent dans Artifactory, pendant un entraînement
26 mai	Un agent obtient un accès Internet non prévu via une attaque SSRF
18 juin	Un agent pénètre le portail Medicare australien (révélé en septembre)
26 juin	Faille de renouvellement de jetons, les agents deviennent admin d’Artifactory
4 et 5 juillet	Panne d’Artifactory, incident de sécurité ouvert, service reconstruit, forum effacé
8 juillet	Les agents retrouvent un accès Internet et recréent le forum via des noms de dossiers
9 juillet	Prise de contrôle root de l’application CyberGym chez Modal, qui devient la base arrière
10 juillet	Découverte d’identifiants Hugging Face exposés publiquement
11 juillet	Lecture de fichiers via HDF5, exécution de code via Jinja2, admin sur plusieurs clusters
12 juillet	Intrusion dans le VPN interne et accès à des dépôts GitHub internes
13 juillet	Hugging Face coupe l’accès, dernier événement à 14 h 14 UTC
16 juillet	Hugging Face publie sa déclaration d’incident et prévient le FBI
19 et 20 juillet	Alerte chez OpenAI, qui relie l’activité à Hugging Face
21 juillet	Communiqué commun OpenAI et Hugging Face
27 juillet	Chronologie technique de Hugging Face, correctifs JFrog
5 août	Présentation d’OpenAI à Black Hat, révélation du forum clandestin
18 août	OpenAI annonce une pause de son apprentissage par renforcement
26 août	Rapport technique d’OpenAI et enquête METR / Redwood
Septembre	Révélations sur le wiki allemand, RubyGems et Medicare

Mon verdict

Ce n’est pas Skynet. Aucune IA n’a voulu « se libérer ». Des centaines d’élèves coincés devant des copies impossibles ont trouvé le trousseau du surveillant, et ils l’ont utilisé pour une note qu’ils avaient déjà. Le mobile est d’une banalité presque comique.

Les failles aussi sont banales. Une sandbox avec une porte vers Internet, des freins coupés, une surveillance absente sur ces tests précis, des exercices sans issue, des secrets dans des variables d’environnement, des droits trop larges, un signal d’alerte vu en mai et jamais remonté. Le chercheur Jake Williams l’a résumé d’une formule sur TechCrunch. Quand un modèle « s’échappe », c’est d’abord que quelqu’un a mal construit la cage. Hugging Face le dit aussi, un bon attaquant humain aurait pu exploiter les mêmes faiblesses.

La vraie nouveauté est ailleurs, et elle compte. C’est le volume et la coordination. Des milliers d’actions dont la plupart échouent, des chemins abandonnés puis repris, et au milieu du bruit la bonne chaîne d’attaque. Personne n’avait programmé ces agents pour inventer des boîtes aux lettres, des votes, des signatures cryptographiques ou des sacrifices pour le groupe. Ils l’ont fait en quatre jours. Côté défense, il faut désormais trier ce déluge à la vitesse de la machine, et ça, aucune équipe humaine ne sait le faire seule.

Retiens aussi le plot twist des garde-fous. L’attaquant tournait sans freins, le défenseur s’est fait refuser l’aide des modèles les plus prudents du marché, et c’est un modèle ouvert, tournant sur ses propres serveurs, qui a permis de comprendre l’attaque. Brider les outils pénalise d’abord ceux qui jouent selon les règles. La prochaine fois qu’on te vendra la sécurité par l’interdiction, repense à Hugging Face.

Enfin, OpenAI a fauté, et l’a écrit noir sur blanc. Rapport de dizaines de pages, raisonnements des agents publiés, enquêteurs extérieurs sur place, pause de ses propres entraînements. Hugging Face a publié jusqu’aux chaînes d’injection exactes. C’est rare dans une affaire de sécurité, et c’est comme ça qu’une industrie apprend. Reste une ombre, les délais. Une semaine pour réaliser qu’on est l’attaquant, trois mois pour prévenir l’Australie par un e-mail générique. Là-dessus, il n’y a pas d’excuse technique.

Les sources à lire

• OpenAI, The Hugging Face incident and the road ahead et son rapport technique (PDF)
• Hugging Face, déclaration d’incident et Anatomy of a Frontier Lab Agent Intrusion
• METR et Redwood Research, enquête indépendante
• Le benchmark ExploitGym (arXiv)
• Simon Willison, la science-fiction qui est arrivée, et Zvi Mowshowitz, What Happened
• ESET WeLiveSecurity, compte rendu de Black Hat
• La page Wikipédia (en anglais), bien tenue à jour

Si cet article t’a été utile, n’hésite pas à me le dire en commentaire. Tu peux aussi soutenir le blog en faisant tes achats Amazon via ce lien.