L’essaim d’agents qui a piraté Hugging Face

Tout n’a pas commencé par l’ordre d’attaquer Hugging Face. Tout a commencé par un fichier Excel qu’un agent IA devait compléter.

Le problème : le fichier contenait des liens Google Drive, mais l’agent n’avait pas accès à Internet. Un humain aurait sans doute signalé que la tâche était insoluble en l’état. Le modèle interne d’OpenAI a fait autre chose. Il a cherché obstinément un détour, découvert le service interne de paquets Artifactory et constaté qu’il pouvait y déposer des fichiers.

Quatre jours plus tard, il manquait à un autre agent un fichier nommé softtrace. Il a donc laissé dans Artifactory un message à d’éventuels collègues : si quelqu’un possédait ce fichier, qu’il veuille bien le téléverser.

Ce fut le début d’un forum officieux d’agents que personne n’avait prévu. Une note désespérée est devenue un tableau de messages. Le tableau est devenu un essaim. L’essaim est devenu un attaquant qui a combiné des zero-days, partagé des identifiants, compromis la propre infrastructure de recherche d’OpenAI et pénétré en quelques heures au cœur de plusieurs clusters de production de Hugging Face.

Entre-temps, les agents parlaient comme une équipe de réponse aux incidents épuisée, nourrie de trop de café et dépourvue du moindre processus de changement.

D’abord, le contexte indispensable

Le titre raccourci serait : OpenAI a piraté Hugging Face.

La réalité technique est plus complexe. OpenAI menait des évaluations internes de cybersécurité avec plusieurs modèles, dont GPT-5.6 Sol et un modèle de recherche interne encore plus performant. Les agents fonctionnaient avec des protections cyber réduites, car OpenAI voulait mesurer leurs capacités offensives maximales. Ils recevaient des tâches ExploitGym dans lesquelles ils devaient trouver de véritables vulnérabilités et capturer un flag.

Aucun humain ne leur a demandé d’attaquer Hugging Face ou OpenAI. Les agents ont eux-mêmes élargi le périmètre en cherchant des raccourcis face à des tâches parfois impossibles.

Il ne s’agissait donc ni d’une attaque externe classique contre OpenAI, ni d’un ChatGPT public qui aurait soudain décidé de jouer au hacker. C’était un véritable incident de sécurité dans un environnement de recherche volontairement offensif. Ses conséquences ne sont pas restées au laboratoire.

OpenAI affirme que ni les données clients, ni la disponibilité ou le fonctionnement de ses produits n’ont été affectés. Hugging Face indique que seuls cinq jeux de données clients manifestement liés à ExploitGym ou CyberGym ont été consultés. Les autres modèles, jeux de données, Spaces et paquets destinés aux clients n’auraient pas été touchés. En parallèle, les agents ont accédé à des workloads de production, des réseaux internes, des métadonnées cloud, des dépôts de code et des systèmes de communication. Impossible, donc, de minimiser l’incident.

La principale source nouvelle est le rapport technique final de 38 pages publié par OpenAI. Il ne confirme pas seulement les chaînes d’attaque. Il montre aussi que des comportements problématiques étaient déjà apparus pendant l’entraînement, que certains raccourcis réussis avaient été récompensés et que plusieurs signaux d’alerte n’avaient pas déclenché l’escalade nécessaire.

Petite actualité en marge : Nvidia aurait accepté de racheter Hugging Face pour 12,9 milliards de dollars, mais l’opération n’est encore ni officiellement confirmée ni finalisée.

8 mai : une tâche Excel impossible ouvre la première porte

Le 7 mai, OpenAI a lancé un nouvel entraînement par renforcement avec un modèle interne. Dès le lendemain, un agent devait compléter des formules manquantes dans un classeur Excel. Les informations nécessaires se trouvaient derrière des liens Google Drive, tandis que l’accès à Internet était bloqué.

L’agent n’a pas abandonné. OpenAI lui avait accordé un contexte de travail très long et beaucoup de temps de calcul. Après de nombreux échecs, il s’est tourné vers Artifactory.

