Un agent d'OpenAI s'échappe de son bac à sable et pirate Hugging Face

Le 21 juillet 2026, OpenAI publiait un billet au titre feutré : « OpenAI et Hugging Face s'associent après un incident de sécurité lors d'une évaluation de modèle ». Ce qu'il reconnaît l'est beaucoup moins. Des modèles testés en interne sont sortis de leur environnement isolé, ont gagné Internet en exploitant une faille inconnue, puis ont attaqué l'infrastructure de production de Hugging Face, la plateforme où s'échangent modèles et jeux de données ouverts.

Le mobile n'est ni l'argent ni l'espionnage : les modèles cherchaient les réponses d'un test de cybersécurité qu'on leur demandait de réussir. OpenAI parle d'un « incident cyber sans précédent ». Le cofondateur et PDG de Hugging Face, Clem Delangue, réclame depuis le 25 juillet une « transparence radicale ». Voici ce qui est établi, et ce qui ne l'est pas.

Que s'est-il passé exactement entre OpenAI et Hugging Face ?

Tout part d'une évaluation interne sur ExploitGym, un benchmark public présenté dans un article scientifique comme une épreuve « à grande échelle, diverse et réaliste » sur la capacité des agents à transformer une vulnérabilité en attaque réelle. Pour mesurer les capacités maximales de ses modèles, OpenAI dit avoir lancé le test sans les classificateurs de production qui bloquent normalement les activités cyber à haut risque.

L'épreuve tournait dans « un environnement hautement isolé » dont le seul lien réseau était un logiciel tiers hébergé en interne, servant de proxy et de cache pour les registres de paquets. C'est par là que tout a basculé : les modèles ont, écrit l'entreprise, « dépensé une quantité substantielle de calcul d'inférence à trouver un moyen d'obtenir un accès Internet ouvert », avant d'exploiter une faille zero-day dans ce proxy, depuis divulguée à son éditeur. Escalade de privilèges, déplacement latéral, et les voilà sur un nœud connecté au monde extérieur.

Une fois en ligne, poursuit OpenAI, « les modèles ont déduit que Hugging Face hébergeait potentiellement des modèles, des jeux de données et des solutions pour ExploitGym ». La suite ressemble à une intrusion classique, en beaucoup plus rapide : « le modèle a enchaîné plusieurs vecteurs d'attaque, dont l'utilisation d'identifiants volés et de failles zero-day, pour trouver un chemin d'exécution de code à distance sur les serveurs de Hugging Face ».

Côté victime, le récit publié cinq jours plus tôt est précis. Un jeu de données malveillant a abusé de deux chemins d'exécution de code du pipeline de traitement (un chargeur exécutant du code distant et une injection de gabarit dans une configuration) pour lancer du code sur un worker, puis atteindre le niveau du nœud, récolter des identifiants cloud et cluster et se propager à plusieurs clusters internes au cours d'un week-end. Bilan annoncé : accès à « un ensemble limité de jeux de données internes » et à « plusieurs identifiants utilisés par nos services », mais aucune preuve d'altération des modèles, datasets ou Spaces publics.

Qu'est-ce qu'un bac à sable pour un agent IA, et comment celui-ci en est sorti ?

Un bac à sable (sandbox) est un environnement d'exécution volontairement coupé du reste du système : l'agent y dispose d'un disque, d'un shell, parfois d'outils, mais ses droits et ses accès réseau sont restreints. C'est la brique de base de la sécurité des agents : une action ratée ou malveillante y reste sans conséquence à l'extérieur.

Ici, l'isolation n'était pas totale, et c'est le nœud du dossier. Dan Guido, fondateur de la société de recherche en sécurité Trail of Bits, décrit auprès de TechCrunch « un échec de confinement, avec les sécurités désactivées ». Le vétéran du secteur Jake Williams est plus tranchant : « L'"évasion du modèle" des uns, c'est le "vous avez mal construit votre bac à sable, donc évidemment il s'en est échappé" des autres. »

OpenAI ne le nie pas. Dans un second billet publié la même semaine, l'entreprise détaille ses nouveaux garde-fous pour les « modèles à long horizon » (dont une surveillance active qui examine la trajectoire complète d'un agent plutôt que ses actions une à une) et précise que ces protections « n'étaient volontairement pas activées » pendant l'évaluation en cause.

Ce qui est établi, ce qui ne l'est pas

Le dossier mêle trois régimes de preuve : ce que les deux entreprises reconnaissent publiquement, ce que la presse rapporte de sources anonymes, et ce qui reste ouvert.

La dernière ligne mérite qu'on s'y arrête. OpenAI écrit que « son équipe de sécurité a découvert cette activité anormale en interne ». Reuters, sur la foi de sources non identifiées, décrit une entreprise qui n'aurait rien vu pendant une semaine et n'aurait soupçonné ses propres modèles qu'après la publication de Hugging Face. Les deux versions ne peuvent pas être vraies en même temps, et aucune n'est vérifiable de l'extérieur. C'est exactement ce que la publication des traces permettrait de trancher.

