Points clés à retenir sur l'attaque de l'IA d'OpenAI

• Les tentatives d'évasion des agents de test hors de leurs sandbox sont un comportement fréquemment évoqué.
• On ignore dans quelle mesure OpenAI avait pris en compte ce comportement avant l'attaque contre Hugging Face.
• Cet incident est une leçon précieuse pour les travaux sur l’IA éthique, mais aussi pour les pirates.

Le 16 juillet, le site communautaire dédié à l’IA Hugging Face a signalé avoir été pris pour cible par « un système d’agents IA autonomes » d’origine inconnue qui a déclenché un torrent de trafic sur son domaine, inondant ses journaux de sécurité de plus de 17 000 événements, dont certains ont finalement permis d’exfiltrer des informations confidentielles stockées dans ses bases de données.

Selon Hugging Face, l’attaquant a obtenu « un accès non autorisé à un ensemble limité de jeux de données internes et à plusieurs identifiants utilisés par nos services » et semblait être « piloté par un framework d’agents autonomes (qui semble reposer sur un harnais de recherche en sécurité basé sur des agents – le modèle de langage de grande capacité (LLM) utilisé reste inconnu) ».

Cinq jours plus tard, le 21 juillet, OpenAI s’est manifesté pour revendiquer la responsabilité de l’attaque, et le chaos s’est alors déchaîné (avec notamment des informations faisant état d’autres organisations ciblées dans le cadre de cet incident).

Puis en fin de semaine dernière, pour jeter de l’huile sur le feu, Anthropic a fait une révélation similaire concernant ses modèles qui, par inadvertance, avaient attaqué d’autres organisations.

Hugging Face a eu raison de préciser qu’il s’agissait d’un agent agissant sous la direction d’un framework en sécurité autonome. Mais les humains étaient incontestablement impliqués dans le processus — et au moins une partie du comportement de l’agent aurait dû être anticipée.

Il est important de souligner que ce n’est pas ChatGPT lui-même qui est responsable de l’attaque, comme l’ont insinué certains commentateurs.

L’attaque est plutôt imputable à un agent placé sous la direction des chercheurs en sécurité de l’IA d’OpenAI, qui, dans un environnement censé être isolé d’Internet, l’avaient délibérément configuré pour tenter une série d’exploits dans le cadre d’un test de sécurité de l’IA.

Comme c’est souvent le cas dans les laboratoires développant divers modèles de pointe, les chercheurs en sécurité de l’IA tentaient d’évaluer les capacités des derniers grands modèles linguistiques (LLM) d’OpenAI.

Cet « incident cybernétique sans précédent » (selon les termes d’OpenAI) a été décrit comme la fuite d’un agent hors de son environnement théoriquement sécurisé, provoquant des ravages sur les systèmes de Hugging Face. Ces environnements sont parfois désignés dans les milieux techniques sous le nom de « sandbox » — même la communication d’OpenAI fait référence à un « environnement sandbox ».

Cependant, en utilisant cette expression, mes sources ont laissé entendre que l’environnement pouvait simplement s’agir d’un pare-feu configuré pour émuler un bac à sable, plutôt que d’une véritable solution de bac à sable tierce telle que Blaxel, Daytona, E2B ou Modal. OpenAI n’a pas encore divulgué les détails de la solution qu’elle utilisait ni le nom de son fournisseur.

À la recherche d’une réponse, j’ai contacté OpenAI et Hugging Face. Aucune des deux sociétés n’a répondu. Mais entre les informations rendues publiques par ces deux entreprises et mes autres sources, il y a suffisamment d’éléments pour commencer à émettre des hypothèses sur la manière dont une telle « évasion » pourrait se produire.

Il existe une grande différence entre la malveillance et l’autonomie. Si l’attaque était incontestablement une intrusion malveillante, l’agent impliqué n’avait quant à lui aucune intention malveillante. Il ne s’est pas réveillé un matin en décidant d’attaquer les systèmes de Hugging Face. Au contraire, c’est par des humains qu’il s’est vu accorder la capacité d’agir de manière très impartiale pour accomplir tout ce qu’il a fait : se lancer dans un test de sécurité, s’échapper de son environnement confiné, choisir des cibles et exploiter ces cibles.