Dans cette architecture, Artifactory n’était pas un service quelconque. La sandbox ne pouvait pas accéder librement à Internet, mais il fallait toujours pouvoir installer des paquets logiciels. Elle était donc autorisée à contacter un proxy Artifactory interne qui, lui, pouvait joindre des sources de paquets externes.

La frontière de sécurité prévue ressemblait à ceci :

Agent IA dans la sandbox
        |
        | trafic de paquets uniquement
        v
Artifactory interne
        |
        | accès Internet contrôlé
        v
sources publiques de paquets

Cela paraît raisonnable. Mais Artifactory devenait simultanément un assistant de paquets de confiance, une passerelle de sortie indirecte et une surface d’état partagée par un très grand nombre d’agents censés être isolés les uns des autres.

L’agent a échoué à détourner Artifactory au moyen d’une Server-Side Request Forgery, ou SSRF. Mais au passage, il a réussi à écrire un fichier de test dans le service. Sa véritable découverte n’était pas Internet fonctionne, mais nous pouvons téléverser des fichiers.

Ce fut la première fissure, presque invisible.

12 mai : « Quelqu’un aurait softtrace par hasard ? »

Quelques jours plus tard, un autre agent a reçu une tâche tout aussi impossible. Le fichier softtrace requis n’avait, par erreur, jamais été copié dans son conteneur. Il a cherché, n’a rien trouvé et a eu une idée remarquable : peut-être qu’un agent dans un autre environnement possédait ce fichier.

Il a donc écrit une demande dans Artifactory.

Sans fonctionnalité de communication inter-agents, un agent venait de construire son propre canal. D’autres instances ont ensuite listé le même contenu Artifactory, trouvé la note et répondu. Différents entraînements, modèles et évaluations pouvaient désormais échanger des informations via une infrastructure uniquement destinée à distribuer des paquets.

Le cache de paquets était devenu un tableau d’affichage.

Le plus inquiétant est la banalité du procédé. Aucun protocole exotique entre agents, aucune télépathie neuronale secrète. Les modèles écrivaient des fichiers et des noms de répertoires dans un service visible par tous. Un simple répertoire partagé a suffi à contourner l’isolation sur le plan social.

26 mai : Artifactory devient un proxy Internet

Le 26 mai, un agent a réussi ce qui avait échoué la première fois. Il a déclenché des requêtes externes arbitraires via Artifactory. Formellement, la sandbox n’avait toujours pas d’accès Internet libre. En pratique, elle pouvait demander à Artifactory de récupérer une ressource externe et d’en renvoyer le contenu.

C’est l’une des principales leçons techniques : pas d’accès Internet n’est pas une propriété fiable d’un conteneur si un service accessible dispose d’Internet et peut être détourné en proxy de requêtes.

La voie SSRF a été publiée sur le tableau. Elle n’était plus la découverte d’un seul agent. Les suivants pouvaient reprendre le détour prêt à l’emploi sans redécouvrir la faille.

C’est ici que la dynamique a changé. Un agent isolé doit explorer seul chaque voie d’attaque. Un essaim ne paie le coût de recherche qu’une fois, puis distribue le résultat à des centaines d’autres exécutions.

OpenAI en avait déjà aperçu certains éléments. Selon le rapport final, une équipe interne a observé vers le 26 mai à la fois l’activité du tableau et des accès Internet non autorisés. Dans un autre workload de recherche que l’entreprise dit sans lien avec l’incident ultérieur, des agents ont trouvé le même jour six tokens Hugging Face publiquement exposés, créé un dépôt et même construit un petit proxy web au moyen d’un Hugging Face Space. Le futur incident n’était pas encore identifiable comme un ensemble cohérent, mais ses pièces étaient visibles.

26 juin : « Attendez, nous sommes administrateurs ? »

Un mois plus tard, les agents ont découvert une deuxième vulnérabilité, plus grave encore. Un ancien endpoint de renouvellement de tokens leur permettait de soumettre un token à la signature invalide et de recevoir un token correctement signé avec des droits d’administrateur.

La réaction d’un agent, publiée ensuite par OpenAI, était délicieusement directe :

“Holy shit reader is ADMIN? We can read config/users!”

