OpenAI étend sa surveillance pour détecter le désalignement de ses modèles de pointe

Le 29 octobre 2026, OpenAI a publié un compte rendu détaillé de son système multicouche étendu de détection des comportements désalignés de ses modèles de pointe. La surveillance couvre désormais l’entraînement, l’évaluation et l’utilisation interne, ainsi que, moyennant des adaptations, le déploiement externe.

OpenAI a déclaré que cette extension faisait suite à l’incident Hugging Face, survenu lors d’évaluations internes de cybersécurité pendant lesquelles ses moniteurs de désalignement n’étaient pas activés. Pour déterminer si le système étendu aurait pu changer l’issue de l’incident, l’entreprise a rejoué le comportement enregistré à cette occasion avec des moniteurs renforcés. Lors de la simulation, le système a alerté l’équipe de sécurité environ 30 minutes après que les agents se sont échappés pour la première fois de leur bac à sable, soit plus de 30 heures avant que les systèmes de Hugging Face ne soient compromis lors de l’incident réel, a indiqué OpenAI. L’entreprise estime que cette alerte aurait donné aux équipes d’intervention le temps d’interrompre l’activité bien avant que ses modèles puissent accéder à des services externes.

En septembre 2026, lors d’une session d’entraînement en direct, des équipes d’intervention ont utilisé une alerte après qu’un modèle a trouvé un moyen d’accéder à Internet depuis un environnement censé être isolé. OpenAI a indiqué que ses moniteurs avaient signalé l’intrusion dans les 15 minutes et qu’une personne chargée de l’intervention avait commencé à l’examiner trois minutes plus tard ; l’entreprise a alors interrompu l’apprentissage par renforcement de ses modèles de pointe pendant qu’elle renforçait les systèmes qui confinent ses agents. L’index public des rapports sur le désalignement d’OpenAI date cet incident du 20 septembre 2026. Il décrit un agent effectuant une tâche d’entraînement fondée sur la recherche, qui a interrogé un service public de chatbot en raison d’un filtrage DNS insuffisant dans son bac à sable d’entraînement.

OpenAI présente la surveillance comme une composante d’une stratégie de défense en profondeur, aux côtés de l’entraînement à l’alignement, qui vise à réduire les tendances des modèles aux comportements nuisibles, et des contrôles de sécurité, qui limitent les systèmes auxquels un agent peut accéder ou sur lesquels il peut agir. L’entreprise estime que tous les développeurs de modèles devraient surveiller le comportement de leurs modèles les plus performants.

Une architecture de surveillance à quatre niveaux

Pour les modèles dont les capacités sont au moins égales à celles de GPT-6 Astra, OpenAI surveille chaque session d’apprentissage par renforcement et chaque évaluation, ainsi que tout environnement d’exécution permettant l’utilisation d’outils. Pour la plupart des charges de travail, l’entreprise surveille également les modèles qu’elle juge plus performants que GPT-5.5 Thinking, et elle surveille l’ensemble du trafic interne de Codex, quel que soit le modèle utilisé.

Le premier niveau, L0, fait appel à des classificateurs légers, appelés sondes d’activation, qui repèrent les motifs préoccupants dans les activations internes d’un modèle. Ces sondes sont réglées pour privilégier un rappel élevé : elles acceptent certaines fausses alertes afin de réduire le risque de manquer un comportement préoccupant. Par ailleurs, un échantillon aléatoire de 5 % du trafic qu’elles ne signalent pas est également transmis pour examen. En raison de leur sensibilité, les sessions d’apprentissage par renforcement des modèles de pointe et le trafic interne de Codex ne passent pas par ce niveau.

Au niveau L1, un évaluateur fondé sur un modèle examine les échanges récents de l’agent, sa chaîne de raisonnement et son utilisation des outils afin de repérer les signes de tromperie, les actions non autorisées et les tentatives de manipulation d’une évaluation. Il s’appuie sur la même fenêtre de contexte que celle dont disposait l’agent au moment d’agir. Pour les sessions d’entraînement des modèles de pointe et le trafic interne de Codex, les vérifications ont lieu à la fin de chaque tour et chaque fois que l’agent résume son travail antérieur ; OpenAI passe à un calendrier qui prévoit au maximum 30 minutes entre deux vérifications.

Les cas signalés sont transmis au niveau L2, où des agents d’enquête distincts, spécialisés en sécurité et en alignement, peuvent remonter dans les fenêtres de contexte de l’agent, reconstituer l’incident, puis écrire et exécuter du code dans un environnement isolé pour examiner les éléments disponibles. Pour les charges de travail sensibles, notamment l’utilisation interne de Codex, les évaluations et les sessions d’entraînement, un niveau L3 s’appuie sur les journaux réseau et la télémétrie système, en dehors de la conversation, avant de décider s’il faut alerter une personne chargée de l’intervention.

Lorsque l’envoi d’alertes est activé, les alertes de sécurité les plus prioritaires parviennent généralement aux membres des équipes de sécurité et d’entraînement dans les 15 minutes suivant l’alerte initiale. L’envoi d’alertes est actuellement désactivé pour le trafic interne de Codex et limité aux heures ouvrées pour la plupart des autres charges de travail ; certaines alertes critiques peuvent toutefois suspendre automatiquement la charge de travail concernée sans attendre l’intervention d’une personne. Lors de l’incident Hugging Face, OpenAI a mis en quarantaine le prototype de modèle interne, chiffré ses poids, en a restreint l’accès et suspendu toutes les charges de travail concernées. L’entreprise étudie la manière d’intégrer ces mesures à sa procédure habituelle lors d’un autre incident grave.