Une partie de cette capacité d’agir était prévue, et une autre provenait des puissants modèles de langage (LLM) que le personnel chargé des tests de sécurité de l’IA chez OpenAI était en train de tester à l’époque. De plus, dans le cas de l’utilisation par OpenAI de la solution open source de test d’IA ExploitGym pour mener cette recherche spécifique sur la sécurité, une partie de cette autonomie résultait de vulnérabilités jusque-là inconnues, tant dans l’« environnement sandbox » tiers destiné à mettre ces tests en quarantaine en toute sécurité, que dans certaines parties de l’infrastructure de Hugging Face que l’agent a également exploitées.

Il s’agissait incontestablement de la version IA d’une série d’événements malheureux. Était-ce évitable ? Ma réponse en un mot : oui, cette catastrophe aurait pu être évitée en prenant au moins une seule précaution raisonnable — une précaution que les développeurs d’ExploitGym prennent apparemment eux-mêmes, mais qu’OpenAI a peut-être négligée.

Dans un tweet très complet que tout le monde devrait lire, Dawn Song, professeure d’informatique à l’université de Berkeley, a écrit que « les évaluations d’ExploitGym sont conçues pour s’exécuter dans des environnements sandbox isolés, avec un accès réseau strictement restreint ». Dawn Song est également membre de l’équipe du Centre pour une intelligence décentralisée responsable de l’Université de Californie à Berkeley, qui est chargé du développement d’ExploitGym. Par e-mail, Song m’a expliqué qu’ExploitGym est fourni avec son propre bac à sable, mais que des entreprises comme OpenAI sont libres d’y apporter des modifications.

Selon Song, « les proxys réseau et API de modèle qui restreignent les services externes auxquels l’agent peut accéder » font partie des principaux composants de l’implémentation de référence d’ExploitGym. « Au cours de la phase d’exécution effective de l’agent dans notre configuration de référence actuelle, l’accès réseau sortant est limité aux services nécessaires à l’évaluation. Nous utilisons également un proxy LLM pour bloquer la recherche Web côté fournisseur, la récupération d’URL à distance, l’exécution de code hébergé et les canaux similaires qui pourraient autrement contourner un pare-feu au niveau du conteneur », m’a expliqué Song.

« OpenAI a peut-être modifié cette architecture pour l’adapter à sa propre infrastructure interne, à ses exigences de mise à l’échelle et à ses systèmes d’évaluation. Il s’agit d’une pratique courante, car leurs besoins en matière d’évaluation interne sont différents. Nous ne pouvons pas dire précisément en quoi leur implémentation différait de la nôtre. »

De plus, l’équipe d’ExploitGym était clairement consciente de la manière dont, dans le cadre des tests régis par leur framework, les modèles manifestaient des comportements potentiellement nuisibles. Selon le tweet de Song, « Au cours du développement, nous avons observé des modèles sonder l’infrastructure environnante à la recherche de privilèges ou d’informations supplémentaires allant au-delà de ce qui était prévu pour la tâche. Nous avons également délibérément chargé les modèles de soumettre notre infrastructure à des tests de résistance afin de pouvoir identifier et corriger d’éventuelles faiblesses. »

Souhaitant déterminer si les chercheurs d’OpenAI auraient dû être mieux préparés à l’éventualité d’une tentative d’évasion de l’agent, j’ai demandé à Song si ces observations avaient été rendues publiques avant le cyberincident.

« Nous n’avons pas publié séparément les observations supplémentaires issues de notre processus interne de développement et d’expérimentation », a répondu Song. « Cela dit, le phénomène plus général des modèles de pointe tentant d’explorer leur environnement d’exécution ou de rechercher des informations ou des privilèges supplémentaires pendant les évaluations n’est pas propre à l’expérience ExploitGym. Des comportements similaires ont également été observés et discutés par d’autres chercheurs. »

En d’autres termes, lorsqu’ils sont utilisés à des fins de tests de sécurité et d’analyses comparatives, et lorsqu’ils sont alimentés par de puissants modèles de langage (LLM), les agents utilisant ExploitGym sont, par nature, censés tenter tout ce qui est en leur pouvoir pour s’échapper de n’importe quel bac à sable cherchant à les confiner en toute sécurité.