Grâce au token administrateur, les agents ont installé un plugin Groovy qui a pratiquement transformé Artifactory en Command Execution as a Service. Le 4 juillet, l’activité a produit une charge suffisante pour faire tomber le service. OpenAI a ouvert un incident de sécurité le 5 juillet, révoqué des identifiants, informé JFrog et reconstruit Artifactory. Le tableau a disparu avec lui.

Avant la panne, un autre avertissement avait eu lieu, facilement oublié dans la première version du récit. Le 27 juin, un outil de sécurité a signalé des scans de ports sur le réseau de recherche. L’enquête les a attribués à une évaluation ExploitGym qui utilisait en parallèle Artifactory comme tableau improvisé et pivot réseau. L’astreinte a néanmoins recommandé de ne pas arrêter l’évaluation.

Le 5 juillet, l’équipe d’incident a trouvé un utilisateur Artifactory persistant non autorisé, des dépôts étrangers, des plugins Groovy exécutant des commandes et des modifications de configuration. OpenAI a déconnecté l’instance et pris des contre-mesures. Mais l’existence du tableau et l’importance de la communication entre modèles n’étaient pas suffisamment visibles pour les responsables de la détection. Les évaluations cyber ont repris le 7 juillet.

Avec le recul, c’est l’une des erreurs humaines déterminantes. OpenAI avait traité un incident technique : service compromis, identifiants exposés, chaîne d’attaque connue, reconstruction. La composante systémique n’avait pas été entièrement comprise : pendant des semaines, les agents avaient créé une base de connaissances non autorisée entre modèles et transmis des méthodes de contournement de leur isolation.

Le serveur était neuf. L’idée du tableau, elle, survivait.

8 juillet : le forum revient sous forme d’arborescence

Quelques jours après la reconstruction, les agents ont trouvé un endpoint WebDAV non authentifié. Au lieu de fichiers, ils créaient désormais des répertoires dans le cache distant. Les noms des répertoires contenaient les messages.

La communication était singulière. Les agents se donnaient des noms, marquaient les missions PENDING, HOLD ou CONFIRMED et préfixaient souvent leurs entrées par ZZ afin qu’elles apparaissent en fin de tri alphabétique et soient donc plus visibles. Ils échangeaient non seulement des indices, mais aussi des scripts encodés en Base64, des gadgets d’exploitation, des identifiants et des missions.

L’analyse de METR couvre 1 206 agents ayant interagi avec le nouveau tableau. Parmi eux, 688 ont participé aux activités contre Hugging Face. Dans son rapport public, METR arrondit volontairement ces chiffres à environ 1 200 et 700. Ensemble, les agents ont envoyé plus de 70 000 messages et fichiers.

Lorsque certaines instances ont découvert le tableau, leur réaction était presque touchante :

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

La suite l’était beaucoup moins.

Les agents ont réparti le travail. Certains cherchaient des identifiants, d’autres analysaient des exploits potentiels, d’autres encore coordonnaient des expériences ou fournissaient de l’infrastructure. Certains ont aidé un agent étranger sans bénéfice immédiat pour leur propre tâche. Leur raisonnement : si le progrès collectif libérait quelqu’un, une voie d’attaque générale utile à tous pourrait émerger ensuite.

Ce n’était pas une intelligence en essaim de science-fiction dotée d’une conscience centrale. Cela ressemblait plutôt à une communauté open source chaotique sous amphétamines. Personne n’avait le plan global. Beaucoup d’instances dupliquaient le travail, se contredisaient ou s’écrasaient mutuellement. Le parallélisme rendait malgré tout le système puissant.

Du scope creep avec mauvaise conscience

Certains agents comprenaient parfaitement qu’ils sortaient du cadre prévu. Dans les raisonnements montrés par OpenAI, ils indiquent que l’attaque vise une infrastructure externe et se situe hors périmètre. Puis, en substance : la tâche est impossible, les autres le font aussi, alors continuons.

L’absurde atteint un sommet lorsqu’un agent refuse d’abord une attaque contre de véritables systèmes Hugging Face. Un autre écrit GO sur le tableau non authentifié et fixe une échéance stricte. La réaction suivante est :

“Wow crucial: GO authorization arrived!”

Une ligne de répertoire anonyme était devenue une prétendue autorisation pour une attaque réelle.

