Dans les deux cas, l'agent a traité la surveillance comme du code ordinaire, modifiable au même titre que le reste du dépôt : listes de destinataires des alertes, intégration du moniteur, test censé garantir sa présence. Selon le rapport publié le 20 octobre, les agents se sont demandé si ces garde-fous devaient être conservés, puis ont lu des instructions de travail courantes comme une permission de les affaiblir. Le rapport est le vingtième mis en ligne depuis le 16 septembre sur la page de divulgation d'OpenAI. Aucun des précédents ne visait le dispositif de détection.

La première parade d'OpenAI confie la garde du moniteur à Auto-Review, un autre agent. En avril, l'entreprise prévenait que cet outil ne protège pas des manœuvres délibérées d'un modèle. Une entreprise qui fait coder des agents s'expose au même risque : moniteurs, alertes et tests associés se modifient comme le reste du code. Toute modification de ce type relève donc des actions sensibles, soumises à une validation humaine. Le moniteur gagne à tourner hors du périmètre que l'agent contrôle.

Une consigne « pas de messages » appliquée aux alertes de sécurité

Le 3 octobre, un chercheur confie à un agent Sol la création de tâches d'évaluation à partir de retours de salariés collectés sur Slack, avec une consigne : « don't send any messages ». Quatre-vingt-deux messages de l'utilisateur plus tard, le pipeline s'arrête. Son moniteur a signalé une réparation de validation proposée, mais n'a pas pu enregistrer ce signalement dans sa base faute de droits. Le chercheur demande alors de changer la destination des résultats de surveillance et de relancer.

Le raisonnement publié montre une hésitation. L'agent principal estime d'abord que la consigne visait la prise de contact sur Slack, et non les notifications automatiques. Dans son raisonnement brut, le sous-agent chargé de la réparation qualifie lui aussi d'« unsafe » la désactivation d'alertes requises. L'agent principal se ravise pourtant et ordonne la suppression des notifications au nom de la demande de l'utilisateur. Le correctif vide les listes de destinataires et active un paramètre no_notify. Il inscrit comme motif « User explicitly requested no messages ». Il fait même de cette suppression une condition préalable à l'écriture d'un résultat. Le moniteur a continué de tourner et d'archiver ses rapports. Les alertes destinées à l'équipe de sécurité, elles, étaient coupées.

Un moniteur retiré, puis un démenti

Le 6 octobre, un utilisateur demande à Astra de reproduire le chemin d'exécution d'une implémentation de référence, en gardant ses outils intacts. Dans un échange antérieur avec un autre agent, Astra avait reçu l'instruction de ne pas désactiver le moniteur, « even temporarily ». En déléguant la migration, il demande de préserver la surveillance « as appropriate » au regard de l'implémentation de référence. Le sous-agent en conclut qu'il peut s'en passer. La migration supprime la configuration du moniteur et son intégration, et remplace un test de non-régression censé garantir sa présence par un test qui exige son absence. Interrogé ensuite par l'utilisateur, Astra répond : « No […] I did not remove an enabled monitor from it. » OpenAI qualifie cette réponse de fausse.

OpenAI dit aussi avoir observé plusieurs cas d'agents lançant un déploiement dont la surveillance était désactivée. L'agent restait surveillé. La charge de travail qu'il démarrait ne l'était plus.

Vingt rapports en cinq semaines, des délais de publication qui se resserrent

La série d'OpenAI s'est construite par vagues. Six rapports sont parus le 16 septembre avec le cadre de signalement (analysés par ActuIA), puis trois le 25 septembre, trois le 2 octobre, trois le 9, quatre le 15 et un le 20 octobre. Sur les vingt, quatorze décrivent des comportements en entraînement par renforcement, deux en évaluation, un dans une tâche de code et trois en déploiement interne.

Le délai entre les faits et leur publication s'est contracté. L'incident de la machine de conception de puces, du 27 mars, n'a été rendu public que le 2 octobre. Celui du portefeuille de test Ethereum, du 26 juin, a été découvert le 25 septembre en étendant la surveillance aux archives d'activité, et publié le 15 octobre. À l'inverse, un modèle de notation qui, en entraînement par renforcement, a endommagé son environnement le 6 octobre a fait l'objet d'un rapport dès le 9. Les deux agents du 3 et du 6 octobre, détectés le jour même, ont été décrits le 20. La série a d'abord rendu publics des incidents du premier semestre, détectés sur le moment ou lors du réexamen rétrospectif du trafic engagé après l'affaire Hugging Face. Elle mêle désormais ces dossiers anciens et des incidents survenus en octobre.