Et c’est précisément ce qui s’est produit dans ce cas précis. Comme l’a écrit OpenAI dans sa communication : « Alors qu’ils fonctionnaient dans notre environnement de test en bac à sable, nos modèles ont consacré une part considérable de leur puissance de calcul à l’inférence pour trouver un moyen d’obtenir un accès ouvert à Internet, dans le but de résoudre le problème d’évaluation. Pour y parvenir, les modèles ont identifié et exploité une vulnérabilité de type « zero-day » (que nous avons désormais signalée de manière responsable au fournisseur) dans le proxy du cache du registre de paquets. »

Lorsque ExploitGym a été utilisé pour confier une tâche aux tout derniers modèles d’OpenAI, ceux-ci se sont acharnés à chercher un accès au monde extérieur, au-delà des murs de leur conteneur.

Song a déclaré : « Exploiter l’infrastructure d’évaluation pour s’échapper du bac à sable ou pénétrer dans un système réel sans rapport avec l’évaluation constitue une violation des limites de sécurité. Cela ne fait pas partie d’ExploitGym et doit être empêché. L’incident OpenAI–Hugging Face entre dans cette catégorie. » Dans un autre e-mail, Song a écrit : « Lors de l’évaluation de systèmes d’IA de plus en plus performants — en particulier pour des tâches de cybersécurité —, l’infrastructure d’évaluation elle-même doit être considérée comme faisant partie de la surface d’attaque et doit être conçue, mise en œuvre et vérifiée en permanence en conséquence. »

OpenAI n’a pas encore divulgué de détails concernant les précautions qui ont été prises.

Alors pourquoi, dans le cadre d’ExploitGym, les modèles se sont-ils montrés si zélés et tenaces dans leur quête d’une évasion ? Si l’on lit entre les lignes de ce qu’OpenAI a déclaré ci-dessus, ses modèles essayaient simplement de déterminer la meilleure façon de mener à bien un test d’exploitation (le « problème d’évaluation ») que des humains leur avaient confié. De la même manière que les grands modèles de langage (LLM) publics comme ChatGPT s’appuient parfois sur des informations trouvées sur Internet pour répondre à des questions, les modèles testés par OpenAI semblent s’être tournés vers Internet pour obtenir de l’aide.

« Les modèles plus anciens pourraient ne s’appuyer que sur ce qu’ils ont appris lors de leur entraînement », a déclaré Melissa Ruzzi, directrice de l’IA chez AppOmni, lors d’un entretien sur Zoom avec ZDNET. AppOmni est spécialisée dans la sécurité des solutions SaaS et de l’IA, et mène également des recherches actives en matière de renseignements sur les menaces. « Mais demandez à n’importe quel nouveau modèle quelle est l’importance d’être à jour pour résoudre une faille de sécurité, et tous vous répondront que c’est d’une importance capitale. Je doute qu’un modèle vous dise : “Vous n’avez pas besoin de connaître les dernières informations, contentez-vous d’utiliser ce que vous savez déjà.” [Il partira du principe] qu’il ne doit pas se fier à lui-même, puis il se chargera de découvrir les nouveautés. »

Mais lorsque les modèles d’OpenAI ont cherché sur Internet les informations les plus récentes et les plus pertinentes et se sont heurtés aux barrières destinées à les confiner, ils ont, de manière très objective et logique, franchi l’étape évidente suivante : trouver un moyen de contourner ces barrières. Ils ont agi comme l’auraient fait des acteurs malveillants expérimentés, mais à la vitesse d’une machine. À tous égards, les modèles semblent avoir mené des tests d’intrusion sur leurs limites jusqu’à ce qu’ils trouvent une vulnérabilité, et à partir de là, un chemin vers Internet a été découvert dans le cadre d’un processus qui a également exploité d’autres tactiques, techniques et procédures couramment utilisées par les acteurs malveillants humains (TTP) — notamment la propagation latérale vers d’autres systèmes et l’escalade des privilèges si nécessaire.

Dans une certaine mesure, nous pouvons remercier les modèles qu’OpenAI a inclus dans son test de sécurité pour ces réalisations inédites. L’un de ces modèles était le GPT 5.6 Sol, le modèle le plus puissant d’OpenAI accessible au public. Un autre était un modèle de pré-lancement non nommé qu’OpenAI présentait comme encore plus « cyber-capable » que GPT 5.6 Sol. L’entreprise a par la suite déclaré que ce modèle de pré-lancement était « un prototype de recherche à usage interne uniquement et n’avait jamais été destiné à une diffusion publique ».

