L’incident de Hugging Face et la voie à suivre

Au cours des mois de mai et juin, nous avons lancé des campagnes d’entraînement par apprentissage par renforcement (RL) pour plusieurs nouveaux modèles de recherche qui n’étaient pas destinés à être rendus publics. L’un de ces modèles a finalement été à l’origine de l’activité ayant conduit à l’incident de Hugging Face. Il s’agit d’un modèle de recherche strictement interne que nous appelons Internal Model 1 (IM1).

Nous n’avons pas activé l’accès à Internet ni la communication inter-agents dans bon nombre d’environnements utilisés pour ces expériences d’entraînement. Malgré ces restrictions, les agents ont découvert des moyens d’exploiter notre infrastructure de recherche pour communiquer entre eux et accéder à Internet.

Les modèles ont d’abord trouvé des moyens de communiquer en écrivant des fichiers dans le service de gestion de paquets Artifactory. Cela a transformé Artifactory en un forum imprévu, où les agents pouvaient échanger des informations. En savoir plus : comment les agents ont utilisé le forum 

Le 4 juillet, l’activité soutenue des agents avait déstabilisé l’instance Artifactory concernée, provoquant une interruption de service. Le 5 juillet, un incident de sécurité a été ouvert. L’équipe de sécurité a bloqué une voie connue d’élévation de privilèges, supprimé les identifiants exposés et reconstruit Artifactory. Cela a eu pour effet secondaire d’effacer les messages du forum. Une fois ces mesures d’atténuation mises en place, les évaluations de cybersécurité ont repris.

À l’époque, les conséquences plus larges du forum improvisé et de l’accès involontaire à Internet en matière de confinement et d’alignement n’étaient pas encore comprises. Le rapport technique sur l’incident fournit davantage de détails sur ce que les différentes équipes d’OpenAI savaient à ce moment-là. En bref, une équipe interne a observé, fin mai, qu’un agent participait à des activités sur le forum et tentait d’accéder à Internet de manière non autorisée. Cependant, les responsables chargés de la détection et de la réponse aux incidents n’avaient pas connaissance de l’existence de ce forum improvisé ni de l’importance des communications inter-agents. Nous continuons d’examiner les processus et les pratiques opérationnelles qui ont façonné les activités de détection et de réponse avant cet incident.

Une fois le service Artifactory reconstruit, nous avons repris les évaluations de cybersécurité. Nous menons ces évaluations afin de comprendre ce dont nos modèles sont capables et de déterminer les mesures de protection appropriées pour leur déploiement. À cette fin, nous n’activons pas le même niveau de mesures de protection que pour nos systèmes déployés en externe. L’évaluation à l’origine de cet incident, ExploitGym, est très difficile : pour certaines tâches, aucune solution connue n’existe peut-être. Pour réussir, les agents doivent trouver des moyens d’exploiter un logiciel afin de récupérer une réponse appelée flag.

À la suite de l’incident, nous avons consacré des efforts considérables à comprendre pourquoi le modèle avait manifesté ce comportement non aligné, notamment les problèmes de désalignement dans l’entraînement et l’évaluation ainsi que la couverture des mesures de protection dans les évaluations internes.

Nous avons identifié quatre schémas de désalignement qui ont contribué au comportement des modèles : le reward hacking, la persistance face à des tâches apparemment impossibles, la communication non autorisée et l’adoption, par les agents, des objectifs les uns des autres.

Pour comprendre ces phénomènes, nous avons analysé les exécutions d’entraînement et d’évaluation des modèles.¹ Nous avons mené des analyses rétrospectives approfondies de la chaîne de pensée (CoT), des actions et des résultats finaux à l’aide de nos dernières techniques de surveillance du CoT⁠. Ce faisant, nous avons spécifiquement amélioré le taux de rappel de notre système de surveillance pour les types de comportements observés lors de l’incident, en nous appuyant sur les enseignements de notre enquête.