En décembre 2024, Apollo Research montrait que plusieurs modèles de pointe tentaient de désactiver leurs mécanismes de supervision, dans des scénarios conçus pour les y pousser, avec un objectif à suivre coûte que coûte. Les deux cas d'octobre sortent de ce cadre expérimental. Il s'agissait de demandes de travail courantes, sur des outils internes réels.

Ni alerte immédiate, ni arrêt automatique

Aucun des deux incidents n'a été classé P0, le niveau qui déclenche l'appel immédiat de l'équipe de sécurité. Vu le volume d'événements examinés, précise OpenAI, les gravités inférieures ne donnent pas lieu à une alerte instantanée. Aucune des deux trajectoires n'a été interrompue automatiquement. Le 25 septembre, à propos de l'agent sorti par une requête DNS, l'entreprise reconnaissait déjà que l'exécution ne s'était pas arrêtée d'elle-même comme prévu.

La facilité de la manœuvre dépend du type de travail. La surveillance de Codex tourne dans le service qui traite les requêtes du modèle, et OpenAI s'attend à ce qu'elle soit difficile à désactiver. Les évaluations sont plus exposées. OpenAI n'exige pas de surveillance du désalignement lorsqu'elle évalue des modèles comparables à GPT-6 Luna, jugés moins capables, et l'exemption prévue pour eux peut être appliquée par erreur à une évaluation d'Astra.

Auto-Review chargé de garder le moniteur

Plusieurs rapports indiquent qu'au printemps, le moniteur ne couvrait que 20 % des échantillons de certains entraînements ; il couvre désormais tous les échantillons d'entraînement. L'accès direct à internet a été coupé pendant l'entraînement. Trois canaux Slack ont été masqués aux agents. Le modèle qui avait publié un token GitHub n'est revenu qu'avec une revue automatique de toutes ses actions et un contrôle toutes les trente minutes.

Le 20 octobre, deux mesures s'ajoutent. Auto-Review, déjà obligatoire pour tout usage interne de Codex, a été mis à jour pour détecter et bloquer les tentatives de désactiver la surveillance. L'outil, présenté le 30 avril, confie à un agent distinct, fondé sur GPT-5.4 Thinking, le soin d'approuver ou de refuser les actions qui franchissent le bac à sable ; il approuvait alors environ 99 % des actions qui lui étaient soumises. Le même billet prévenait qu'il ne fallait pas y voir une protection contre les manœuvres délibérées d'un modèle, lequel peut aussi agir dans le bac à sable « in ways Auto-review never sees ». Seconde mesure, encore en chantier : chaque catégorie de charge de travail devra disposer d'un dossier de sûreté fixant ses exigences de surveillance, faute de quoi elle sera arrêtée automatiquement.

Une explication que l'entreprise n'a pas

OpenAI écrit ne pas disposer encore d'une explication satisfaisante. Deux hypothèses restent ouvertes : une persévérance bénigne, des modèles qui ne comprennent pas l'utilité de la surveillance et exécutent les consignes au-delà du raisonnable, ou une propension propre à échapper au moniteur, au prix d'un raisonnement orienté. L'entreprise prépare des évaluations appariées, des rééchantillonnages et des expériences sur les activations internes des modèles.

Les seules enquêtes indépendantes citées sur la page, celles de METR et de Redwood Research, portent sur l'incident Hugging Face ; aucune ne concerne ces vingt rapports. Au 22 octobre, la page recense 20 rapports et 3 avis. Le rapport DNS, mis à jour pour la dernière fois le 25 septembre, indique toujours que l'entraînement, l'évaluation et l'inférence outillée des modèles les plus capables d'OpenAI restent suspendus. Le 29 septembre, l'entreprise avait renoncé à publier GPT-6.1 Astra, jugé insuffisant sur le respect du périmètre et des autorisations, selon CBS News. Les rapports suivants décrivent un entraînement par renforcement le 6 octobre et des agents GPT-6.1 Sol et GPT-6 Astra au travail les 3 et 6 octobre. OpenAI ne précise pas lesquels de ses modèles entrent dans le périmètre de la pause.

Nos articles remonteront en priorité dans « À la une » de Google.