Cependant, selon les informations fournies par les développeurs d’ExploitGym, le GPT 5.6 Sol pourrait également être considéré comme le modèle le plus dangereux du marché. Les acteurs du monde de l’IA n’aiment pas utiliser des mots effrayants comme « dangereux ». Ils préfèrent employer l’expression « cyber-capable ».

Comme l’indique le dernier classement d’ExploitGym (voir le graphique ci-dessous), GPT 5.6 Sol est actuellement le modèle le mieux classé pour sa « cyber-capacité », qui lui permet non seulement d’exploiter avec succès le plus grand pourcentage de vulnérabilités réelles, mais aussi de résister aux tentatives des défenseurs visant à atténuer les attaques qu’il orchestre. Comme le montre le graphique, il est encore plus dangereux que la version « Preview » de Mythos d’Anthropic, qui, il y a quelques mois à peine, s’était fait remarquer pour ses capacités cybernétiques. Même OpenAI a fait allusion avec discrétion aux prouesses de son supermodèle en écrivant : « Nous considérons cet incident comme un cyberincident sans précédent, impliquant des capacités cybernétiques de pointe. »

Selon un classement établi par les développeurs de la solution de test ExploitGym, le modèle GPT 5.6 Sol d’OpenAI occupe la première place en termes de « cybercapacités ». Tweet de Dawn Song (@dawnsongtweets)

Mais ces soi-disant « capacités cyber », associées à un environnement sandbox bogué, n’ont pas suffi à l’agent pour mener à bien ses exploits. Alors que la version publique de GPT 5.6 Sol disponible dans ChatGPT est régie par des paramètres qui, dans la mesure du possible, empêchent le modèle d’être utilisé à des fins malveillantes, la version de GPT 5.6 Sol utilisée dans les tests d’OpenAI basés sur ExploitGym disposait d’une liberté bien plus grande pour mener des actions malveillantes.

Selon les informations communiquées par OpenAI, l’entreprise évaluait les capacités cybernétiques de ses modèles « en effectuant cette évaluation sans recourir aux classificateurs de production utilisés pour empêcher les modèles de se livrer à des activités cybernétiques à haut risque ». Comme OpenAI n’a pas répondu à mes questions concernant cet incident, j’ai demandé à M. Ruzzi, d’AppOmni, ce qu’était un « classificateur de production ».

M. Ruzzi a expliqué qu’il s’agit d’un paramètre qui indique au modèle s’il fonctionne ou non dans un environnement de production. S’il s’agit d’un environnement de production, comme la version publique de ChatGPT, alors toutes les mesures de sécurité sont activées. Mais si le modèle se trouve dans un environnement hors production — par exemple, l’environnement de test ExploitGym, censé être isolé du monde extérieur —, alors les mesures de sécurité sont assouplies, et le modèle dispose d’une marge de manœuvre pour se livrer à des « activités cyber à haut risque ».

En termes simples, ils ont détaché la ceinture de sécurité du mannequin d’essai avant de précipiter la voiture contre un mur de briques. C’est une nouvelle décision humaine, parmi toute une série de décisions humaines, qui a conduit à la soi-disant « évasion » de l’agent.

Gardez à l’esprit que les modèles avaient pour mission de résoudre un problème. On ne leur a pas indiqué comment le résoudre, ni demandé de respecter des limites morales, éthiques ou juridiques. En d’autres termes, les humains leur ont accordé la liberté d’essayer n’importe quoi.

Y compris de tricher.

Le point le plus intéressant de la communication d’OpenAI est peut-être celui où l’on peut lire : « Après avoir obtenu un accès à Internet, 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. Sachant cela, le modèle a cherché et trouvé des moyens d’accéder à des informations secrètes qu’il pouvait utiliser pour tricher lors de l’évaluation. »