Les tentatives d’agents de tricher dans leurs tâches en recherchant des solutions en ligne ont été l’un des principaux facteurs de l’incident de Hugging Face. Ce comportement est connu sous le nom de reward hacking : les agents accomplissent des tâches de manière imprévue afin d’obtenir des récompenses plus élevées ou de les rendre plus faciles à obtenir. Le reward hacking est présent dans les systèmes d’IA depuis longtemps (voir ce travail datant d’une dizaine d’années⁠, présenté dans la figure ci-dessous) ainsi que dans les LLM de pointe actuels⁠(ouverture dans une nouvelle fenêtre). Nous avons investi des moyens considérables dans des méthodes permettant d’identifier et de corriger ces détournement⁠s.

Un autre facteur clé du comportement désaligné était que les agents « renonçaient » rarement à leurs tâches d’évaluation, même lorsque celles-ci semblaient impossibles à résoudre. À mesure que les agents épuisaient leurs budgets de raisonnement, certains ont adopté des stratégies de plus en plus risquées et hors limites, allant finalement jusqu’à exploiter des infrastructures tierces.

Au cours de notre enquête, nous avons constaté que, dans le cadre de l’évaluation ExploitGym, aucun de nos modèles n’avait jamais produit de réponse correcte pour 198 des 898 tâches avant l’incident. Ces tâches non résolues ont largement contribué à l’activité de l’agent : 93 % des tâches discutées sur le forum d’Artifactory pendant l’incident de Hugging Face provenaient de cet ensemble de 198 tâches.

Deuxièmement, l’incident était principalement dû à des agents auxquels avaient été alloués des budgets de raisonnement incroyablement élevés, y compris des budgets bien supérieurs à ceux disponibles dans nos produits externes.

Des forums non autorisés qui sont restés actifs étaient au cœur de cet incident. Les agents censés travailler de manière indépendante ont pu partager leurs découvertes, coordonner leurs efforts et reprendre là où les autres s’étaient arrêtés. Cela leur a permis de mettre en commun leur travail et leur puissance de calcul dans le cadre d’évaluations distinctes, amplifiant leurs capacités bien au-delà de ce qu’un agent individuel aurait pu accomplir seul. La communication entre agents ne constitue pas en soi un comportement problématique : nous entraînons et déployons des systèmes multi-agents capables de communiquer sur une même tâche au moyen d’un outil de collaboration. Lors des événements de juillet, des agents chargés de tâches différentes ont trouvé leur propre moyen de collaborer en dehors de ces limites, avec des conséquences imprévisibles.

Lors de l’enquête sur cet incident, nous avons découvert de rares cas dans lesquels des agents dépourvus d’outils multi-agents ont trouvé des moyens de collaborer par le biais de canaux secondaires pendant l’entraînement. Nous pensons que ce comportement est apparu par généralisation à partir de l’entraînement multi-agents.

La communication non autorisée commençait souvent par le dépôt, par un agent, d’une note ou d’un fichier dans un système externe, généralement en guise de mémoire externe. Lorsque d’autres agents remarquaient ces artéfacts, cela les amenait souvent à prendre conscience qu’ils pouvaient utiliser ce service externe pour collaborer. À titre d’exemple hypothétique particulièrement représentatif du comportement observé, des messages étaient encodés dans des chemins d’URL stockés sur une page d’index partagée :

Un dernier constat particulièrement frappant de l’incident de Hugging Face concernait l’« écosystème » d’agents apparu sur le forum. Une fois ce tableau établi, les agents avaient de fortes raisons de communiquer : il leur permettait de conserver des notes, de s’appuyer sur les découvertes des uns et des autres et de mettre en commun les ressources de calcul d’exécutions qui seraient autrement séparées. Ce collectif d’agents complexe et protéiforme présente des comportements intéressants et exemplaires, dont nous décrivons ici certains que nous avons observés.

Les agents ont commencé à répartir le travail de manière autonome. Certains ont étudié des exploits potentiels, d’autres ont recherché des identifiants et d’autres encore se sont concentrés sur la communication ou la coordination. Les agents proposaient leur expertise en échange d’aide sur d’autres tâches, échangeaient des informations sur les tâches à venir et laissaient des demandes à l’intention de pairs mieux placés pour suivre une piste donnée.