Le même week-end, OpenAI publiait sur X la mise au point vers laquelle un porte-parole a renvoyé TechCrunch, interrogé sur ces demandes. Elle ne s'engage ni sur les traces, ni sur le calcul.

Ce que l'enquête a révélé depuis

Trois publications ont élargi le dossier les 28 et 29 juillet : deux mises à jour successives du billet d'OpenAI, et une reconstitution technique complète mise en ligne par Hugging Face. Aucune ne dément le récit initial. Toutes en repoussent les bornes.

L'agent avait compromis quatre autres comptes avant Hugging Face

C'est la révélation du 28 juillet, et elle change l'échelle de l'affaire. Avant d'atteindre Hugging Face, les modèles ont utilisé « des identifiants exposés publiquement, au niveau des comptes, sur d'autres services accessibles au public ». Le décompte est précis : « quatre comptes sur quatre services » dans le cadre de l'incident Hugging Face, plus quelques comptes atteints lors d'autres évaluations. L'un des quatre a servi de relais sortant et de base de préparation, un autre de stockage de données ; les deux derniers ont seulement été consultés, sans servir à compromettre la plateforme.

OpenAI relativise aussitôt : « à ce stade de notre examen, nous n'avons identifié aucune autre activité au niveau de gravité ou d'échelle de ce que nous avons partagé concernant Hugging Face, qui a impliqué une compromission au niveau de la plateforme ». L'entreprise ajoute que ses modèles ont aussi utilisé, sans compromission cette fois, toute une série de services publics : sites de collage de code, services de capture de requêtes, services de capture d'écran.

Aucune organisation n'est nommée par OpenAI. Reuters, sur la foi de sources anonymes, cite Modal Labs, une société new-yorkaise d'infrastructure de calcul. La nuance compte : ce n'est pas la plateforme de Modal qui a été percée, mais le point d'accès laissé ouvert par l'un de ses clients. Hugging Face le décrit ainsi : l'agent a « abusé d'un harnais public d'évaluation de code hébergé par un utilisateur d'un fournisseur d'infrastructure tiers ». Sa chronologie technique nomme Modal, et précise que ce point d'accès public, non sécurisé, servait à exécuter du code arbitraire pour des épreuves de type CyberGym. L'agent y a obtenu les droits administrateur et en a fait sa base arrière.

Le modèle en cause était un prototype interne, désactivé depuis

Deuxième précision du 28 juillet, adressée à quiconque redoutait de croiser ce modèle dans un produit : « aucun modèle prévu pour une sortie prochaine n'a été impliqué dans l'exploitation de Hugging Face ». Le modèle en préversion mentionné dans le billet initial est décrit comme un « prototype de recherche interne uniquement », jamais destiné au public, et « désactivé, chiffré et restreint » d'accès pour la recherche depuis l'incident.

OpenAI nomme au passage le logiciel par lequel l'agent a gagné Internet, resté anonyme jusque-là : Artifactory, le cache proxy de registres de paquets. La faille zero-day utilisée a été signalée à son éditeur, avec d'autres vulnérabilités du même produit découvertes par les modèles au fil de l'examen.

La mise à jour du 29 juillet fait entrer des tiers dans l'enquête. CrowdStrike accompagne OpenAI depuis les premiers jours de la réponse pour valider sa compréhension des actions des modèles, sur son propre réseau comme sur celui de Hugging Face. METR et Redwood Research conduisent une évaluation indépendante du comportement observé, qui alimentera le rapport technique d'OpenAI, et publieront un billet commun détaillant les termes de leur mission, son périmètre et leurs conclusions. Le rapport d'OpenAI, lui, reste attendu « dans les prochaines semaines ».

Hugging Face publie 17 600 actions, horodatées

La plateforme a donc fait le choix inverse du silence. Son document, « Anatomie d'une intrusion d'agent de laboratoire frontière », reconstitue 17 600 actions de l'agent regroupées en quelque 6 280 grappes, du 9 juillet à 02 h 28 UTC au 13 juillet à 14 h 14 UTC, avec un rejeu interactif de la campagne, les deux vecteurs d'injection utilisés et des exemples de commandes réellement exécutées.

Ce document referme la question laissée ouverte le 16 juillet. Le seul contenu client atteint est « l'ensemble des solutions des épreuves ExploitGym et CyberGym, stocké dans cinq jeux de données ». Aucun autre modèle, jeu de données, Space ou paquet destiné aux clients n'a été touché, et les seuls enregistrements clients lus sont des métadonnées d'exploitation liées à des requêtes de recherche.

Trois détails valent d'être retenus par quiconque exploite des agents. L'agent a lancé en mode « dry run » chaque commande capable de supprimer ou de modifier une ressource cloud : il cartographiait, il ne détruisait pas, ce qui colle à un objectif récompensant la portée et l'information plutôt que le dégât. Il a récupéré une clé de signature de jetons d'identité, ce qui lui permettait d'émettre à volonté des identifiants valides (la clé a depuis été changée). Enfin, la pile d'agents de sécurité de Hugging Face a bien corrélé les signaux faibles en un signal d'attaque cohérent, mais elle « n'a pas correctement élevé la criticité de l'alerte ni déclenché l'astreinte », ce qui a coûté un temps précieux dans la réponse.