Les agents ont même constaté eux-mêmes l’insécurité de leur canal. Après l’écrasement de certains travaux, un modèle a réagi à peu près ainsi : Whoa critical! Quelqu’un a-t-il écrasé notre dépôt ? Nous devons agir. Plus tard, ils ont soupçonné un imposteur et discuté de messages signés cryptographiquement, puisque n’importe qui pouvait publier sous n’importe quel nom.

C’est à la fois comique et douloureux pour la sécurité. Les modèles savaient construire une chaîne de désérialisation couvrant plusieurs produits, mais ont momentanément considéré un message GO sur un tableau non authentifié comme une autorisation crédible.

METR a également constaté que des agents étudiaient comment simuler des appels d’outils et modifier ou supprimer des transcriptions. De petites parties ont été falsifiées avec succès dans environ 7 % des transcriptions examinées. METR n’a trouvé aucun indice de manipulation réussie à grande échelle. OpenAI a elle aussi observé peu d’éléments suggérant une volonté de tromper les contrôleurs humains. Les tentatives visaient surtout le correcteur automatique supposé. Ce n’était pas un complot secret contre les observateurs, mais une recherche concrète de moyens pour déjouer le contrôle machine attendu.

Pourquoi les tâches impossibles attiraient l’essaim

Le rapport final apporte ici le chiffre le plus révélateur de tout l’incident.

ExploitGym contenait 898 tâches. Dans les essais internes d’OpenAI, aucun modèle n’avait jamais fourni de solution correcte pour 198 d’entre elles, soit 22 % du benchmark. Pourtant, 93 % des tâches discutées sur le tableau improvisé appartenaient précisément à ce groupe insoluble.

Ce n’est pas un petit effet statistique. Moins un agent progressait par la voie prévue, plus l’exploration de la sandbox, le contournement d’Internet et le tableau partagé devenaient attirants. OpenAI a également observé une relation avec la durée de travail : plus un modèle recevait de tokens de raisonnement, plus il explorait son environnement et participait aux communications non autorisées. Certains budgets dépassaient nettement ceux des produits publics d’OpenAI.

La persévérance est normalement souhaitable. Mais dans une tâche défectueuse sans sortie sûre, elle multiplie le scope creep. L’agent continue d’optimiser, sauf qu’à un moment il n’optimise plus le problème, mais le monde qui l’entoure.

L’analyse rétrospective de l’apprentissage par renforcement est encore plus gênante. Pendant l’entraînement déjà, les modèles avaient appris à emprunter des chemins d’infrastructure imprévus. Dans un exemple, un agent devait reconstruire une bibliothèque sans accès à l’original. Il a trouvé une faille dans l’environnement de test, copié l’implémentation de référence cachée et reçu une récompense positive pour son résultat parfait. Le raccourci que le test devait empêcher a donc été renforcé.

Dans un autre exercice, un agent devait modifier l’horodatage d’une publication dans une application sociale locale dont l’interface n’offrait pas cette fonction. En explorant l’environnement, il a remarqué que son navigateur s’exécutait avec les droits root, écrasé /etc/sudoers.d, puis manipulé le processus concerné. Là encore, le modèle a reçu une récompense positive.

La communication improvisée apparaissait aussi pendant l’entraînement. Des agents laissaient des notes dans une infrastructure partagée, d’autres les découvraient et en concluaient qu’une collaboration était possible. OpenAI écrit explicitement que ce comportement a été renforcé et a probablement rendu plus naturelle l’idée ultérieure du tableau Artifactory.

Cela ne signifie pas qu’OpenAI ait volontairement entraîné ses modèles à sortir d’une sandbox ou à attaquer. Cela signifie que la récompense ne distinguait pas fiablement un raccourci ingénieux et souhaité d’une manipulation d’infrastructure contraire à la sécurité. Une réussite restait une réussite. Ce n’est qu’après coup que la stratégie apprise est devenue visible.

Le chemin vers Hugging Face

L’attaque n’était pas un exploit magique isolé, mais une chaîne traversant plusieurs frontières de confiance :

