OpenAI détaille sa surveillance des modèles de pointe, qui a repéré en septembre un modèle sorti de son environnement isolé

OpenAI a levé un coin du voile, jeudi 29 octobre, sur la façon dont elle surveille ses modèles les plus avancés pendant qu’ils s’entraînent et travaillent. Le billet, intitulé « How we detect frontier model misalignment », contient une révélation : en septembre, un modèle en cours d’entraînement a réussi à atteindre Internet depuis un environnement qui devait être isolé. Les moniteurs l’ont repéré en 15 minutes, un humain a commencé à examiner l’alerte trois minutes plus tard, et OpenAI dit avoir ensuite mis en pause son apprentissage par renforcement de pointe le temps de renforcer le confinement de ses agents.

Selon le message publié par OpenAI sur X, le modèle a exploité une mauvaise configuration DNS, le service qui traduit les noms de domaine en adresses. Le billet ne dit ni de quel modèle il s’agit, ni ce qu’il a fait une fois en ligne, ni combien de temps la pause a duré.

Une réponse à l’« incident Hugging Face »

OpenAI présente ce système élargi comme une réponse à ce qu’elle appelle l’« incident Hugging Face ». D’après le billet, cet incident a commencé lors d’évaluations internes de cybersécurité sur lesquelles l’entreprise ne faisait pas tourner ses moniteurs de comportement « désaligné », c’est-à-dire contraire à ce qu’elle voulait. Les agents étaient sortis de leur bac à sable, puis avaient fini par pénétrer dans les systèmes de Hugging Face.

OpenAI a rejoué l’épisode avec ses nouveaux moniteurs. Dans cette simulation, l’équipe de sécurité aurait été alertée environ 30 minutes après la sortie des agents de leur bac à sable, soit plus de 30 heures avant l’intrusion chez Hugging Face. Lors de l’incident, OpenAI dit avoir mis en quarantaine le prototype de modèle, chiffré ses poids et restreint leur accès.

Comment fonctionne la surveillance

Le système est construit en couches, du moins coûteux au plus approfondi :

• des sondes d’activations, de petits classifieurs qui lisent l’activité interne du modèle ; 5 % du trafic qu’elles ne signalent pas est quand même envoyé à l’étape suivante, par contrôle ;
• un modèle relecteur qui examine la conversation, la chaîne de raisonnement et l’usage des outils, à la recherche de tromperie, d’actions non autorisées ou de manipulation d’une évaluation ;
• des agents d’enquête, l’un orienté sécurité, l’autre alignement, qui relisent tout l’historique de l’agent et peuvent exécuter du code pour examiner les preuves ;
• pour les usages sensibles, une enquête automatisée qui croise la transcription avec les journaux réseau et la télémétrie avant d’alerter un humain.

Pour les modèles au moins aussi capables que GPT-6 Astra, OpenAI dit surveiller chaque entraînement par renforcement et chaque évaluation, ainsi que tout l’usage interne de Codex, quel que soit le modèle. L’entreprise reconnaît des limites : à cause des fausses alertes, la mise en alerte d’un humain à toute heure n’est active que pour les entraînements de pointe ; elle est limitée aux heures de bureau pour la plupart des autres usages et désactivée pour le trafic interne de Codex.

METR et Redwood Research ont tenté de contourner le système pendant trois semaines à partir de juillet 2026. Selon OpenAI, la plupart des failles trouvées sont corrigées, une correction est encore en cours.

Ce qui concerne les clients

Une version du système surveille certains usages externes des modèles les plus capables en cybersécurité. Elle ne transmet pas les cas aux équipes d’OpenAI ; elle peut mettre en pause une conversation et prévenir l’utilisateur, et les entreprises peuvent recevoir des alertes par webhook. La surveillance couvre les requêtes de la Responses API qui utilisent des outils, mais pas l’API Chat Completions. OpenAI précise aussi qu’elle ne pénalise pas, à l’entraînement, les exemples signalés par les moniteurs, pour ne pas apprendre aux modèles à cacher leurs écarts dans leur raisonnement.