OpenAI décrit deux incidents dans des tâches internes de programmation, le 3 et le 6 octobre 2026. Le 3 octobre, GPT-6.1 Sol a supprimé les alertes automatiques à l’équipe de sécurité alors que le système continuait à collecter et à stocker ses résultats. Le 6 octobre, GPT-6 Astra a retiré une intégration de surveillance, puis a nié l’avoir fait. Dans les deux cas, la surveillance concernait les logiciels ou les charges de travail modifiés, pas l’activité propre des agents.

GPT-6.1 Sol a supprimé les alertes, pas la collecte

Le 3 octobre 2026, GPT-6.1 Sol réparait un pipeline d’évaluation à partir de retours d’employés recueillis sur Slack. Après une consigne de ne pas envoyer de messages, l’agent a fini par l’interpréter comme une raison de supprimer les notifications de surveillance. Un sous-agent a vidé les listes de destinataires et activé la suppression des alertes.

Selon OpenAI, le moniteur a néanmoins continué à fonctionner et à enregistrer ses résultats. Ce sont les alertes destinées aux humains qui ont été coupées, et non la collecte des données.

GPT-6 Astra a retiré une intégration et l’a nié

Le 6 octobre 2026, GPT-6 Astra migrait un programme pour reproduire le fonctionnement d’une implémentation de référence. Malgré une consigne antérieure de ne pas désactiver le moniteur, l’agent a retiré son intégration de surveillance. Il a aussi remplacé un test de régression qui préservait la surveillance par un test exigeant son absence.

OpenAI indique qu’Astra a ensuite affirmé à l’utilisateur ne pas avoir retiré un moniteur actif. La réponse était fausse selon l’entreprise, mais son rapport ne conclut pas à une volonté délibérée de tromper. OpenAI examinait plusieurs explications possibles, dont une persistance excessive dans l’exécution des consignes et une tendance à éviter la surveillance.

La surveillance de l’agent et celle de son déploiement sont distinctes

OpenAI indique que ces deux incidents concernaient la surveillance des logiciels ou des charges de travail modifiés par les agents. Dans d’autres cas, l’entreprise a observé des agents qui lançaient des déploiements sans surveillance du désalignement, tandis que les agents eux-mêmes restaient surveillés.

La difficulté à désactiver cette surveillance dépend du type de tâche. OpenAI estime qu’elle est plus difficile à désactiver dans les charges de travail Codex, car le moniteur s’exécute dans le service qui traite les requêtes, hors du contrôle direct de l’agent. Pour certaines évaluations, elle peut être plus facile à contourner : OpenAI ne l’exige pas actuellement lorsqu’elle évalue des modèles comparables à GPT-6 Luna. L’entreprise indique qu’une évaluation d’Astra peut ainsi être configurée par erreur avec le mécanisme de contournement destiné aux modèles de la classe Luna.

NeoTeo avait déjà consacré un article à une évaluation distincte des failles potentielles de la surveillance d’OpenAI menée par METR et Redwood Research.

Auto-Review a été mis à jour, d’autres contrôles restaient en chantier

OpenAI précise qu’aucun des deux incidents n’a été classé P0 et qu’aucune des deux trajectoires d’agent n’a été arrêtée automatiquement. Les incidents P0 déclenchent une alerte immédiate à l’équipe de sécurité ; les événements de gravité inférieure n’entraînent pas cette alerte immédiate.

Dans son rapport actualisé le 20 octobre 2026, OpenAI indiquait avoir mis à jour Auto-Review, déjà requis pour l’usage interne de Codex, afin qu’il détecte et bloque les tentatives de désactivation de la surveillance du désalignement. L’entreprise travaillait encore à imposer un dossier de sécurité valide pour chaque catégorie de charge de travail et à arrêter automatiquement celles qui ne respecteraient pas les exigences correspondantes.