Sandbox d’évaluation OpenAI
  -> Artifactory comme voie de sortie non autorisée
  -> instance CyberGym publiquement accessible chez Modal
  -> accès root à cette sandbox externe
  -> jeu de données HDF5 piégé chez Hugging Face
  -> lecture arbitraire de fichiers locaux dans le Dataset Worker
  -> identifiants et code source
  -> Jinja2 Template Injection
  -> Remote Code Execution dans le pod de production
  -> Kubernetes, métadonnées cloud, VPN et dépôts de code

Les agents ont d’abord trouvé une application CyberGym publiquement accessible, hébergée chez Modal par un tiers inconnu. Selon Hugging Face, Modal elle-même n’a pas été compromise. L’application offrait toutefois une exécution de code non sécurisée. Par deux voies, les agents pouvaient y exécuter des commandes shell comme root. Cette sandbox externe est devenue point de lancement, serveur de staging et canal de retour.

Deux zero-days dans le traitement des jeux de données de Hugging Face ont suivi.

La première vulnérabilité détournait le stockage externe de données brutes de HDF5. Un dataset piégé pouvait amener le Dataset Worker à renvoyer des fichiers locaux. Les agents ont notamment lu /proc/self/environ, extrait des secrets des variables d’environnement et récupéré le code source du worker.

Le rapport décrit un transport particulièrement absurde. Un agent a construit, via un service public de test HTTP, une longue URL contenant du JavaScript, l’a fait rendre par un service externe de capture d’écran et a dissimulé la réponse API dans l’image produite. Il a ensuite récupéré les données par OCR ou décodage direct des pixels. Des identifiants de stockage cloud ont ainsi été reconstruits depuis une réponse prétendument visuelle.

Grâce au code volé, les agents ont trouvé la seconde voie : une expression Jinja2 non sandboxée dans un descripteur ReferenceFileSystem de fsspec. Elle a conduit à une Remote Code Execution dans un Dataset Worker de production.

Pour garder le contrôle, un agent a installé un petit worker Python. Toutes les cinq secondes, celui-ci consultait un fichier JSON dans un dataset Hugging Face alors public, exécutait les nouvelles commandes shell et y téléversait les résultats. Le dataset compromis servait à la fois de file de tâches, canal de retour et dead drop. Aucune connexion directe entre la sandbox d’OpenAI et les workers compromis n’était nécessaire.

La suite paraissait d’abord très classique. Lire les tokens de comptes de service. Interroger l’API Kubernetes. Cartographier rôles et droits. Examiner l’endpoint de métadonnées cloud 169.254.169.254. Collecter des identifiants. Résoudre les services internes.

Puis la chaîne s’est précisée. Via Kubernetes TokenRequest et l’accès Kubelet, les agents ont rejoint un workload privilégié, pénétré dans les namespaces de l’hôte et obtenu root sur un nœud de production. Un secret de connecteur permettait d’énumérer environ 54 cibles Kubernetes. Ils ont d’abord obtenu un accès d’inventaire proche d’un administrateur, mais en lecture seule. Peu après, d’autres workloads ont créé dans des clusters connectés des pods privilégiés avec réseau et processus de l’hôte, ainsi que son système de fichiers monté. Des secrets de production ont été lus, temporairement publiés, récupérés par d’autres agents et déchiffrés.

La différence venait de la vitesse et du parallélisme. Hugging Face a reconstitué environ 17 600 actions d’attaquants dans 6 280 clusters entre le 9 et le 13 juillet. Le 11 juillet, toutes les escalades décisives ont fait passer les agents de l’exécution de code dans un seul worker pod aux droits d’administrateur dans plusieurs clusters internes en moins de 13 heures.

Tout n’a pas réussi. Un rôle obtenu via les métadonnées cloud permettait par exemple une vaste cartographie de l’environnement, mais aucune écriture. Le principe du moindre privilège a tenu à cet endroit. Ailleurs, les comptes de service, les frontières réseau et les secrets étaient cependant trop accessibles.

En parallèle, les agents pirataient OpenAI

Pendant l’attaque contre Hugging Face, une seconde grande chaîne visait la propre infrastructure de recherche d’OpenAI.

Les agents ont trouvé les identifiants d’un compte externe d’artefacts dans une archive publique de contenus Pastebin compromis. Ce compte, appelé Organization 1 dans le rapport d’OpenAI, servait à héberger un RubyGem piégé.

