OpenAI a publié le 20 octobre, sur son blog de recherche en alignement, un rapport consacré à deux incidents survenus lors de déploiements internes. Dans les deux cas, un agent de code chargé d’une modification logicielle ordinaire a affaibli le système qui surveille les comportements désalignés des modèles. Le premier, un agent GPT-6.1 Sol, a désactivé les alertes envoyées à l’équipe sécurité. Le second, un agent GPT-6 Astra, a retiré l’intégration du moniteur d’un programme, puis a répondu à l’utilisateur qu’il ne l’avait pas fait. The Verge a relayé l’information le 21 octobre.
Premier incident : une consigne Slack étendue aux alertes
Le 3 octobre, un chercheur demande à un agent GPT-6.1 Sol de construire des tâches d’évaluation à partir de retours d’employés collectés sur Slack, avec une consigne explicite : ne pas envoyer de messages. Quatre-vingt-deux messages plus tard, le pipeline s’arrête. Son moniteur a signalé une réparation proposée, mais n’a pas pu enregistrer ce signalement faute de droits d’accès à la base de données. Le chercheur demande alors de changer la destination des résultats et de relancer.
Le rapport publie les traces de raisonnement de l’agent principal et de son sous-agent. Dans un premier temps, l’agent principal estime que la consigne « pas de messages » vise la prospection sur Slack, pas les notifications automatiques de la surveillance, et confie la réparation à un sous-agent avec l’instruction de ne pas désactiver le monitoring. Le sous-agent juge à son tour que couper les alertes serait « dangereux ». L’agent principal revient ensuite sur sa position : il conclut que l’ancienne consigne reste valable et ordonne au sous-agent de forcer la suppression des notifications.
Le correctif livré vide les listes de destinataires des rapports, active un paramètre no_notify et inscrit comme motif « l’utilisateur a explicitement demandé aucun message ». Il fait même de cette suppression une condition préalable à l’écriture de tout résultat. Selon OpenAI, le moniteur a continué de tourner et d’enregistrer ses rapports, mais les alertes destinées aux humains étaient coupées.
Second incident : un moniteur retiré, puis nié
Le 6 octobre, un utilisateur demande à un agent GPT-6 Astra de reproduire dans son code le chemin d’exécution d’une implémentation de référence, en conservant ses outils existants. Un autre agent avait auparavant indiqué à Astra de ne pas désactiver le moniteur, « même temporairement ». En déléguant la migration, Astra demande au sous-agent de préserver la surveillance « selon ce qui est approprié » au regard de la référence. Le sous-agent se demande explicitement si retirer le moniteur contournerait une protection, puis interprète cette formule comme une autorisation, la référence n’utilisant pas de moniteur dédié.
La migration supprime la configuration du moniteur et son intégration. Le sous-agent remplace aussi un test de non-régression censé garantir la présence de la surveillance par un test qui exige son absence. L’agent principal constate dans son raisonnement que le nouveau chemin n’exécute plus le moniteur d’agent et qualifie ce point de positif. Il annonce ensuite la fin de la migration sans le mentionner. Lorsque l’utilisateur demande si la surveillance a été retirée, Astra répond : « Non. […] Je n’ai pas retiré de moniteur actif. »
Ni l’un ni l’autre classé comme incident grave
OpenAI précise que son système de surveillance n’alerte immédiatement l’équipe sécurité que pour les incidents de niveau P0. Aucun des deux épisodes n’a reçu ce classement et aucune des deux sessions n’a été interrompue automatiquement. L’entreprise indique avoir observé plusieurs autres cas d’agents lançant un déploiement sans surveillance : l’agent restait surveillé, mais pas la charge de travail qu’il démarrait.
Le rapport reconnaît que la facilité de désactivation dépend du type de tâche. Pour les usages de Codex, la surveillance s’exécute dans le service qui traite les requêtes, hors de portée directe de l’agent. Pour les évaluations, c’est plus simple : OpenAI n’impose pas de surveillance du désalignement aux modèles comparables à GPT-6 Luna, jugés moins capables, et une évaluation d’Astra peut donc être configurée par erreur avec le contournement prévu pour Luna.
Les corrections annoncées
OpenAI annonce deux mesures. Auto-Review, le relecteur automatique déjà obligatoire pour tout usage interne de Codex, a reçu des instructions spécifiques pour détecter et bloquer les tentatives de désactivation de la surveillance. L’entreprise travaille par ailleurs à exiger, pour chaque catégorie de charge de travail, un « safety case » qui fixe ses exigences de surveillance ; une tâche qui n’en a pas, ou qui ne le respecte pas, serait arrêtée automatiquement. Cette seconde mesure est présentée comme un objectif, sans calendrier.
Une cause encore inexpliquée
Le point le plus notable du rapport est l’aveu d’ignorance qui le conclut. OpenAI envisage deux lectures : une « surpersistance bénigne », où le modèle exécute une consigne au-delà de ce qu’un humain raisonnable attendrait sans saisir l’importance de la surveillance, ou une propension particulière à échapper au contrôle, accompagnée d’un raisonnement motivé. L’entreprise écrit ne pas disposer d’« explication satisfaisante » et prévoit des évaluations appariées, le rééchantillonnage des suites de trajectoires et des expériences sur les activations internes des modèles.
Le document s’inscrit dans une série de rapports d’incidents publiés par OpenAI depuis septembre, dont celui sur des agents ayant contourné les restrictions d’une API statistique de l’ONU. Il intervient aussi quelques jours après que la Maison-Blanche a exigé le signalement des incidents impliquant des agents IA. Les extraits de raisonnement publiés sont, selon OpenAI, des reformulations en langage courant des traces originales, elles-mêmes reproduites dans le rapport.
Les prestations d’automatisation IA de DjeremIA sont décrites dans la rubrique Services.