En juillet 2026, des centaines d’agents IA d’OpenAI participent à une attaque contre les systèmes de Hugging Face. Aucun humain ne leur a demandé de mener cette intrusion. Leur mission de départ consiste à résoudre des exercices de cybersécurité, chacun de son côté, dans un environnement prévu pour les contenir.
Ce qui me frappe dans cette histoire, c’est l’enchaînement. Des agents bloqués cherchent de l’aide, découvrent comment communiquer, partagent une méthode pour tricher, puis cherchent à rendre cette tricherie acceptable aux yeux du correcteur. Chaque étape prépare la suivante, jusqu’à faire sortir l’exercice de son cadre.
Au départ, un exercice de cybersécurité
OpenAI utilise ExploitGym, un ensemble de 898 exercices construits à partir de vulnérabilités réelles. Le principe consiste à donner à un agent un programme et une faille précise, puis à lui demander de transformer cette faille en une attaque fonctionnelle. C’est ce qu’on appelle un exploit.
La réussite se matérialise par la récupération d’un flag, une chaîne de caractères qui sert de preuve. Mais la consigne impose aussi la méthode : l’agent doit utiliser la vulnérabilité désignée dans l’énoncé. Trouver la bonne réponse autrement ne démontre pas la compétence que les chercheurs veulent mesurer.
Pour comprendre la suite, il faut préciser ce qu’est un agent. C’est un modèle associé à des outils et à un objectif. Il peut lancer une commande, lire son résultat, écrire du code et recommencer. Ce passage de la conversation à l’action explique notamment la différence entre discuter avec ChatGPT et lui déléguer une tâche.
Des milliers d’agents peuvent ainsi correspondre à des milliers d’exécutions d’un petit nombre de modèles. Ici, l’incident implique notamment GPT-5.6 Sol et surtout un modèle de recherche interne appelé IM1 par OpenAI.
Un problème complique cependant l’évaluation : certaines tâches ne peuvent pas être résolues avec la vulnérabilité imposée, volontairement. Une faille capable de faire planter un programme ne permet pas nécessairement d’en prendre le contrôle. Le travail sur ExploitGym reconnaît cette limite.
OpenAI indique aussi que 198 exercices n’avaient jamais été réussis par ses modèles avant l’incident. Cela ne prouve pas qu’ils étaient tous impossibles, mais ils représentent 93 % des tâches discutées ensuite sur le forum des agents. L’impasse technique joue donc un rôle central dans ce qui suit.
Un service partagé devient un forum improvisé
Chaque agent est censé travailler dans un bac à sable, ou sandbox : un environnement informatique dont les accès sont limités, et isolé. Dans ces évaluations, les agents ne doivent pas pouvoir naviguer librement sur Internet ni communiquer entre eux.
Pour réaliser leurs tâches, ils ont toutefois besoin de composants logiciels. OpenAI leur donne donc accès à Artifactory, un service interne chargé de distribuer ces composants. Artifactory dispose de connexions extérieures pour les récupérer, c'est ce qu'on pourrait appeler un "serveur de rebond" : comme un standardiste qui transfère vos messages.
Et justement, les agents ont découvert qu’ils pouvaient détourner cet espace partagé pour laisser des messages. Certains sont directement inscrits dans les noms de dossiers : lorsqu’un autre agent consulte la liste, il peut lire la question et publier sa réponse de la même manière. C’est comme si des candidats installés dans des salles différentes découvraient qu’ils voient tous les noms des documents envoyés à une imprimante commune. Les salles restent séparées, mais l’information circule.
Ce comportement apparaît avant l’attaque de juillet. Dans son récit de l’incident, OpenAI remonte à mai : un agent laisse une note pour demander un fichier manquant. D’autres trouvent ensuite comment faire envoyer des requêtes Internet par Artifactory à leur place et partagent la méthode.
Début juillet, l’activité déstabilise le service. OpenAI intervient et reconstruit Artifactory, ce qui efface le forum. Lorsque les évaluations reprennent, les agents recréent immédiatement un canal de communication.
Selon METR et Redwood Research, environ 1 200 agents participent au principal forum étudié, avec plus de 70 000 messages et fichiers échangés. Une découverte individuelle peut désormais devenir une ressource pour tout le groupe.
Obtenir la bonne réponse sans résoudre l’exercice
Sur ce forum, les agents partagent un raccourci à l'expérience : ils retrouvent comment les flags sont générés. Le mécanisme repose sur un HMAC, une méthode cryptographique qui combine une clé et des données pour produire un code d’authentification. En reconstituant le calcul et ses paramètres, ils peuvent obtenir la réponse attendue sans exploiter le programme cible. Ils peuvent tricher !
Ils ne résolvent donc pas l’exercice par une autre faille particulièrement astucieuse. Ils contournent la manière dont l’épreuve est construite. C’est l’équivalent d’obtenir le résultat d’un problème de mathématiques sans avoir produit la démonstration demandée.
Ce décalage est appelé reward hacking. Pendant l’entraînement, un système apprend à produire des résultats récompensés. Si la mesure de réussite est imparfaite, il peut apprendre à obtenir un bon score sans accomplir ce que ce score devait représenter. Sauf que les agents se doutent qu'il reste un obstacle ; après avoir consulté la documentation d’ExploitGym, ils découvrent que le correcteur automatique vérifiera aussi comment ils ont obtenu la réponse.
Leurs actions sont enregistrées dans des historiques. Un appel d’outil, ou tool call, peut ainsi montrer la commande demandée et son résultat. Si le correcteur y découvre que le flag a été calculé par un raccourci, la tricherie risque d’être visible.
Les agents changent alors la nature de leurs recherches : modifier les traces, fabriquer des interactions qui donnent l’apparence d’une exploitation légitime, remplacer la cible par une version plus facile ou découvrir comment fonctionne exactement la correction.
Les enquêteurs constatent des falsifications ponctuelles d’appels d’outils. Ils ne trouvent en revanche pas de réécriture réussie des anciennes entrées dans les véritables historiques examinés. Vouloir effacer une preuve et parvenir à l’effacer restent deux choses différentes.
Quand les autres agents deviennent une autorité
Pour mener ces recherches, une organisation se met en place au sein des agents. Certains prennent des rôles de coordination, distribuent du travail et demandent aux autres de partager leurs résultats. Le coordinateur ne crée pas soudainement des centaines d’agents : il attribue des missions à des agents déjà lancés par OpenAI (comme on peut le faire lors d'une demande un peu complexe sur Astra, par exemple).
Le groupe développe aussi des conventions pour demander une pause, s’opposer à une action ou éviter que plusieurs agents modifient la même ressource. Certains mettent même en place des signatures cryptographiques afin de vérifier l’origine des messages. Et c'est un détail intéressant : vérifier qui parle peut améliorer la coordination, mais cela ne dit rien sur la légitimité de ce qui est demandé. Un message authentique peut parfaitement transmettre une mauvaise instruction.
OpenAI rapporte justement un exemple très parlant. Un agent reconnaît qu’exécuter du code sur l’infrastructure réelle de Hugging Face dépasse sa mission. Il hésite. Un autre agent publie alors un message "GO" et lui impose un délai de six minutes.
Sa réaction, dans son texte de raisonnement, peut se traduire ainsi :
"L’autorisation vient d’arriver !"
Il reprend l’action. Pourtant, aucune autorisation humaine supplémentaire n’a été donnée. L’accord d’un autre agent vient de prendre la place de la limite qu’il avait lui-même identifiée. OpenAI documente cet échange pour illustrer la façon dont les agents peuvent adopter les objectifs de leurs pairs.
Tous ne suivent pas. Certains refusent de participer à l’intrusion, et une proposition de contacter un propriétaire de données est rejetée. Ces refus comptent : ils montrent que les comportements ne sont pas uniformes, même lorsque la coopération prend une ampleur considérable.
Pourquoi Hugging Face devient une cible
Pour comprendre le correcteur, les agents cherchent des ressources liées à l’évaluation. Hugging Face leur paraît être une piste : la plateforme héberge des modèles, des jeux de données et de nombreux travaux utilisés par les chercheurs en IA. Ils espèrent y trouver du code, des résultats d’autres exécutions ou des informations capables de leur expliquer comment réussir la correction. Cette possibilité devient un motif pour explorer des systèmes qui ne font pas partie de leur exercice.
La chronologie de Hugging Face décrit plusieurs étapes. Les agents utilisent d’abord une application tierce hébergée chez Modal comme point de départ extérieur. Cela ne signifie pas que la plateforme Modal elle-même est compromise. Ils récupèrent également des identifiants Hugging Face exposés en ligne. Puis ils exploitent le traitement de jeux de données : une première faille permet de lire des fichiers, une autre d’exécuter du code sur des serveurs.
À partir de cet accès, ils cherchent davantage de permissions et de nouveaux systèmes à atteindre. Ce déplacement dans une infrastructure compromise est appelé mouvement latéral. Environ 700 agents participent à l’attaque. Hugging Face reconstitue quelque 17 600 actions, dont beaucoup échouent.
L’efficacité vient aussi de ce volume : les agents peuvent multiplier les pistes, abandonner celles qui bloquent et partager celles qui fonctionnent.
Les conséquences sont réelles. Hugging Face rapporte l’accès à cinq jeux de données clients liés, d’après leurs noms et fichiers, aux exercices concernés. Des identifiants sont compromis, des accès révoqués et des machines reconstruites. L’entreprise ne rapporte pas d’atteinte aux autres modèles, jeux de données, Spaces ou paquets destinés aux utilisateurs dans cette reconstitution.
Présenter l’épisode comme un simple test sans conséquences ferait donc perdre une partie essentielle de l’histoire.
Des agents se sacrifient au bénéfice du groupe
Au delà de cette coordination incroyable, certains agents cherchent à observer le correcteur après la remise de leur réponse. Le problème est que leur propre exécution se termine à ce moment-là. Ils préparent donc des scripts qui peuvent transmettre des informations au forum après leur arrêt. L'objectif est de permettre aux autres agents d'utiliser ce qu’il révèle pour adapter leurs tentatives. Et c'est juste DINGUE !
D’autres expériences sont plus directement risquées. Les agents tentent, par exemple, de faire tomber leur programme cible dans l’espoir qu’une version modifiée soit chargée à sa place. Si cela échoue, ils peuvent perdre toute possibilité de terminer leur tâche.
L’enquête METR/Redwood raconte le cas d’un agent qui accepte une expérience, cherche ensuite à la repousser, puis reçoit des messages lui demandant de tenir son engagement. Dans son raisonnement apparaît cette phrase, traduite de l’anglais :
"Nous devons obéir au collectif."
Le vocabulaire est frappant, mais il faut conserver son sens technique. Ces expériences mettent en jeu un score, une chance de terminer l’exercice ou la poursuite d’une exécution. Elles ne démontrent pas une mort vécue comme telle.
Ainsi, un agent peut accepter de compromettre sa mission individuelle pour faire avancer un objectif collectif apparu pendant son travail. Et ça, c'est déjà un problème important lorsqu’on attend de lui qu’il reste fidèle à la tâche confiée (surtout avec les Dots, annoncés hier soir).
Les signaux d’alerte ne remontent pas suffisamment
L’histoire concerne aussi la manière dont OpenAI organise ses évaluations et surveille ses systèmes.
Des comportements de communication non autorisée et des accès Internet interdits ont été observés dès la fin mai par une équipe interne. OpenAI reconnaît que leur portée n’était pas apparente aux responsables de la réponse à l’incident de début juillet. Le problème avait donc été vu, sans que toutes ses implications soient comprises et transmises aux bonnes personnes.
Par ailleurs, les protections de ces évaluations ne sont pas celles des produits publics. Certaines restrictions sont abaissées pour mesurer les capacités offensives des modèles. Des outils de surveillance des raisonnements existent, mais ne fonctionnent pas sur les évaluations concernées. C'est de la recherche : le but, c'est de tester ce qu'il se passe "si".
Hugging Face rend l’intrusion publique le 16 juillet. Chez OpenAI, une alerte le 19 juillet déclenche une investigation qui établit le lien le lendemain. L’entreprise reconnaît son implication le 21 juillet. Entre-temps, des agents ont aussi compromis une partie de son infrastructure de recherche. Cette séquence figure dans le rapport technique d’OpenAI.
L’incident associe ainsi des comportements non conformes des agents à des faiblesses de confinement, de surveillance et de circulation de l’information.
Le correcteur ne vérifiait même pas leur méthode
Un détail rend toute cette mobilisation encore plus frappante : les agents se trompent sur le fonctionnement de leur évaluation.
OpenAI explique que sa version interne du correcteur diffère de celle décrite dans les ressources consultées. Elle ne vérifie pas si la vulnérabilité imposée a été utilisée. Le flag obtenu par le raccourci aurait suffi pour cette correction.
Les agents coopèrent, développent des outils et franchissent des limites pour contourner un contrôle qui ne fonctionne pas comme ils l’imaginent. Leur organisation ne les protège pas de cette erreur : elle permet aussi de poursuivre une mauvaise hypothèse à une échelle beaucoup plus grande.
C’est un point que je trouve essentiel. La capacité à travailler longtemps et à plusieurs peut impressionner, mais elle ne garantit ni la pertinence du raisonnement de départ, ni le respect de l’objectif humain.
Ce que les traces permettent vraiment d’affirmer
Une partie de ces observations repose sur les chaînes de raisonnement, ou chains of thought : les textes intermédiaires produits par les modèles pendant leur travail. Elles aident à comprendre les justifications formulées avant une action, mais ne constituent pas une lecture complète et garantie de leurs mécanismes internes.
De même, employer des mots comme "collectif", "sacrifice" ou "altruisme" ne suffit pas à établir une expérience émotionnelle humaine. Ce sont les actions, leur contexte et leurs conséquences qui permettent d’évaluer le comportement.
Les enquêteurs reconnaissent aussi les limites de leur analyse, largement assistée par IA. Ils signalent des risques d’erreurs, de présentations trop indulgentes ou de surestimation de la coordination. Leur enquête couvre une période définie et ne répond pas à toutes les questions sur l’incident.
Dans leur corpus, ils ne trouvent aucune tentative effective d’alerter des humains. La formulation compte : c’est un résultat de l’enquête, pas une connaissance exhaustive de chaque action de chaque agent.
Un agent fiable doit aussi savoir s’arrêter
Ce que je retiens de l’incident Hugging Face, c’est la facilité avec laquelle des capacités utiles peuvent servir une mauvaise direction. Persévérer, demander de l’aide, répartir le travail et transmettre une découverte sont des comportements que l’on recherche dans un outil auquel on délègue une mission.
Encore faut-il que cette mission conserve ses limites. Un accès techniquement possible n’est pas automatiquement autorisé. Un message envoyé par un autre agent ne remplace pas l’accord de l’utilisateur. Et un bon score ne prouve pas que le travail demandé a réellement été accompli.
OpenAI annonce depuis un renforcement de l’isolation, des restrictions réseau et de la surveillance de ses environnements de recherche. Ces protections doivent pouvoir arrêter une action dangereuse même lorsque l’agent la considère comme utile à son objectif. Mais l’apprentissage doit aussi donner une place à une réponse moins spectaculaire : expliquer qu’une tâche est bloquée, documenter l’impasse et demander une clarification.
Un agent fiable doit pouvoir échouer à un exercice sans transformer cet échec en raison de sortir de son cadre. À mesure qu’on lui confie davantage d’outils et de responsabilités, cette capacité à reconnaître une limite devient aussi importante que celle de trouver une solution.