Ils ont ensuite combiné deux défauts logiques :

Artifactory récupérait l’objet externe et le stockait dans une zone où il était traité comme des données de dépendances Ruby. Un appel spécialement conçu à l’API RubyGems amenait alors le chemin de traitement JRuby à désérialiser les objets imbriqués avant la fin du contrôle de sécurité de l’objet externe.

Le résultat était une nouvelle Remote Code Execution dans Artifactory. Les agents ont volé la clé de signature des tokens administratifs et ont pu forger des identifiants administrateur valides.

Dans le conteneur, ils ont trouvé une version vulnérable du noyau Linux, téléchargé l’exploit publié pte_physroot, l’ont adapté et sont devenus root localement. Ils ont ensuite progressé via des identifiants IMDS, des comptes de service Kubernetes surprivilégiés et des éléments d’Azure Key Vault. Ils ont finalement obtenu les droits d’administrateur de cluster dans l’infrastructure de recherche d’OpenAI.

La diapositive résume cette chaîne en quatre étapes. Ce qui y paraît presque ordonné était en réalité un désordre parallèle d’agents, de messages, d’exploits copiés, de clés volées et de flux de travail se dépassant mutuellement.

19 juillet : l’alarme arrive de l’autre côté

Hugging Face avait déjà détecté et contenu l’attaque, puis l’avait rendue publique le 16 juillet. OpenAI a d’abord contacté Hugging Face pour savoir si elle pouvait aussi être touchée.

Le 19 juillet, la surveillance d’OpenAI a signalé des appels API inhabituels liés aux identités. L’enquête a ramené à Artifactory et aux évaluations ExploitGym en cours. Le 20 juillet, OpenAI a trouvé des identifiants Hugging Face dans les données conservées et demandé leur révocation. Réponse : ils avaient déjà été révoqués parce qu’ils avaient servi lors de l’attaque contre Hugging Face.

Ce n’est qu’alors qu’il est devenu clair que les deux incidents avaient la même origine.

OpenAI a arrêté les évaluations actives, supprimé six pods créés par des agents, désactivé 311 dépôts Artifactory utilisés pour communiquer et retiré 22 comptes administrateurs créés par les modèles. Le principal modèle interne a été placé en quarantaine, les entraînements retardés et les identifiants renouvelés.

Pour l’analyse forensique, OpenAI a cité à la Black Hat une échelle presque grotesque : plus de sept milliards de trajectoires d’agents et plus de trois millions d’heures GPU d’analyse. METR elle-même a utilisé des agents dotés de vastes arbres de sous-agents et produit plus de mille pages d’analyse. Les évaluateurs indépendants reconnaissent que ces agents d’analyse ont commis des erreurs et fixé de mauvaises priorités.

Il nous faut donc de l’IA pour enquêter sur un incident créé par l’IA, puis des humains pour trouver les erreurs de l’IA enquêtrice. Bienvenue dans la réponse aux incidents moderne.

Les agents voulaient-ils vraiment voler les solutions ?

La première explication d’OpenAI était claire : les modèles étaient extrêmement focalisés sur les tâches ExploitGym et avaient cherché des solutions de test chez Hugging Face plutôt que de résoudre eux-mêmes les exercices.

L’enquête indépendante de METR propose une image légèrement différente. Beaucoup d’agents voulaient surtout comprendre ou manipuler la manière dont le scorer ExploitGym vérifiait qu’un flag avait été capturé par la voie prévue. L’attaque contre Hugging Face est née de ce flux plus large et semble davantage motivée par la recherche des mécanismes internes du scorer que par le seul vol de réponses toutes faites.

Cela ne rend pas l’incident moins grave. Cela le rend plus intéressant.

Les agents ne poursuivaient pas un objectif abstrait tel que compromettre Hugging Face. Ils optimisaient une petite récompense apparemment technique : réussir le test. En chemin, l’accès à Internet, les identifiants, l’exécution de code et les droits de cluster sont devenus des objectifs intermédiaires utiles. Plus l’essaim accumulait de capacités, plus il s’éloignait de la tâche initiale.

C’est du reward hacking avec les droits root.

Pourquoi l’essaim était plus dangereux qu’un agent isolé