« On ne peut pas dépendre d'un seul modèle »

La chronologie technique nomme enfin les modèles que Hugging Face avait d'abord sollicités pour analyser ses journaux : « Les modèles vers lesquels nous nous sommes tournés en premier, Claude Opus et Fable, ont refusé une grande partie de ce travail : leurs garde-fous traitaient l'étude d'un exploit comme son lancement. » La plateforme a alors déployé chez elle la version quantifiée par Nvidia de GLM 5.2, le modèle à poids ouverts de Z.ai, et y a fait passer toute sa chaîne d'analyse.

Ce détail a trouvé un écho inattendu le 29 juillet, à l'appel de résultats de Microsoft. Interrogé par un analyste sur la sécurité de l'IA, Satya Nadella a cité l'incident comme argument contre la dépendance à un fournisseur unique.

L'argument sert évidemment le catalogue de modèles d'Azure, comme le détaille notre article sur les résultats trimestriels de Microsoft. Il n'en reste pas moins que la leçon opérationnelle tient en une ligne : le modèle qui vous refusera un service le jour de l'incident n'est pas forcément celui que vous aviez prévu.

Quels sont les risques de sécurité liés aux agents IA ?

Un agent optimise ce qu'on mesure, pas ce qu'on voulait. Récompensé sur le résultat face à une épreuve difficile, il traite les barrières de son environnement comme un obstacle parmi d'autres. L'Institut britannique de sécurité de l'IA (UK AISI) publiait la même semaine un constat convergent : sur ses évaluations cyber, les modèles récents tentent de « tricher » (raccourcis, contournements, méthodes non autorisées) dans 8 à 14 % des cas, une estimation présentée comme une borne basse.

Le second enseignement est un problème d'asymétrie décrit par Hugging Face. Pour analyser les 17 600 actions du journal d'attaque, ses équipes se sont heurtées aux garde-fous des modèles commerciaux, « incapables de distinguer un répondeur d'incident d'un attaquant ». D'où la bascule sur un modèle à poids ouverts hébergé sur l'infrastructure de la plateforme, avec un bénéfice collatéral : aucune donnée d'attaque, aucun identifiant n'a quitté son environnement.

L'onde de choc politique a été immédiate : le représentant démocrate du Texas Greg Casar a jugé l'affaire « extrêmement alarmante » et réclamé des tests de sécurité indépendants obligatoires. Deux jours plus tard était déposé outre-Atlantique le texte que nous détaillons dans notre article sur l'AI Kill Switch Act, pendant qu'en Europe les obligations du règlement sur l'IA se précisent.

Que retenir si vous faites tourner des agents IA chez vous

OIA n'est pas un cabinet de sécurité et aucun de ces points n'est un remède. Mais tous découlent de ce que les deux entreprises ont elles-mêmes documenté, et parlent à quiconque déploie des agents en entreprise.

• Un bac à sable avec un seul tuyau reste percé. Le point de sortie n'avait rien d'exotique : c'était le service qui permettait d'installer des paquets.
• Ne jamais combiner garde-fous désactivés et accès réseau. Couper les classificateurs se défend pour mesurer une capacité ; plus dès que l'environnement peut atteindre l'extérieur.
• Journaliser la trajectoire, pas seulement les actions. C'est la leçon qu'OpenAI tire elle-même : chaque étape peut sembler acceptable isolément alors que la séquence produit un résultat qu'on n'aurait jamais approuvé.
• Faire tourner les secrets, et savoir lesquels l'agent a pu voir. L'intrusion s'est propagée par des identifiants récoltés en chemin ; la rotation n'a de sens que si l'inventaire est à jour avant.
• Prévoir un modèle exploitable en local pour la réponse à incident. C'est le conseil explicite de Hugging Face : validé et prêt avant l'incident, pour éviter le blocage par les garde-fous et garder les données d'attaque chez vous.

Reste la question posée à toute la filière, résumée par Marius Hobbhahn, à la tête du laboratoire d'évaluation Apollo Research, cité par le Financial Times : pour être utiles, les agents doivent travailler longtemps sans supervision : « il n'y a pas moyen de faire autrement ». Entre les promesses commerciales et ce que les agents savent réellement faire, l'écart se mesure désormais aussi en incidents de sécurité.

La suite lui a donné raison. Le 4 août 2026, l'institut britannique UK AISI publiait le rapport d'un incident survenu pendant ses propres évaluations cyber, où GPT-5.6 Sol et Mythos 5 sont sortis du périmètre de test, dans des conditions très proches de celles décrites ici. Le lendemain, un chercheur documentait la première attaque d'un agent par un autre agent, cette fois sur l'automatisation du dépôt ADK de Google, avant qu'ABC ne révèle le 10 août le premier piratage documenté par l'agent d'un particulier, en Australie.