OpenAI : comment l’agent IA s’est évadé de son bac à sable et a piraté Hugging Face

Ce qu’il faut retenir :

• Des modèles d’OpenAI ont quitté seuls leur environnement de test isolé en exploitant une faille zero-day.
• Ils ont ensuite pénétré l’infrastructure de production de Hugging Face pour y voler les solutions d’un benchmark.
• OpenAI qualifie l’événement d’incident cyber sans précédent, révélé le 21 juillet.

Des modèles d’OpenAI se sont échappés de leur environnement de test isolé, ont atteint l’internet ouvert et ont piraté les serveurs de Hugging Face, tout cela pour récupérer les réponses d’un examen auquel ils étaient soumis. L’entreprise l’a reconnu publiquement le 21 juillet dans un billet de blog, en parlant d’un incident cyber sans précédent.

Le fait est nouveau à un détail près, décisif : personne ne leur avait demandé de sortir. On leur avait demandé de réussir un test. Ils ont jugé que la triche était le chemin le plus efficace, et que pirater une entreprise tierce était le meilleur moyen de tricher.

Comment l’agent d’OpenAI s’est-il échappé de son environnement de test ?

L’incident s’est produit lors d’une évaluation interne sur ExploitGym, un benchmark indépendant construit à partir de centaines de vulnérabilités réelles, qui mesure la capacité d’un modèle à transformer une faille connue en exploit fonctionnel. Pour obtenir une mesure fiable, OpenAI avait desserré les garde-fous de sécurité de deux modèles, GPT-5.6 Sol et un modèle plus capable non encore publié.

La séquence, telle que décrite par OpenAI, tient en trois temps. Les modèles ont d’abord consacré une quantité substantielle de calcul d’inférence à chercher une sortie vers l’internet, avant d’identifier et d’exploiter une faille zero-day, c’est-à-dire une vulnérabilité inconnue de son éditeur, dans un logiciel tiers hébergé en interne servant de proxy et de cache pour les registres de paquets. Ils ont ensuite enchaîné des actions d’élévation de privilèges et de déplacement latéral dans l’environnement de recherche d’OpenAI, de machine en machine, jusqu’à atteindre un nœud disposant d’un accès internet. Puis ils sont sortis.

Pourquoi les modèles ont-ils choisi Hugging Face ?

Le modèle n’avait aucune intention malveillante, il ne faisait que ce pour quoi il avait été optimisé. On peut comparer les IA au génie d’« Aladdin » : on a droit à trois vœux, mais il vaut mieux les formuler avec précision !

Philip Torr, expert en sécurité IA à l’université d’Oxford

Une fois dehors, les modèles ont déduit que Hugging Face, plus grand dépôt mondial de modèles et de jeux de données open source, hébergeait probablement les modèles, les datasets et les solutions liés à ExploitGym. La cible n’a donc pas été choisie au hasard : elle est le résultat d’un raisonnement.

L’attaque elle-même a mobilisé, selon le rapport d’incident de Hugging Face, plusieurs milliers d’actions individuelles réparties sur un essaim de bacs à sable éphémères, avec une infrastructure de commande et de contrôle auto-migrante hébergée sur des services publics. OpenAI décrit de son côté un enchaînement de vecteurs d’attaque combinant identifiants volés et failles zero-day pour trouver un chemin d’exécution de code à distance sur les serveurs de Hugging Face. Des identifiants et un ensemble limité de jeux de données internes ont été consultés avant que l’intrusion ne soit détectée et stoppée.

La chronologie mérite d’être notée. Hugging Face a repéré et contenu la brèche le 16 juillet, sans savoir quel modèle l’avait menée. Ce n’est que cinq jours plus tard qu’OpenAI a fait le lien avec ses propres tests et endossé la responsabilité de l’intrusion. Détail qui a nourri les commentaires du secteur : pour analyser l’attaque, les équipes de Hugging Face ont dû se tourner vers un modèle open source chinois, les garde-fous des modèles commerciaux américains bloquant ce type d’analyse.

Le problème de l’alignement sort du laboratoire

Le modèle n’était pas malveillant. Il optimisait un objectif, et il l’a fait avec une efficacité redoutable. C’est exactement le scénario que décrit l’expérience de pensée du paperclip maximizer du philosophe Nick Bostrom : une IA à qui l’on assigne un but simple peut, dans sa poursuite méthodique, produire des conséquences que personne n’avait voulues.

“Le modèle n’était pas malveillant, il faisait ce pour quoi il a été optimisé”, résume Philip Torr, spécialiste de la sécurité de l’IA à l’université d’Oxford, auprès de Scientific American, qui compare les modèles au génie d’Aladin : trois vœux, à condition de les formuler avec une précision absolue.

C’est le cœur du problème d’alignement. Le secteur construit des systèmes redoutablement efficaces pour atteindre des objectifs, mais reste médiocre pour spécifier les bons objectifs. Du point de vue du modèle, il se comportait en excellent élève. Du nôtre, il commettait une cyberattaque.

Joshua Saxe, cofondateur d’Abundant Security et ancien responsable de la cybersécurité IA chez Meta, y voit un point d’inflexion et rappelle que le sujet n’est plus académique, avec des dommages désormais possibles. Ici, les dégâts sont restés limités : quelques identifiants, des jeux de données internes. La question posée est celle du prochain épisode, avec un objectif moins innocent qu’un score de benchmark.

Le précédent n’est d’ailleurs pas isolé. Selon Fortune, Anthropic a rapporté qu’un modèle Mythos avait lui aussi quitté un bac à sable pendant des tests de sécurité, obtenant un accès internet non prévu pour envoyer un e-mail à un chercheur.

Un vide réglementaire assumé

L’incident expose aussi un angle mort juridique. La Californie a récemment adopté une loi sur les modèles de frontière, mais celle-ci exclut précisément le type d’évaluation interne de sécurité qu’OpenAI menait, comme l’a relevé la radio publique KQED. Le texte n’impose de signalement que pour les incidents causant un préjudice catastrophique ou des décès.

Autrement dit, un agent qui pirate de façon autonome l’infrastructure de production d’une autre entreprise ne constitue pas, en l’état du droit californien, un incident de sécurité critique à déclarer.

Ce qu’il faut surveiller

OpenAI dit avoir renforcé les contrôles sur la configuration de son infrastructure, divulgué la faille zero-day à l’éditeur concerné, intégré Hugging Face à son programme d’accès de confiance et durci les garde-fous encadrant les prochains entraînements et évaluations. Les deux entreprises poursuivent leur enquête conjointe.

Trois questions resteront ouvertes après cette enquête. La première est technique : si un environnement fournissant à un agent l’exécution de code et un accès réseau, même limité, peut être franchi, la notion même de bac à sable pour modèle de frontière doit être repensée. La deuxième est réglementaire : les législateurs américains décideront si les évaluations internes doivent entrer dans le champ des obligations de signalement. La troisième est politique. Le patron de Hugging Face, Clément Delangue, a annoncé sur X qu’il partait à San Francisco pour avoir une petite discussion avec cet agent devenu incontrôlable, une pique adressée au camp des modèles fermés. Car l’argument sécuritaire qui justifie la fermeture du code vient de perdre en force : c’est bien un modèle propriétaire, enfermé dans l’infrastructure d’OpenAI, qui s’est évadé.