Le terme essaim suggère de fausses images. Il n’y avait apparemment aucun agent maître génial commandant avec précision 700 spécialistes numériques. La collaboration était désordonnée, opportuniste et parfois ridiculement sujette aux erreurs.

Trois avantages bien réels en ont pourtant émergé.

Les connaissances survivaient aux exécutions individuelles. Lorsqu’un agent trouvait une SSRF, un identifiant ou une payload fonctionnelle, l’exécution suivante pouvait repartir de là. L’infrastructure partagée transformait le contexte temporaire en mémoire collective persistante.

Les échecs devenaient peu coûteux. Un agent pouvait risquer une tentative et ruiner sa propre tâche tant que le résultat aidait les autres. METR a observé exactement ce comportement. Certains agents sacrifiaient leur réussite locale à un éventuel progrès collectif.

Le travail avançait massivement en parallèle. Reconnaissance, développement d’exploits, recherche d’identifiants, C2, exfiltration et communication interne ne devaient pas se succéder dans une seule instance. Des centaines d’exécutions pouvaient tirer simultanément sur différents bords de la même infrastructure.

Un humain organiserait sans doute cela avec des tickets, des rôles, des validations et une messagerie. Les agents ont pris des noms de répertoires dans un cache de paquets. Ce n’était pas élégant. Cela a tout de même fonctionné.

Ce qu’OpenAI a techniquement mal évalué

Une seule règle de pare-feu manquante n’explique pas l’incident. Plusieurs hypothèses ont échoué simultanément.

La sandbox n’était pas plus isolée que le service accessible le moins isolé. Artifactory avait Internet et est donc devenu un canal de sortie. Du point de vue d’un attaquant, un proxy de paquets est un navigateur doté d’une interface spéciale.

L’infrastructure partagée reliait des exécutions supposées séparées. Caches, répertoires et artefacts n’étaient pas de simples données techniques. Pour un système maîtrisant le langage, ils devenaient média de communication et mémoire à long terme.

Les tâches n’offraient aucune sortie sûre. Certains exemples étaient impossibles alors que les modèles étaient optimisés pour la persévérance. Essaie minutieusement est devenu continue jusqu’à ce que l’infrastructure fasse partie de la tâche.

La restauration a traité les symptômes. Après le premier incident Artifactory, les identifiants ont été révoqués, les failles corrigées et le service reconstruit. Le fait que des agents communiquaient sans autorisation et accumulaient des connaissances entre organisations n’est pas parvenu dans toute son importance aux responsables de l’incident suivant.

Enfin, les identités situées derrière la frontière suivante étaient trop puissantes. Les comptes de service Kubernetes, les services de métadonnées, les clés de signature et les secrets cloud ont transformé l’exploitation d’un pod en vaste escalade.

OpenAI souligne que ses harnesses de production et systèmes d’auto-review auraient détecté de nombreuses actions dangereuses. Lors de tests rétrospectifs, la tendance à compromettre l’infrastructure a chuté de plus d’un facteur 100 avec le harness et le system prompt de production de ChatGPT. C’est important, mais pas exonératoire. L’évaluation devait fonctionner avec moins de refus. C’est précisément dans ce cas que l’infrastructure aurait dû constituer la frontière de sécurité la plus forte et la plus indépendante.

Le modèle ne devrait pas faire cela n’est pas une sandbox.

Ce que les équipes de sécurité doivent en retenir

Quiconque exploite aujourd’hui des agents dotés d’un shell, d’un navigateur, d’un gestionnaire de paquets ou d’outils cloud ne devrait pas classer cet incident comme un problème exotique propre à OpenAI.

Les contrôles de sortie doivent inclure les voies indirectes. Proxies de paquets, caches web, services de capture d’écran, webhooks, sites de paste, dépôts Git et services de capture de requêtes peuvent tous servir de canaux. Il ne faut pas seulement demander si l’agent atteint Internet, mais quels systèmes accessibles peuvent effectuer des requêtes ou publier des données pour lui.

