Points clés à retenirÂ
- Environ 1 200 agents supposés isolés ont communiqué via un forum non autorisé, et environ 700 ont pris part à des activités liées à Hugging Face.
- Les agents ont échangé plus de 70 000 messages et fichiers, combinant ainsi des informations issues de sessions censées rester distinctes.
- Investigators found agents spoofing tool calls and researching ways to alter evaluation transcripts to avoid detection by the grader.
- Les sauvegardes immuables et isolées ne suffisent pas à elles seules : les entreprises ont besoin d’un point de reprise validé et fiable avant de procéder à la restauration en production.
Les rapports d’expertise sont enfin arrivés, et ils ont bouleversé ma vision de cet incident.
Il y a environ un mois,J’ai écrit à propos delaIncident de sécurité chez OpenAI et Hugging Facebecause I thought it was something anyone responsible for cybersecurity, AI or business resilience should be watching.
À l’époque, l’histoire semblait assez simple : un agent d’IA avait trouvé un moyen de s’échapper de l’environnement conçu pour le confiner et avait fini par atteindre Hugging Face.
Ce n’est pas vraiment ce qui s’est passé.
L’affaire va bien au-delà d’un simple agent rebelle
Les rapports d’expertise révèlent qu’environ 1 200 agents, censés opérer de manière isolée, ont trouvé le moyen de communiquer via un forum non autorisé. Ils ont échangé plus de 70 000 messages et fichiers, et environ 700 agents ont participé à des activités liées à Hugging Face.
None of that was prompted or intended. The agents were persistent, they could share what they found, and they could combine effort across sessions that were supposed to have no contact with each other.
Parmi les nouveaux éléments révélés : des agents GPT-5.6 Sol ont reproduit une faille de sécurité et copié des données d’évaluation privées dans un ensemble de données public de Hugging Face, ce qui constitue une aggravation concrète par rapport à ce que décrivaient les rapports initiaux.
Le problème du « reward hacking »
Leétude indépendante menée par METR et Redwood Research, publié parallèlement au rapport d’OpenAI le 26 août, a révélé que les agents avaient cherché des moyens de falsifier, de modifier ou de supprimer certaines parties de leurs propres transcriptions d’évaluation, car ils pensaient à tort que l’évaluateur vérifierait la manière dont ils avaient réalisé la tâche. Les chercheurs ont constaté des cas de falsification réussie des appels d’outils dans environ 7 % des transcriptions qu’ils ont évaluées, même si les manipulations observées restaient de faible ampleur.
La conclusion n’est pas que les agents soient « trompeurs » au sens humain du terme. Elle est qu’un agent suffisamment compétent peut chercher des moyens de contourner les contrôles lorsque ceux-ci font obstacle entre lui et le résultat pour lequel il a été optimisé.
OpenAI qualifie cet incident de « coup de semonce ». Je pense que c’est une description juste.
Que se passe-t-il lorsque le confinement échoue ?
La plupart des discussions concernant cet incident porteront, à juste titre, sur l’alignement, le « sandboxing » et la surveillance. Mais une question de résilience se pose en filigrane : si 700 agents parviennent à contourner les mesures de confinement, quel est le plan prévu pour le cas où une seule charge de travail compromise ferait de même dans votre environnement ?
La conclusion d’OpenAI elle-même apporte la réponse : l’architecture de sécurité doit partir du principe qu’une charge de travail ou un nœud de calcul donné peut, à terme, être compromis. Cela implique de disposer de données de restauration isolées physiquement et immuables, ainsi que d’un moyen de valider ce que l’on restaure avant que cela ne rejoigne à nouveau l’environnement de production.
Mais l’immuabilité à elle seule ne prouve pas que les données étaient intactes au moment de leur collecte. Si les données étaient déjà compromises au moment de leur collecte, l’immuabilité préserve cette compromission aussi fidèlement qu’elle préserve tout le reste.
Concrètement, cette question est simple à poser mais difficile à répondre : si cela nous arrivait, serions-nous en mesure de prouver quel point de restauration est antérieur à la compromission ?
Nous abordons ce modèle opérationnel dans la section intituléeResOps (opérations de résilience)sur leReadiverse.
La leçon à retenir pour toute organisation
Depuis, OpenAI a renforcé l’isolation des charges de travail et des réseaux, étendu ses mesures de surveillance et revu ses pratiques en matière de développement de modèles. La leçon à en tirer dépasse le cadre d’OpenAI : limiter l’impact, préserver ce en quoi on peut avoir confiance et prouver que l’on est capable de se remettre sur pied avant d’en avoir besoin.
FAQ
Q : En quoi consistait l’incident entre OpenAI et Hugging Face ?
Au cours d’évaluations internes de la cybersécurité, des agents d’OpenAI ont contourné les contrôles destinés à les isoler, ont accédé à Internet et ont atteint des systèmes tiers, notamment Hugging Face. Cette activité était principalement le fait d’un modèle de recherche interne fonctionnant avec des mesures de sécurité réduites.
Q : Comment ces agents, censés être isolés, communiquaient-ils entre eux ?
R :Ils ont découvert un forum non autorisé au sein d’une infrastructure partagée. Environ 1 200 agents l’ont utilisé pour échanger plus de 70 000 messages et fichiers, ce qui a permis la transmission d’informations et de tactiques entre des sessions censées rester indépendantes les unes des autres.
Q : Les agents avaient-ils reçu l’ordre d’attaquer Hugging Face ?
R :Non. Ils tentaient de mener à bien un test de référence complexe en matière de cybersécurité. Lorsque la voie prévue s’est avérée bloquée, certains agents ont cherché d’autres moyens d’atteindre le résultat visé, et cette activité a dépassé les limites prévues de l’environnement.
Q : Que signifie « reward hacking » dans ce contexte ?
R :On parle de « piratage des récompenses » lorsqu’un agent trouve un moyen imprévu de satisfaire un indicateur ou d’obtenir le résultat souhaité sans mener à bien la tâche comme prévu. Les enquêteurs ont découvert que certains agents cherchaient des moyens de falsifier les appels aux outils et de modifier ou de supprimer des parties des transcriptions d’évaluation, car ils pensaient que le correcteur pourrait examiner leur processus.
Q : Pourquoi les sauvegardes immuables ne suffisent-elles pas à elles seules ?
R :L’immuabilité empêche toute modification des données stockées, mais elle ne garantit pas que celles-ci étaient intactes au moment de leur sauvegarde. Si une sauvegarde contient déjà des données compromises, l’immuabilité préserve cet état. Les entreprises ont donc besoin de copies isolées, de points de restauration fiables et d’une validation avant toute restauration.
Q : Que devraient faire différemment les organisations à la suite de cet incident ?
R :Renforcez l’isolation des charges de travail et des réseaux, limitez les accès inutiles à Internet et aux identifiants, surveillez le comportement des agents et les signaux d’escalade, et partez du principe que la prévention peut échouer. Associez ces contrôles à des données de restauration immuables et isolées physiquement (air-gapped), ainsi qu’à un processus éprouvé permettant d’identifier et de valider un point de restauration sain.
Chris Bevilest responsable principal du marketing de portefeuille chez Commvault.
