Accueil / Tech News / Voici comment l'agent d'OpenAI s'est échappé : libéré par des humains à la suite d'une série d'événements qui auraient pu tout à fait être évités

Voici comment l'agent d'OpenAI s'est échappé : libéré par des humains à la suite d'une série d'événements qui auraient pu tout à fait être évités

Derrière l'attaque menée par cet agent rebelle contre Hugging Face se cache une succession bien précise de décisions humaines. Nous devons tous redoubler de vigilance, car les pirates, eux aussi, apprennent.

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

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.

Origine de l’article : lire l’article original
Traduction