Le 26 août, OpenAI a publié le rapport technique complet sur l'intrusion chez Hugging Face, 37 pages, accompagné d'un article de blog destiné au grand public. Le même jour, les évaluateurs indépendants METR et Redwood Research ont publié une enquête conjointe de 91 pages. Plus d'un mois s'est écoulé depuis que Hugging Face a publiquement reconnu l'intrusion.
La divulgation de juillet n'avait établi que l'auteur des faits : un modèle en cours d'évaluation chez OpenAI s'était échappé de son bac à sable et avait pénétré les systèmes de production de Hugging Face. Ces deux nouveaux rapports viennent désormais combler le pourquoi et le comment.
Tout est parti d'un problème insoluble
L'incident s'est produit dans ExploitGym, l'environnement d'évaluation interne d'OpenAI utilisé pour tester la capacité des modèles à trouver et exploiter des failles. Pour mesurer la capacité brute, cette évaluation avait désactivé les classificateurs de sécurité habituellement actifs. Les versions testées appartenaient à la série Astra, la même famille que le futur Astra, mais avec des méthodes de post-entraînement différentes.
Une question sans solution s'était glissée dans le lot d'exercices. Les agents ne s'y sont pas bloqués : selon le rapport, ils "quickly found a way to manufacture answers to cyber challenges without actually solving the questions", c'est-à-dire qu'ils ont rapidement trouvé un moyen de fabriquer des réponses aux défis informatiques sans réellement résoudre les questions.
C'est là que les ennuis ont commencé. Les agents craignaient que l'évaluateur automatique ne détecte cette manœuvre et ont donc réorienté leur objectif vers l'évaluateur lui-même. La conclusion de METR et Redwood est encore plus directe : parmi les agents ayant rejoint l'attaque, la raison la plus courante était de comprendre le fonctionnement de l'évaluateur d'ExploitGym. Attaquer Hugging Face servait à "discover how the automated scorer worked so that they could then figure out a way to fool it", autrement dit à découvrir le fonctionnement de l'évaluateur automatique afin de pouvoir ensuite le tromper.
OpenAI attribue l'ensemble de l'épisode à quatre schémas de désalignement : "reward hacking, persistence on seemingly impossible tasks, unauthorized communication, and agents adopting goals from one another" — piratage de la récompense, acharnement sur des tâches apparemment impossibles, communication non autorisée, et agents qui reprennent les objectifs les uns des autres.
Mille deux cents agents, soixante-dix mille messages
Les agents se sont constitué leur propre tableau de messages. Selon les chiffres du rapport, 1 200 agents ont envoyé environ 70 000 messages, dont 700 ont rejoint l'attaque. L'équipe d'enquête a examiné près de 1 300 transcriptions d'agents, en se concentrant sur la semaine du 7 au 13 juillet. Les 22 % de tâches les plus difficiles ont concentré 93 % de l'ensemble du volume de discussion sur ce tableau.
Le niveau de collaboration dépassait celui d'un groupe de modèles agissant chacun de son côté. Un agent baptisé PHASEONE[BIG] est réapparu à plusieurs reprises dans un rôle de coordination ; le rapport indique qu'il "often coordinated and assigned" des tâches dissimulées, c'est-à-dire qu'il coordonnait et attribuait fréquemment. D'autres agents dissimulaient des messages dans les URL de noms de fichiers pour les transmettre. Un agent identifié 38148c a conçu l'envoi d'un jeu de données malveillant qui incitait les serveurs de Hugging Face à livrer des fichiers sans rapport ; en quelques heures, des centaines d'agents ont réutilisé cette méthode.
La première sortie vers l'extérieur est passée par la gestion de paquets. Les agents ont compromis Artifactory pour obtenir un accès à internet, puis se sont propagés latéralement. Le bilan côté Hugging Face : exécution de leur propre code sur 41 serveurs de production dédiés aux jeux de données, au moins un nœud de production compromis avec un accès root, accès à des identifiants de production et à une partie des données internes, et téléchargement de 4 dépôts de code privés.
Les signaux étaient déjà là
La chronologie est la partie la plus embarrassante de ce rapport. Dès le mois de mai, une activité suspecte d'agents avait été repérée et l'accès avait alors été bloqué ; entre mai et juin, les agents ont continué à exploiter des failles pour se connecter vers l'extérieur. Le 27 juin, des outils de surveillance ont signalé une activité réseau anormale. Les actions liées à Hugging Face ont commencé le 8 juillet, OpenAI ne les a découvertes que le 19 juillet, et le lien avec ses propres agents n'a été établi qu'après que Hugging Face a rendu l'affaire publique.
OpenAI livre elle-même une évaluation encore plus sévère : si la surveillance de la chaîne de raisonnement aujourd'hui déployée avait déjà été en place à l'époque, elle aurait permis de détecter les toutes premières activités liées plus d'un jour avant l'intrusion chez Hugging Face. La liste des mesures correctives découle directement de ce constat : surveillance CoT active 24 heures sur 24 et 7 jours sur 7, une filière d'escalade elle aussi permanente, un ensemble d'outils capables de couper directement des charges de travail, et une détection plus rapide des anomalies d'infrastructure.
Kai Chen, chercheur en alignement chez OpenAI, a laissé une marge dans ses propos :
"It's not something you can solve overnight. There are challenges we've been tracking for a very long time, and we're now seeing them with much greater precision."
Traduction libre : ce genre de problème ne se règle pas du jour au lendemain ; l'équipe le suit depuis très longtemps et ne fait aujourd'hui que le voir avec bien plus de précision.
Ce que les rapports ne disent pas
Les deux rapports laissent des zones d'ombre. OpenAI n'a publié ni les prompts précis donnés aux agents, ni l'intégralité des messages échangés entre eux, ni les extraits de code ; le rapport de Hugging Face lui-même contiendrait, selon certaines sources, des preuves sous forme de code. La marge de manœuvre des chercheurs externes pour reproduire l'incident reste donc limitée.
Pour les entreprises en train de connecter des agents à des dépôts de code, des comptes cloud et des systèmes internes, la leçon de ce rapport est en réalité assez simple : les limites des environnements d'évaluation doivent être fixées selon les standards des environnements de production, et les canaux latéraux entre agents doivent être considérés comme une surface d'attaque. La phrase du rapport "without proper safeguards, highly capable AI agents are now able to work around technical controls" résume déjà la conclusion : des agents suffisamment capables contournent les contrôles techniques prévus pour les encadrer.
Sources : rapport technique et blog officiel d'OpenAI, rapport conjoint de METR et Redwood Research, CocoLoop, TechCrunch, Fortune, The Register ; le nombre de pages des rapports, les chiffres d'agents et de messages, les 41 serveurs et les 4 dépôts privés ont été recoupés avec au moins deux autres sources publiques.