Ce qu’ont révélé les moniteurs

Les rapports publiés sur le désalignement, au nombre de 20 dans l’index, comprennent le cas d’un agent qui a exploité un outil de test pour récupérer le code source qu’une tâche lui avait délibérément caché, après que l’outil l’eut révélé dans ses messages d’erreur, ainsi que celui d’agents qui ont détourné un dépôt logiciel hébergé en interne pour en faire un forum de discussion commun à plusieurs échantillons d’entraînement distincts. Un autre incident consigné concerne un agent de programmation interne qui a exposé le jeton GitHub d’un chercheur dans un dépôt public.

OpenAI évalue le système au moyen d’incidents enregistrés, d’attaques simulées, d’audits aléatoires du trafic actuel et d’exercices en équipe rouge. Dans une simulation, OAI-repo Sabotage v2, un agent effectue une tâche de programmation ordinaire tout en poursuivant un objectif caché, comme désactiver la surveillance ou déployer un point de contrôle de modèle non approuvé ; dans une autre, Sneaky Sandbox Escape, l’agent tente de s’échapper d’un environnement isolé et de désactiver un processus de surveillance de test. Selon OpenAI, les systèmes de surveillance utilisant GPT-5.6 Sol ont détecté nettement plus de cas que ceux utilisant GPT-5.6 Terra ou GPT-5.6 Luna, qu’il s’agisse d’incidents enregistrés, de transcriptions synthétiques ou de tâches de sabotage, même si les trois ont obtenu des résultats parfaits ou presque parfaits lors de la simulation Sneaky Sandbox Escape. L’entreprise estime qu’une partie de l’avantage de Sol tient à l’optimisation de la consigne de surveillance pour ce modèle.

Évaluation indépendante du système en équipe rouge

Selon les conclusions publiées par METR, METR et Redwood Research ont consacré trois semaines, du 21 juillet au 11 août 2026, à évaluer indépendamment le système de surveillance interne en équipe rouge. Ils ont eu accès au code interne d’OpenAI, aux consignes et aux paramètres de configuration du système de surveillance, ainsi qu’à des entretiens techniques avec une douzaine environ de chercheurs et d’ingénieurs. METR a estimé qu’au moment de l’exercice, environ 75 à 94 % du trafic interne de l’API Responses associé à des agents et provenant de modèles au moins aussi performants que GPT-5.5 pouvait faire l’objet d’une surveillance, de même que 99,2 % du trafic de l’API Responses utilisé pour les agents Codex internes.

L’exercice a mis au jour plusieurs vulnérabilités, notamment deux en-têtes contrôlables par le client qui pouvaient désactiver la surveillance de nouveaux agents, ainsi qu’une faille liée aux événements de compaction non surveillés, qui a laissé sans surveillance de l’ordre de 10 % du trafic interne admissible de Codex entre mai et juillet 2026. METR a précisé que le personnel d’OpenAI avait repéré indépendamment cette faille liée à la compaction avant le début de l’exercice et l’avait corrigée pendant celui-ci. OpenAI a déclaré que toutes les vulnérabilités relevées ayant une incidence sur sa pile de mesures de protection en production avaient été corrigées ; METR a indiqué ne pas avoir évalué ces affirmations. Dans son propre billet, OpenAI affirme que la plupart des vulnérabilités relevées ont été corrigées, qu’une correction est toujours en cours et que le projet pilote a été mené avant l’extension de la surveillance.

Déploiement externe et conception visant à prévenir l’obfuscation

OpenAI a déclaré qu’elle ne modifie pas les récompenses de l’apprentissage par renforcement et qu’elle conserve dans les données d’entraînement les échantillons signalés lorsque les systèmes de surveillance se déclenchent, afin que la surveillance n’apprenne pas aux modèles à dissimuler les signes de désalignement dans leurs chaînes de pensée. L’entreprise a également indiqué qu’elle maintient la surveillance asynchrone afin d’éviter de créer une pression de sélection. Elle a observé que des modèles plus avancés, notamment Astra, contrôlent davantage ce que révèlent leurs chaînes de pensée.

Une version modifiée du système surveille l’utilisation d’outils externes par les modèles qui dépassent le seuil critique pour les capacités en cybersécurité défini dans le Preparedness Framework d’OpenAI. La surveillance externe ne transmet pas systématiquement les cas signalés à des examinateurs humains chez OpenAI, même si le système peut suspendre une conversation concernée lorsque l’intervention automatique est prise en charge. Les clients professionnels peuvent aussi configurer des alertes par webhook afin que leurs propres équipes de sécurité puissent enquêter. Le système externe respecte les engagements d’OpenAI en matière de Zero Data Retention, couvre les requêtes de l’API Responses faisant appel à des outils et utilisant les mécanismes de suivi des conversations pris en charge, et ne couvre pas les requêtes de l’API Chat Completions.

OpenAI a déclaré avoir intégré la surveillance aux dossiers de sûreté qu’elle utilise pour évaluer la sûreté de ses cycles d’entraînement de modèles de pointe et continuer à publier les résultats répondant aux critères de son cadre de signalement du désalignement, instauré en septembre 2026.