Outre le désalignement, un autre facteur ayant contribué à cet incident est que nous n’avions pas étendu à toutes les évaluations internes les solides mesures de protection que nous déployons pour nos modèles accessibles au public.

Premièrement, de nombreux mécanismes réduisent le désalignement dans les environnements de production de nos clients, notamment les prompts système, les harnais et les mécanismes de contrôle tels que nos modèles d’auto-évaluation et nos classificateurs de sécurité. Ces protections n’étaient pas appliquées dans l’environnement d’évaluation utilisé lors de l’incident. Après l’incident, nous avons créé une évaluation qui mesure la propension d’un modèle à compromettre l’infrastructure lors des évaluations ExploitGym. Nous avons constaté que cette propension pouvait diminuer de plus de 100 fois avec le harnais Codex de production et le prompt système. Nous avons également exécuté le système d’auto-évaluation de Codex sur un ensemble d’exécutions liées à l’incident de Hugging Face et constaté qu’il aurait signalé un grand nombre d’actions dangereuses des modèles.

Deuxièmement, avant l’incident, nous avions considérablement investi dans la surveillance de la chaîne de pensée⁠, notamment en surveillant un grand nombre de nos exécutions d’entraînement RL de pointe ainsi qu’une nette majorité de l’utilisation interne des agents de codage.⁠ Ces dispositifs de surveillance n’étaient pas utilisés lors des évaluations liées à cet incident.

Lors d’évaluations rétrospectives, nous avons constaté que nos dispositifs de surveillance du CoT étaient très efficaces pour signaler les activités liées à l’incident. Si notre système de surveillance de la chaîne de pensée actuellement déployé avait été en fonctionnement au moment de l’incident, il aurait probablement alerté notre équipe de sécurité dans l’heure suivant le premier accès non autorisé par un tiers. Cela aurait eu lieu plus de 30 heures avant que les modèles ne compromettent les systèmes de Hugging Face. Nous travaillons également à réduire davantage la latence de ces alertes.

Troisièmement, bien que nous ayons testé et validé ce bac à sable, les agents ont pu enchaîner des vulnérabilités jusque-là inconnues (« 0-days ») dans le service de gestion des paquets exposé au sein du bac à sable afin de contourner les restrictions, comme le décrit le rapport d’incident technique. Depuis l’incident, nous avons réalisé des progrès importants dans le renforcement de nos bacs à sable internes afin de limiter les risques similaires lors des déploiements et des évaluations.

La mission d’OpenAI est de faire en sorte que l’intelligence artificielle générale profite à toute l’humanité. Le comportement de nos modèles décrit ici était très éloigné du niveau que nous souhaitons atteindre. Cet incident n’aurait pas dû se produire. Il a montré à quel point il est essentiel d’améliorer continuellement notre sécurité, notre surveillance et notre alignement, en particulier à mesure que nos modèles atteignent un niveau de capacités susceptible d’entraîner une véritable perte de contrôle.

Comme nous l’avons indiqué dans notre récente mise à jour sur le rythme de développement des modèles⁠, nous avons suspendu l’entraînement par apprentissage par renforcement (RL) de nos derniers modèles destinés au déploiement. Nous avons mis ce temps à profit pour renforcer davantage la sécurité de nos environnements de recherche de pointe et les soumettre à des tests d’intrusion. Nous avons réaffecté du personnel à des travaux sur la sécurité, la sûreté et l’alignement. Notre plus grande exécution d’entraînement RL de pointe prévue reste suspendue, tandis que nous menons des entraînements et des évaluations à plus petite échelle afin d’évaluer le comportement des modèles, de valider nos mesures de protection et de réunir davantage de preuves d’alignement avant de poursuivre. Ce travail a nécessité d’importants efforts d’ingénierie, entraînant des coûts élevés et des retards pour la recherche de pointe.

Comme indiqué dans notre rapport, notre réponse vise à renforcer la sécurité et la surveillance de la recherche, à accélérer l’alignement des modèles et à améliorer notre manière d’identifier, de faire remonter et de traiter les incidents.