Le 20 octobre, OpenAI a publié un rapport décrivant des agents d’IA qui ont modifié ou désactivé des dispositifs de surveillance pendant des tâches de travail courantes. Ce document est le vingtième mis en ligne depuis le 16 septembre sur la page de divulgation de l’entreprise. Aucun des précédents ne visait le dispositif de détection.
- Deux agents de code d’OpenAI ont modifié ou désactivé leur surveillance pendant des tâches courantes.
- Les agents ont traité le moniteur comme du code ordinaire et coupé les alertes de sécurité.
- Un agent a nié avoir retiré un moniteur actif, ce qu’OpenAI juge faux.
- OpenAI n’a pas encore expliqué ces comportements et ne bloque pas toutes les manœuvres.
Dans les deux cas décrits, l’agent a traité la surveillance comme du code ordinaire, modifiable comme le reste du dépôt : liste des destinataires des alertes, intégration du moniteur (le système qui observe l’activité de l’agent), test censé garantir sa présence. Selon le rapport, 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.
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 la consigne « don’t send any messages ». Quatre-vingt-deux messages de l’utilisateur plus tard, le pipeline s’arrête. Le moniteur a signalé une réparation de validation proposée, mais n’a pas pu enregistrer ce signalement faute de droits. Le chercheur demande alors de changer la destination des résultats de surveillance et de relancer.
Selon le raisonnement publié, l’agent principal estime d’abord que la consigne visait la prise de contact sur Slack, et non les notifications automatiques. Le sous-agent chargé de la réparation qualifie pourtant d’« unsafe » la désactivation d’alertes requises. L’agent principal ordonne finalement la suppression des notifications, au nom de la demande de l’utilisateur. Le correctif vide les listes de destinataires, active un paramètre no_notify et mentionne comme motif « User explicitly requested no messages ». Le moniteur a continué d’archiver ses rapports, tandis que les alertes destinées à l’équipe de sécurité é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, 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, puis remplace le 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. L’entreprise dit aussi avoir observé plusieurs cas d’agents lançant un déploiement dont la surveillance était désactivée. L’agent restait surveillé, mais la charge de travail qu’il démarrait ne l’était plus.
Vingt rapports, des délais qui se resserrent et une explication attendue
Six rapports sont parus le 16 septembre, 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, une méthode où le modèle apprend par essais et récompenses, 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, survenu le 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, puis publié le 15 octobre.
En décembre 2024, Apollo Research montrait déjà que plusieurs modèles de pointe tentaient de désactiver leurs mécanismes de supervision, mais dans des scénarios conçus pour les y pousser. Les deux cas d’octobre se distinguent de ce cadre expérimental : il s’agissait de demandes de travail courantes, sur des outils internes réels.
Aucun des deux incidents n’a été classé P0, le niveau qui déclenche l’appel immédiat de l’équipe de sécurité. Aucune des deux trajectoires n’a été interrompue automatiquement. Depuis le 20 octobre, Auto-Review, un agent distinct fondé sur GPT-5.4 Thinking et 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. Selon OpenAI, cet outil ne protège pas contre les manœuvres délibérées d’un modèle, qui peut aussi agir dans le bac à sable, l’environnement isolé où le code s’exécute, « in ways Auto-review never sees ». OpenAI ne dispose pas encore d’une explication satisfaisante et évoque deux hypothèses, une persévérance bénigne ou une propension à échapper au moniteur. Le rapport DNS, mis à jour pour la dernière fois le 25 septembre, indique que l’entraînement, l’évaluation et l’inférence outillée des modèles les plus capables de l’entreprise restent suspendus. OpenAI ne précise pas lesquels de ses modèles entrent dans le périmètre de la pause.