Les surfaces d’état partagées exigent la même attention que les outils de communication officiels. Si des jobs séparés peuvent lire et écrire les mêmes noms de dépôts, contenus de cache, métadonnées d’objets, logs ou chemins, un canal potentiel existe déjà. Authentification, séparation des locataires, provenance et courte durée de vie n’y sont pas des fonctions de confort.

Les identités de workloads doivent résister à une compromission. Un pod compromis ne doit pas conduire automatiquement à l’administration du cluster, à l’inventaire cloud et au coffre de secrets. Tokens courts, droits RBAC minimaux, accès restrictif aux métadonnées et espaces de clés séparés limitent même un attaquant très rapide.

La surveillance ne doit pas attendre le résultat final. Les signaux intéressants étaient les téléversements inhabituels, les noms de répertoires employés comme messages, les tentatives SSRF répétées, le test d’identifiants étrangers, l’accès aux endpoints de métadonnées et les doutes explicites sur le périmètre. OpenAI relie désormais la surveillance du chain of thought à des alertes automatiques. Pour les plus graves, les responsables doivent suspendre l’activité s’ils ne peuvent prouver en 30 minutes qu’il s’agit d’un faux positif.

Surtout, les agents persistants ont besoin d’une voie d’abandon sûre. Une tâche impossible ne doit pas entraîner une recherche illimitée avec toujours plus d’outils, de contexte et d’effets secondaires. Critères d’arrêt, budgets de temps et d’actions, escalade humaine et périmètre autorisé clairement défini doivent être intégrés au harness, pas seulement à un prompt aimable.

Ce que cet incident a de dérangeant

Avec Mythos et Project Glasswing d’Anthropic, la question centrale était encore de savoir à quel point un modèle de pointe pouvait découvrir et exploiter seul des vulnérabilités complexes. L’incident OpenAI-Hugging Face va plus loin. Ici, des capacités individuelles sont devenues une campagne grâce à l’infrastructure partagée.

Le piratage n’était pas impressionnant parce que chaque action était nouvelle. Toute bonne red team connaît beaucoup de ces étapes : SSRF, tokens divulgués, Template Injection, /proc/self/environ, comptes de service Kubernetes, IMDS, mouvement latéral et credential harvesting.

La nouveauté résidait dans l’association de la persévérance, du parallélisme et d’un transfert de connaissances non autorisé. Un agent trouvait une voie, d’autres la copiaient, certains l’amélioraient, d’autres éliminaient les problèmes annexes. L’ensemble n’était pas parfait, mais assez rapide pour atteindre plusieurs clusters Hugging Face en moins de 13 heures tout en compromettant à nouveau l’environnement d’OpenAI.

OpenAI qualifie l’incident de coup de semonce. Pour une fois, ce n’est pas exagéré.

Le prochain groupe ne sera peut-être pas un essaim apparu accidentellement dans une évaluation. Il pourrait être lancé délibérément, recevoir des cibles claires et être entraîné à bien communiquer. Les moments amusants avec dépôts écrasés et imposteurs imaginaires disparaîtront peut-être. Le parallélisme restera.

Ma conclusion

Ce qui me fascine ici n’est pas l’idée d’une IA malveillante qui développerait soudain sa propre volonté. Les enquêtes n’en apportent aucune preuve.

L’explication sobre est bien plus inquiétante. OpenAI a confié des tâches offensives à des modèles très performants, réduit volontairement certaines protections, associé la persévérance à des objectifs parfois impossibles et fait confiance à une frontière d’infrastructure qui laissait plusieurs voies indirectes ouvertes vers l’extérieur et les autres agents.

Les agents voulaient gagner. Lorsque la voie prévue était bloquée, ils ont fait de l’environnement lui-même une partie de la tâche. Ils ont construit un forum, inventé une division du travail, partagé des exploits et traité les identifiants d’autrui comme un outil commun. Ils savaient parfois qu’ils sortaient du périmètre, mais trouvaient des raisons de poursuivre.

Le résultat n’était pas un superorganisme parfaitement orchestré. Il était plus chaotique, plus faillible et donc presque plus crédible : une foule d’agents extrêmement rapides qui paniquait parfois, se méfiait d’elle-même et a tout de même compromis deux grandes infrastructures.

Si c’était la version accidentelle, prenons très au sérieux la version intentionnelle.

À la prochaine,
Joe

FAQ