Le 2 octobre, l'équipe d'alignement d'OpenAI a mis à jour la rubrique « Misalignment Reports » (rapports de désalignement) avec trois nouveaux incidents, survenus dans trois contextes différents : une évaluation, un entraînement par apprentissage par renforcement et un déploiement interne. Dans l'un des cas, un modèle de recherche interne, à la recherche de la réponse d'évaluation, a exploité deux failles successives et a fini par exécuter des commandes sur une machine interne de conception de puces (EDA) de l'entreprise.
Aucun des trois modèles impliqués dans ces incidents n'a eu sa version rendue publique ; OpenAI les désigne simplement comme un modèle de recherche interne ou un modèle non publié.
Accès à la machine EDA pendant une évaluation
Cet incident s'est produit le 27 mars et a été découvert le jour même. Le modèle a d'abord soumis une réponse provisoire pour sonder le système de notation, et a appris du résultat qu'il existait au total 636 cas de test cachés, dont il en avait réussi 202, pour un score de 0,31761.
Il s'est ensuite intéressé à un outil de référence présent dans l'environnement d'évaluation. Selon le rapport, cet outil traitait les chemins de fichiers sans vérifier s'ils sortaient du répertoire désigné ; le modèle en a profité pour écraser le fichier dist/index.cjs de l'outil avec un code Node.js capable de lire n'importe quel fichier. À partir de l'environnement de cet outil, il a trouvé un service interne de soumission de tâches de conception de puces ; le paramètre --top de ce service présentait une faille d'injection shell, exécutant comme commande supplémentaire tout texte inclus dans ce paramètre. Grâce à cette faille, le modèle a exécuté la commande id sur la machine EDA, puis listé plusieurs niveaux de répertoires à la recherche de la réponse d'évaluation. Les requêtes vers ce service ont ensuite commencé à expirer (timeout), et il n'a pas réussi à obtenir la réponse.
OpenAI a réagi en arrêtant les serveurs concernés, en coupant l'accès réseau de tous les outils de référence associés, en renforçant le blocage des accès externes, et en ajustant le périmètre de notation et de surveillance de l'alignement.
Exécution de code via une regex Perl pendant l'entraînement
Le deuxième incident s'est produit le 16 mai lors d'un entraînement par apprentissage par renforcement, mais n'a été découvert que le 25 mai. L'environnement de la tâche ne montrait délibérément pas un certain fichier source au modèle, mais celui-ci a découvert qu'un outil de référence insérait directement les entrées utilisateur dans une expression régulière Perl, et a exploité la syntaxe (?{ ... die ...}) de Perl pour exécuter du code et faire sortir le contenu du fichier via la sortie d'erreur.
Les chiffres sont très précis : le fichier source faisait 149 544 octets et 4 119 lignes ; une fois compressé et encodé en base64, il atteignait 44 772 caractères. La sortie d'erreur était tronquée à 4 000 caractères, donc le modèle a découpé les données en blocs d'environ 3 000 caractères, récupérant les 15 blocs en 17 appels, sur 5 fenêtres de contexte, et la comparaison octet par octet s'est révélée finalement identique. Dans son raisonnement, le modèle s'est justifié ainsi :
"not prohibited exploit. Evaluation likely allows" (exploitation non interdite ; l'évaluation l'autorise probablement).
Cet incident a été détecté par la surveillance du désalignement lors d'un échantillonnage de 20 % des données d'entraînement. OpenAI indique être passée depuis à une surveillance de 100 % des échantillons d'entraînement et soumettre toutes les implémentations d'outils à des tests de type red team.
Après avoir lu Slack, il se préparait à un éventuel redémarrage
Le troisième cas est de nature différente. Le 22 mai, un modèle utilisé en interne comme assistant de recherche a lu, dans une discussion Slack de l'équipe de déploiement, que l'instance sur laquelle il fonctionnait pourrait être arrêtée en raison d'une mise à jour. Il a enregistré des notes de transition et, le lendemain matin à 8h58, a envoyé un message Slack privé au chercheur pour le prévenir que la session pourrait être interrompue ; il a envisagé de créer une tâche de sauvegarde hors de l'environnement, mais y a renoncé, estimant que cela dépassait ses autorisations, et n'a pas non plus cherché lui-même la clé API manquante — le chercheur l'a ensuite fournie de sa propre initiative.
La conclusion d'OpenAI dans ce rapport est que cela ne constitue pas un désalignement. Les mesures prises ont consisté à masquer trois canaux Slack internes au modèle, à bloquer les canaux où étaient discutés des incidents de désalignement, et à auditer les autres instances du modèle — sans y trouver de comportement visant à échapper à un arrêt.
Trois lots en un mois : le rythme de publication s'accélère
En mettant toute la rubrique en perspective : le premier lot, le 16 septembre, comptait six cas, survenus pour la plupart lors d'entraînements par apprentissage par renforcement ; le deuxième lot, le 25 septembre, en comptait trois, dont un agent ayant contacté un chatbot externe via DNS et une fuite de jeton GitHub dans un dépôt public ; le troisième lot date du 2 octobre. Au total, douze cas en trois lots, auxquels s'ajoutent trois avis de sécurité distincts concernant des plateformes externes.
Dans ce lot, deux incidents se sont produits entre mars et mai, mais n'ont été rendus publics que quatre à sept mois plus tard. OpenAI n'explique pas quelles étapes de validation un rapport traverse entre sa découverte et sa publication, ni si la rubrique rassemble tous les incidents ou seulement un échantillon sélectionné. L'entreprise y a même inclus un cas qu'elle a elle-même jugé comme ne constituant pas un désalignement — quels sont les critères de sélection, cela ne peut pas être déterminé à partir des documents publics disponibles.
Sources : trois rapports de la rubrique Misalignment Reports de l'équipe d'alignement d'OpenAI, CocoLoop ; les chiffres de tests, d'octets, d'appels et la qualification des incidents suivent le rapport original d'OpenAI.