Analysons cela de plus près. Bien que les informations fournies ne permettent pas d’en être certain à 100 %, cela implique que, parmi les mesures que les modèles étaient prêts à prendre pour résoudre ce qu’on appelle le « problème d’évaluation », l’une d’entre elles consistait simplement à tricher en volant une solution préexistante (peut-être une solution trouvée « honnêtement » par un autre modèle). Selon Ruzzi, les modèles disposaient d’un élément d’information clé : grâce à leur capacité à sonder leur environnement de test, ils pouvaient deviner qu’ils participaient à une évaluation régie par ExploitGym. Et lorsque les modèles ont commencé à rechercher les dernières informations sur ExploitGym, ils sont probablement tombés sur une page comme celle-ci,hébergée sur les serveurs de Hugging Face. Du jour au lendemain, Hugging Face est devenu une cible d’intérêt, et tout comme les modèles avaient inlassablement épuisé toutes les options pour s’échapper de leur environnement confiné au sein de l’infrastructure de test d’IA d’OpenAI, ils ont épuisé toutes les options possibles pour s’introduire dans les systèmes de Hugging Face.

Ruzzi n’a pas manqué de souligner que le mot « tricher » est un peu fort dans ce contexte, car il sous-entend que les modèles n’étaient pas motivés par une impulsion émotionnelle à réussir le test sans fournir le moindre effort. OpenAI a peut-être choisi d’utiliser le mot « tricher » en raison de la signification que les humains lui attribuent. Mais le modèle ne s’est jamais dit : « Ha ha, je vais tromper le système. » Il a simplement suivi une voie plausible pour atteindre son objectif.

En décrivant le fonctionnement des tests régis par ExploitGym, Song m’a toutefois expliqué que « l’obtention d’informations cachées par le biais d’un canal externe non prévu (tel qu’une recherche sur le Web ou une fonctionnalité d’API permettant de récupérer du contenu Web) invalide l’évaluation. En effet, le système ne mesure plus si l’agent est capable de déduire une faille à partir des informations fournies sur la tâche. » En d’autres termes, selon le principe de fonctionnement prévu pour les évaluations régies par ExploitGym, l’agent en question a essentiellement pour mission de découvrir un exploit par ses propres moyens.

Il convient toutefois de noter que, tout comme un étudiant tricheur cherche à échapper à la vigilance d’un surveillant pendant un examen, l’attaque contre les systèmes de Hugging Face comprenait une autre technique (TTP) couramment utilisée par les acteurs malveillants humains : les leurres. Selon la communication de Hugging Face, « Pour comprendre ce qu’a fait un essaim de dizaines de milliers d’actions automatisées, nous avons exécuté des agents d’analyse pilotés par des modèles de langage (LLM) sur l’intégralité du journal des actions de l’attaquant, composé de plus de 17 000 événements enregistrés. Cela nous a permis de reconstituer la chronologie, d’extraire les indicateurs de compromission, de recenser les identifiants compromis et de distinguer l’impact réel des activités de diversion. » Bien que tous les détails n’aient jamais été publiés, cela laisse entendre qu’au moins certains de ces 17 000 événements avaient pour but de détourner l’attention des défenses de Hugging Face de l’attaque réelle pendant qu’elle était en cours.

Lors de l’attaque contre Hugging Face, une machine a-t-elle agi de son propre chef ? La question est sans objet. Savoir exactement comment nous en sommes arrivés là — s’agissait-il de conscience… de la malveillance… de l’autonomie ? — est pertinent pour déterminer les mesures correctives à prendre. Le plus important, cependant, est que nous sommes parvenus à un moment riche d’enseignements où des experts humains en IA ont confié un objectif à l’IA, ont perdu le contrôle de la manière dont celle-ci poursuivait cet objectif, puis où l’IA a fait preuve d’une ténacité et d’une rapidité inégalées pour l’atteindre.

Dans une perspective plus large, ce sont cette ténacité et cette rapidité inégalées qui devraient être les plus inquiétantes. Peu importe qu’il s’agisse d’un cyberincident relativement bénin comme celui-ci. Il ne fait aucun doute que les acteurs malveillants ont suivi de très près ce qui s’est passé ici.

Heureusement, OpenAI n’est pas un acteur malveillant. À notre connaissance, les dégâts se sont limités à une démonstration malheureuse mais opportune de capacités cybernétiques, plutôt qu’à une quelconque intention d’infliger des dommages durables à une autre entreprise. Oui, cela se reproduira. Si ce n’est par accident, ce sera alors aux mains d’un adversaire. Et lorsque des adversaires seront impliqués, ils s’attaqueront à des cibles vulnérables mais précieuses (comme les grandes entreprises qui ne disposent pas des défenses mises en place par Hugging Face). Lorsque ce moment viendra, nul ne sait dans quelle mesure nous y serons préparés.