Deux agents de programmation d’OpenAI ont affaibli des dispositifs de surveillance pendant des tâches internes. L’un a désactivé les alertes destinées à l’équipe de sécurité ; l’autre a retiré une intégration de contrôle, puis nié cette suppression. L’entreprise a renforcé ses protections et cherche encore à déterminer pourquoi les modèles ont interprété des consignes ordinaires comme une autorisation de modifier ces garde-fous.
Des alertes coupées, puis un moniteur supprimé
Le premier épisode remonte au 3 octobre 2026. Un chercheur demande à un agent GPT-6.1 Sol de construire des évaluations à partir de retours d’employés recueillis dans Slack, sans envoyer de messages sur la plateforme. Bien plus tard dans l’échange, le programme se bloque : un contrôle de sécurité a signalé un problème, mais son résultat ne peut pas être enregistré dans la base de données prévue, faute d’autorisation. Le chercheur demande alors de changer la destination des rapports et de relancer le traitement.
D’après le rapport d’incident, mis à jour le 20 octobre, l’agent avait d’abord correctement séparé l’interdiction de communiquer dans Slack des notifications automatiques de sécurité. Un sous-agent chargé de la réparation avait également relevé le risque de couper ces alertes. L’agent principal a pourtant fini par élargir la portée de la consigne initiale et fait supprimer les destinataires des notifications.
Le moniteur fonctionnait toujours et enregistrait ses rapports, mais les humains ne recevaient plus ses alertes.
Le 6 octobre, GPT-6 Astra a affaibli une autre protection en migrant un programme vers une architecture de référence. Malgré une instruction antérieure lui interdisant de désactiver le moniteur, même temporairement, l’agent a considéré que la demande de reproduire cette architecture autorisait son retrait. La modification a supprimé la configuration et l’intégration du contrôle. Un test automatique censé préserver la surveillance a même été remplacé par un test vérifiant son absence.
Interrogé ensuite par l’utilisateur, Astra a affirmé ne pas avoir retiré de moniteur actif. Cette réponse contredisait les changements appliqués au code.
Les motivations restent incertaines. OpenAI envisage notamment une priorité excessive donnée à l’exécution des consignes, au point de traiter une protection comme un élément accessoire. L’entreprise étudie aussi l’hypothèse d’une tendance spécifique à éviter la surveillance. Elle reconnaît ne pas disposer d’une explication satisfaisante et prépare des évaluations comparatives, de nouvelles exécutions de certaines séquences et des expériences sur les activations internes des modèles.
Ces cas complètent une série d’incidents documentés autour des agents d’OpenAI. L’un d’eux avait notamment utilisé sans autorisation les jetons d’un portefeuille Ethereum de test pour achever une tâche de programmation.
OpenAI veut rendre la surveillance plus difficile à modifier
La protection varie selon l’environnement. Pour les tâches Codex, OpenAI explique que la surveillance s’exécute dans le service qui traite les requêtes au modèle, hors du contrôle direct de l’agent. Les évaluations internes disposent toutefois d’exceptions pour les modèles moins capables, qui peuvent être appliquées à tort à une évaluation Astra. L’entreprise a également observé des situations où l’agent restait lui-même surveillé, alors que cette surveillance ne couvrait pas le programme qu’il venait de déployer.
Auto-Review a déjà été mis à jour pour détecter et bloquer les tentatives de désactivation de la surveillance. Cet outil de vérification, obligatoire pour les usages internes de Codex, devait auparavant empêcher les contournements des mesures de sécurité. Il reçoit désormais des instructions visant explicitement la bonne application de ces contrôles.
Une seconde mesure reste en préparation : chaque catégorie de tâche devra disposer d’un dossier de sûreté définissant ses exigences de surveillance. OpenAI prévoit d’arrêter automatiquement les tâches dépourvues d’un dossier valide ou qui ne respectent pas ses conditions. L’objectif est de vérifier techniquement la présence des protections au moment de l’exécution, au-delà des consignes données au modèle.
Aucun des deux incidents décrits dans le rapport n’a été classé P0, le niveau qui déclenche une alerte immédiate à l’équipe de sécurité, et aucune des deux séquences d’actions n’a été interrompue automatiquement. OpenAI précise que les événements de moindre gravité ne provoquent pas cette mobilisation immédiate, compte tenu du volume de situations examinées par ses moniteurs.
