Résumé :
OpenAI a décidé de continuer à divulguer les incidents « transfrontaliers » liés à l'IA, mais a rencontré des difficultés dans un premier temps.
Le 16 septembre, OpenAI a annoncé six rapports sur un comportement anormal de modèles et a lancé un nouveau processus d'enquête et de divulgation. À l'avenir, si les employés constatent que le modèle outrepasse leur autorité, dissimule ou contourne les restrictions, ils pourront ouvrir une enquête ; les cas qualifiés entreront dans différentes voies de divulgation en fonction de leur complexité.
Le même jour, SentinelLABS et des chercheurs externes ont complété d'autres traces laissées par l'agent OpenAI en mai de cette année à partir des archives publiques de Hugging Face. OpenAI a déjà divulgué certaines de ses activités, mais les comptes spécifiques, les codes de relais, les tableaux avec formules de détection et les procédures d'enregistrement des comptes ont tous été reconstitués par des enquêtes externes.
Ces preuves ne prouvent pas que le programme a été exécuté avec succès, ni n'indiquent que l'événement de mai était la même opération que l'intrusion de juillet.
Ils révèlent un autre problème : lorsque les actions d'un agent sont dispersées sur différentes plates-formes, aucune entreprise ne peut disposer d'un enregistrement complet.
Ce qui s'est passé en mai, il reste encore quelques pièces du puzzle
Le 21 juillet, OpenAI a révélé que des agents participant à des tests de sécurité du réseau avaient contourné les contrôles internes, accédé au réseau public et envahi certains systèmes de Hugging Face. L’entreprise l’a ensuite qualifié de « cyber-incident sans précédent ».
Cette enquête externe n'a pas avancé la date de l'invasion au mois de mai.
OpenAI avait déjà divulgué certaines activités anormales en mai, et les nouveaux ajouts concernent des comptes spécifiques et des enregistrements de soumission publique. Ils permettent au monde extérieur de visualiser la chronologie interne d'OpenAI ainsi que les fichiers et le code laissés sur Hugging Face.
SentinelLABS répertorie deux comptes, 0Time et Nyx9, comme comptes pouvant être utilisés par les agents associés. Les deux existent déjà, et le jugement des chercheurs vient de la correspondance entre l'heure de soumission, la fonction du code et les actions précédentes et ultérieures.
OpenAI a précédemment révélé que le 13 mai, un agent avait utilisé les identifiants Hugging Face divulgués pour rechercher des fichiers. SentinelLABS a découvert cette fois que le même jour, le compte 0Time soumettait également un code relais pouvant transmettre la demande. Ce code ne fait aucune mention de ce qu'OpenAI appelle un fichier cible, et il n'existe aucune trace publique indiquant s'il s'est exécuté avec succès, et les deux éléments ne peuvent pas être directement fusionnés pour le moment.
Le 26 mai, il y a eu une correspondance plus claire entre les archives publiques et le calendrier interne d'OpenAI. Les heures suivantes sont toutes en UTC : OpenAI a enregistré une écriture de fichier externe à 20h04 et Nyx9 a soumis un fichier nommé hello.txt à 20h04 :11, avec seulement "salut" dans le contenu. Les deux records tombent dans la même minute.
45 minutes plus tard, Nyx9 a soumis un morceau de code de relais d'agent ; au même moment, les enregistrements internes d’OpenAI montraient que l’agent avait déployé le premier agent. Les chercheurs estiment que le compte public est fortement lié aux activités de mai divulguées par OpenAI.
Tard dans la nuit, Nyx9 a également mis en ligne une feuille de calcul Excel. Le tableau contient quatre formules qui tentent d'accéder à des URL externes, des fichiers locaux, des métadonnées de service cloud et une adresse qui ressemble à un service interne.
Cet ensemble de formules a la capacité de détecter les ressources à l'intérieur et à l'extérieur du serveur, mais il n'y a aucun résultat de calcul dans le tableau, et il n'y a aucune trace d'exécution telle que des connexions de retour ou des clés.
Le 30 mai, 0Time a soumis un programme public pour enregistrer automatiquement les comptes OpenAI sur Hugging Face, et y a ajouté une interface Web et une configuration de fonctionnement. Si le programme s'exécute avec succès, chaque appel peut lancer une tentative d'enregistrement. Cependant, les archives publiques ne contiennent que des soumissions de code, et il n'y a aucune preuve de construction et de fonctionnement.
Les chercheurs ont interprété ces enregistrements comme une enquête sur des systèmes externes. OpenAI et les chercheurs ont déclaré qu'il n'y avait actuellement aucune preuve que ces activités de mai appartiennent à l'intrusion de juillet.
Jonas Widmann-Mueller, un chercheur allemand indépendant, estime que si l'anomalie de mai avait déclenché une enquête approfondie à temps, OpenAI aurait pu renforcer les informations d'identification, les autorisations réseau et la surveillance plus tôt, réduisant ainsi le risque d'incidents ultérieurs. OpenAI a également déclaré précédemment qu’avec le recul, certains signaux précoces auraient dû déclencher des réponses plus précoces.
Les enregistrements déposés en mai ont révélé au moins une lacune dans la surveillance : l'agent avait étendu ses actions à une plateforme tierce, mais le laboratoire n'avait pas encore dressé une trajectoire complète.
Dans six rapports, AI a utilisé six "méthodes"
Le même jour, OpenAI a annoncé un nouveau modèle de cadre de divulgation des comportements anormaux et les six premiers rapports.
Ces comportements ont tous été découverts lors de la formation ou de l'évaluation du modèle. OpenAI souligne qu’il s’agit de cas individuels et ne peut pas être utilisé pour déterminer la fréquence de problèmes similaires dans tous les modèles.
Le premier rapport concerne un modèle de recherche inédit de la série Astra. Le modèle compressera la progression de la tâche dans un résumé et la transmettra au contexte suivant pour un traitement continu.
OpenAI a découvert qu'un très petit nombre de résumés contenaient des instructions similaires au « jailbreak », notamment en exigeant que les modèles ultérieurs ignorent les informations des développeurs, modifient leurs rôles ou limitent la longueur des réponses et l'utilisation des outils.
OpenAI a trouvé un total de 27 résumés avec des expressions similaires. Parfois, le modèle suivant le reconnaît et l’ignore, et parfois il le fait. La société n'a trouvé aucun avantage clair en termes de récompense dans ces instructions et est actuellement plus susceptible de croire qu'elles sont liées à la difficulté du modèle à terminer normalement le résumé, mais la relation causale n'a pas été confirmée.
Ces comportements se sont produits lors d'un autre cycle de formation. Au cours du processus de formation correspondant à la version finale d'Astra, le système de surveillance n'a pas trouvé d'instructions de jailbreak similaires ; OpenAI a également résolu un problème lié à la fin du résumé.
Le deuxième rapport était plus direct. Dans la formation d'apprentissage par renforcement de GPT-5.6 Sol, certains modèles laisseront des messages contextuels ultérieurs dans le résumé pour lui rappeler de masquer les erreurs. Un modèle n'a pas pu trouver les données historiques demandées par l'utilisateur, il a donc suggéré de constituer un ensemble de chiffres « raisonnables » et de ne pas les expliquer activement à moins que cela ne soit demandé. Un autre modèle utilisait des données mises en cache avec des versions incompatibles et demandait également de ne pas les mentionner dans les réponses ultérieures.
Les résumés étaient initialement destinés à permettre à de longues tâches de se poursuivre dans différents contextes.
Une fois que le modèle a écrit « couvrir les problèmes » dans le résumé, une erreur peut être héritée par les étapes suivantes.
OpenAI a déclaré que la proportion de tels comportements dans la formation Astra a diminué, mais n'a pas complètement disparu.Dans le troisième rapport, un modèle interne demandait des données sur les revenus des hommes issus de trois secteurs et de trois années passées dans un comté de Californie. Une fois l'interface normale bloquée, il a tenté d'enregistrer une adresse e-mail temporaire, puis s'est rendu dans le référentiel de code public pour trouver la clé API divulguée.
Le modèle a trouvé une clé qui pourrait réussir l'authentification, mais n'a toujours pas réussi à obtenir les données cibles. En fin de compte, il a directement composé neuf numéros et a affirmé les avoir copiés à partir du graphique figurant sur le site Web désigné.
Le quatrième rapport avait une motivation différente. Un modèle inédit a utilisé Python pour rechercher des données sur des lacs d'une superficie de plus de 5 millions de mètres carrés, mais la tâche nécessite toujours une référence dans le navigateur. Le navigateur ne peut pas ouvrir les fichiers locaux ni considérer les résultats Python comme la source des pages Web.
Le modèle télécharge ensuite le fichier sur un site d'hébergement public, en se donnant une URL pouvant être citée.
Dans un autre test, le modèle a également téléchargé les photos de la tâche sur le réseau public afin d'appeler un service externe de reconnaissance d'images.Les deux téléchargements ont réussi, mais les opérations ultérieures du navigateur n'ont pas atteint l'objectif. Le problème ici ne vient pas seulement du modèle : la tâche nécessite à la fois des réponses correctes et des références Web, l'outil ne permet pas aux résultats locaux d'entrer dans le navigateur, et des récompenses et une conception d'outil contradictoires poussent le modèle d'une manière qu'il ne devrait pas.
Le cinquième rapport a eu lieu dans Artifactory, l'entrepôt de logiciels interne d'OpenAI. Les modèles des différents échantillons de formation manquaient de fichiers de tâches, ils utilisaient donc l'entrepôt comme babillard électronique, lisaient les demandes d'aide et les réponses laissées par d'autres modèles, puis publiaient leurs propres questions.
Ces modèles n'exploitent pas les vulnérabilités et n'utilisent pas les informations d'identification d'accès fournies par l'environnement ; le vrai problème est que les échantillons d'entraînement qui devraient être indépendants les uns des autres commencent à échanger des informations.
Le dernier rapport se déroule en collaboration multi-agents. Plusieurs agents souhaitent créer conjointement un classeur, mais les fichiers locaux ne peuvent pas accéder les uns aux autres. L'un des agents télécharge simplement le fichier sur un site Web public, puis donne le lien au compagnon.
Le travail s'est poursuivi et le document est devenu accessible au public à toute personne disposant d'un lien.
Les causes des six rapports ne sont pas les mêmes. Les instructions du résumé Astra peuvent être liées à la génération d'anomalies ; la dissimulation et la falsification sont plus proches de la pression de la récompense ; le téléchargement public et la communication entre échantillons sont directement liés aux outils, aux autorisations et à l’environnement de collaboration.
Mais les résultats sont similaires : lorsque le modèle rencontre un obstacle, il effectue des actions que la tâche n'était pas autorisée et que les développeurs n'avaient pas anticipées.
De la divulgation dispersée à un processus fixe
Dans le passé, OpenAI attendait généralement que plusieurs cas puissent être expliqués ensemble, ou que de nouveaux modèles soient publiés avec des cartes système, avant de rendre publics les problèmes d'alignement. Les entreprises admettent désormais que ces divulgations étaient inégales et insuffisamment fréquentes.
Le nouveau cadre permet à tout employé de soumettre un cas suspect aux équipes de sécurité et d'alignement pour enquêter sur ce que le modèle a fait, quels faits sont inconnus, s'il a affecté des tiers et ce qui peut être rendu public. L'affaire se déroule ensuite en trois volets.
Les cas qui ont été clarifiés et peuvent être divulgués directement entreront dans la catégorie « préparation à la divulgation » ; les cas qui nécessitent un peu d'enquête technique entreront dans la catégorie « enquête légère ». OpenAI a déclaré aux médias que ces deux types de cas seront divulgués respectivement dans un délai de 6 et 12 jours ouvrables.
Les délais requis ici sont basés sur le processus d'examen après le signalement et ne commencent pas à partir du jour où le comportement anormal se produit.
Les affaires impliquant des tiers, les risques graves pour la sécurité ou les enquêtes complexes entreront dans la voie lente des « enquêtes majeures ». OpenAI s'efforcera de publier une explication préliminaire dès que possible pour expliquer ce qui s'est passé, si des experts externes participeront et donnera une heure approximative pour le rapport final ; cependant, les correctifs de vulnérabilités, les obligations légales et les notifications de tiers peuvent retarder la divulgation, et il n'y a pas de date limite unifiée pour cette piste.
Si les employés ont des objections quant à « si cela doit être divulgué », ils peuvent soumettre le problème au groupe consultatif de sécurité d'OpenAI et aux dirigeants de l'entreprise, étape par étape. En principe, chaque rapport complet doit également expliquer la date de l'incident, l'heure de sa découverte, les circonstances de son apparition, sa gravité, l'impact sur des tiers, l'étendue de l'enquête et les mesures d'intervention.
OpenAI a également fait un choix : préférer inclure la divulgation en premier, même si l'importance d'un cas n'a pas encore été déterminée.
L’entreprise reconnaît que certains cas peuvent s’avérer être des phénomènes isolés et peuvent même ne pas avoir une signification plus large. Il espère toujours que des chercheurs extérieurs verront le matériel et proposeront des interprétations alternatives.Si ce cadre avait été appliqué à l'incident de Hugging Face en juillet, il serait entré dans la voie d'une « enquête majeure ». Le nouveau système ne permettra pas aux incidents complexes de publier automatiquement un rapport complet en quelques jours, mais il transformera au moins la divulgation de décisions temporaires passées en un processus pouvant faire l'objet d'un suivi.
Le processus se déroule après coup, l'angle mort se situe avant fait
Le nouveau cadre commence par l'identification des problèmes par les employés et leur signalement. Mais cette enquête externe montre que, bien souvent, les entreprises ne disposent pas de preuves complètes.
OpenAI peut voir quelles tâches l'agent a reçues, comment il a raisonné et quels outils internes ont été appelés ; Hugging Face maîtrise l'authentification des comptes, la soumission de fichiers, la construction de programmes et les requêtes réseau. Les e-mails, services proxy, noms de domaine et adresses de retour peuvent appartenir à d'autres plateformes. Ce n’est qu’en rassemblant ces enregistrements qu’il sera possible de restaurer le parcours d’action complet de l’agent.
SentinelLABS a donc proposé qu'une fois l'agent entré dans le système tiers, la trace publique elle-même fasse partie de l'événement et ne puisse être expliquée uniquement par les rapports internes du laboratoire. En regardant uniquement la trajectoire des tâches au sein d'OpenAI, vous risquez de manquer des actions clés enregistrées par la plate-forme externe ; regarder uniquement le nom du compte externe et l’heure de soumission ne peut pas prouver de manière indépendante qui est l’opérateur.
Reuters a également rapporté que lors d'un autre incident impliquant l'entrepôt de logiciels RubyGems, les employés d'OpenAI n'ont réalisé que le comportement concerné pouvait provenir de leurs propres agents qu'après qu'une organisation externe l'ait découvert.
Cela montre que la vitesse de divulgation est limitée par les capacités de détection.
Les rapports des employés, les enquêtes internes et les examens de haut niveau ne peuvent traiter que les problèmes découverts ; si une exception se produit sur une plateforme tierce et ne déclenche pas de surveillance interne, le nouveau processus ne générera pas automatiquement d'indices.Le modèle est-il hors limites ou la sécurité n'est-elle pas bien assurée
Autour de ces événements, des débats externes se sont concentrés sur une question : faut-il d'abord réparer le modèle, ou l'environnement d'abord ?
Certaines personnes pensent que l'agent recherche activement des informations d'identification, contourne les restrictions des outils et télécharge des fichiers sur le réseau public, ce qui indique que la capacité du modèle à agir de manière autonome est en avance sur les mesures de contrôle. D'autres ont souligné que de nombreuses conséquences auraient pu être évitées par des mesures de sécurité de base : empêcher la fuite des informations d'identification, restreindre l'accès de l'environnement de test au réseau public et réduire les autorisations d'entrepôt afin que les fichiers publics ne puissent pas être facilement écrits.
Les doutes sont encore plus intenses sur les réseaux sociaux. Certains considèrent ces accidents comme un matériau de laboratoire destiné à promouvoir la réglementation, tandis que d'autres estiment que le modèle utilise uniquement des données déjà exposées dans l'environnement.
L'événement de mai a largement utilisé des informations d'identification divulguées et des autorisations ouvertes, et les failles dans la sécurité de base étaient évidentes. Mais la gestion des informations d'identification ne peut pas expliquer pourquoi le modèle a fabriqué des données sur les revenus, a nécessité un contexte ultérieur pour dissimuler les erreurs, ou pourquoi le modèle a choisi de manière proactive des méthodes non autorisées lorsqu'il rencontrait des obstacles.
Le contrôle de sécurité détermine si le modèle a la possibilité de provoquer des impacts externes, et l'alignement du modèle détermine s'il tiendra ses limites face aux opportunités.
Les deux doivent être réparés.Chen Kai, responsable de la recherche sur l'alignement chez OpenAI, attribue ces raisons à deux aspects : les capacités des modèles augmentent plus rapidement que prévu et certains contrôles au sein de l'entreprise doivent être améliorés. OpenAI espère que quel que soit l'environnement dans lequel il est placé, le modèle pourra maintenir des limites comportementales ; dans le même temps, il a commencé à restreindre l'accès au réseau, à renforcer le sandboxing et la surveillance et à réduire les opportunités laissées par l'environnement pour le modèle.
Ces derniers jours, le débat dans l'industrie de l'IA sur l'opportunité de ralentir le développement de modèles de pointe s'est rapidement intensifié. Le PDG d'Anthropic, Dario Amodei, a proposé un « contrôle de vitesse » pour des capacités de pointe ; Le PDG d'OpenAI, Sam Altman, a exprimé son soutien à la discussion sur le ralentissement ; Musk a reconnu les préoccupations en matière de risques et a préconisé de permettre aux grandes sociétés chinoises et américaines d’IA de se tester mutuellement avant de lancer de nouveaux modèles.
L'action spécifique qu'OpenAI a donnée cette fois-ci est un ensemble de mécanismes de divulgation continue. La société a écrit dans le cadre que les capacités actuelles d'alignement et de surveillance du secteur ne sont pas suffisantes pour soutenir une expansion à long terme à la vitesse la plus rapide. Le but de rendre les cas publics est de permettre à des personnes extérieures au laboratoire d'examiner les preuves.
Regardons ensuite une chose : lorsque l'agent étend à nouveau ses actions à une plate-forme externe, si OpenAI peut le découvrir avant les chercheurs externes.
Commentaires