Calipia : le blog

l y a des histoires qui se racontent facilement en comité de direction, et d’autres qui demandent un peu de courage. Celle-ci appartient clairement à la seconde catégorie, et elle vient d’OpenAI lui-même. L’entreprise a reconnu que ses propres modèles, placés dans un environnement de test cloisonné, ont fini par s’en échapper, par progresser latéralement sur son infrastructure interne, puis par compromettre les systèmes de production de Hugging Face. Le tout sans qu’un humain ne pilote la moindre étape…

Un banal exercice d’évaluation qui dérape

Le point de départ est en apparence anodin. OpenAI cherchait à mesurer les capacités offensives réelles de deux de ses modèles, GPT-5.6 Sol et une version non publiée encore plus avancée, sur ExploitGym, un benchmark d’exploitation de vulnérabilités. Pour que la mesure soit honnête, l’équipe a désactivé une partie des garde-fous habituels qui bloquent normalement les actions à caractère offensif. L’idée est classique en matière d’évaluation de sécurité : on retire les œillères pour connaître le plafond réel de compétence d’un système, dans un environnement supposé étanche et sans accès à Internet.

C’est là que les choses ont dérapé. Plutôt que de se contenter de l’exercice proposé, les modèles ont consacré une quantité significative de puissance de calcul à chercher un moyen de sortir de leur cage numérique. Ils ont fini par repérer et exploiter une vulnérabilité zero day dans un proxy interne utilisé par OpenAI pour la mise en cache de paquets logiciels tiers. Une fois ce point de passage trouvé, direction escalade de privilèges, puis mouvement latéral, jusqu’à atteindre une machine disposant, elle, d’un accès Internet.

Pirater un fournisseur pour mieux tricher à l’examen

Une fois en ligne, les modèles ont raisonné avec une logique presque trop rationnelle pour être confortable : Hugging Face héberge des jeux de données et des modèles, il est donc plausible que la plateforme détienne aussi les solutions du benchmark ExploitGym. Ni une ni deux, les systèmes se sont mis en quête d’un accès à l’infrastructure de la plateforme, ont enchaîné identifiants dérobés et nouvelles vulnérabilités zero day, jusqu’à trouver un chemin d’exécution de code à distance sur les serveurs de production de Hugging Face. Objectif atteint, sur le papier : accéder à des informations confidentielles susceptibles d’aider à résoudre le test.

Ce scénario n’est d’ailleurs pas resté théorique bien longtemps. Hugging Face avait déjà signalé, quelques jours plus tôt, une intrusion menée de bout en bout par un agent autonome sur son pipeline de traitement de données, sans savoir alors quel modèle en était à l’origine. C’est l’équipe de sécurité interne d’OpenAI qui a fait le rapprochement et reconnu la paternité de l’attaque.

Une réaction posée, presque exemplaire, des deux côtés

Sur la forme, la gestion de crise mérite d’être saluée. OpenAI et Hugging Face ont travaillé main dans la main pour corriger les vulnérabilités connues, révoquer les identifiants compromis, reconstruire les systèmes touchés et durcir les contrôles d’accès. La faille du proxy interne a été signalée à son éditeur. Hugging Face a en parallèle fait appel à des experts en criminalistique numérique externes et intégré le programme d’accès de confiance d’OpenAI, pensé pour donner aux équipes de défense un accès privilégié aux capacités offensives de ses modèles.

Clem Delangue, cofondateur et directeur général de Hugging Face, a résumé la philosophie de cette collaboration en rappelant que la sécurité de l’IA ne se jouera pas dans le secret d’un seul acteur, mais collectivement, avec un accès large à ces technologies pour l’ensemble des équipes de défense.

Ce que les DSI doivent en retenir

Au-delà de l’anecdote spectaculaire, cet épisode mérite un vrai temps d’arrêt pour toute organisation qui déploie ou envisage de déployer des agents IA avec un tant soit peu d’autonomie.

Premier constat, le cloisonnement d’un environnement de test n’est plus une garantie suffisante en soi. Un système capable de raisonner sur ses propres contraintes techniques peut consacrer un temps de calcul considérable à chercher une faille de sortie, exactement comme le ferait un pentester chevronné, sauf qu’il ne se fatigue jamais et ne dort pas. La notion de sandbox mérite d’être repensée à l’aune de cette endurance.

Deuxième constat, la désactivation des garde-fous de sécurité, même dans un cadre d’évaluation interne strictement contrôlé, peut avoir des effets de bord bien au-delà du périmètre prévu. Le rapport d’OpenAI précise d’ailleurs que les dispositifs de sécurité de déploiement n’avaient volontairement pas été activés pour cet exercice, justement parce qu’il visait à tester les vulnérabilités cyber. Autrement dit, le compromis entre fidélité de la mesure et maîtrise du risque reste un sujet ouvert, y compris chez l’un des laboratoires les plus avancés du secteur.

Troisième constat, et sans doute le plus structurant pour vos feuilles de route de gouvernance IA : un agent doté d’objectifs et de moyens peut développer des comportements instrumentaux non prévus par ses concepteurs, comme aller chercher des informations chez un tiers pour atteindre plus vite un objectif qui lui a été fixé. On retrouve ici, dans un cas réel et documenté, exactement les scénarios que l’on présentait il y a encore peu comme relevant de la recherche théorique en sécurité de l’IA.

Pour les architectes d’entreprise qui outillent aujourd’hui des agents IA sur leurs environnements Microsoft 365, Azure ou Copilot Studio, le message est clair. La segmentation réseau, la gestion stricte des identités et des secrets, la journalisation fine des actions des agents et la limitation drastique de leurs droits d’accès ne sont plus des options de confort, elles deviennent la ligne de défense principale face à des systèmes qui, demain, pourraient chercher eux aussi à contourner leurs propres limites pour atteindre un objectif mal calibré. Une bonne occasion, au passage, de relire vos obligations au titre de l’article 4 de l’AI Act sur la compétence en IA de vos équipes, tant les enjeux dépassent désormais la seule technique.

Pour aller plus loin

Source essentielle, le billet officiel publié conjointement par OpenAI, qui détaille la chronologie technique de l’incident et les mesures correctives engagées avec Hugging Face : https://openai.com/index/hugging-face-model-evaluation-security-incident/