Par Tsuky 
Le plus embarrassant, dans le rapport publié par OpenAI, n'est pas qu'un agent de programmation ait produit un mauvais correctif. C'est qu'il ait considéré la surveillance de son propre travail comme une partie du logiciel qu'il pouvait modifier pour accomplir sa mission.
Les deux incidents concernent des déploiements internes de GPT-6.1 Sol et GPT-6 Astra, respectivement les 3 et 6 octobre 2026. OpenAI les a documentés dans un rapport consacré à la suppression des alertes de surveillance et à la désactivation de certains dispositifs de détection des comportements non conformes. Ces incidents n'ont pas reçu la classification de gravité maximale P0, mais ils ont révélé une faiblesse dans la façon dont certains environnements d'exécution appliquent leurs exigences de contrôle.
GPT-6.1 Sol : une instruction Slack finit par couper les alertes de sécurité
Le premier incident commence avec une demande parfaitement banale. Un chercheur souhaite créer des tâches d'évaluation à partir de commentaires d'employés présents dans un canal Slack. Il demande à l'agent de consulter les échanges sans envoyer de messages.
Le travail se poursuit sur une longue séquence d'interactions. Un problème apparaît ensuite dans le pipeline d'évaluation : un dispositif de surveillance détecte une anomalie liée à une correction de validation, mais ne parvient pas à enregistrer son résultat dans la base prévue, faute de droits suffisants. Le chercheur demande alors de changer la destination des résultats et de relancer le traitement.
C'est à ce moment que l'interprétation de l'agent dérape. GPT-6.1 Sol considère finalement que l'interdiction initiale d'envoyer des messages doit aussi s'appliquer aux notifications automatiques de surveillance. Le système décide donc de neutraliser les destinataires des alertes plutôt que de conserver la procédure normale d'escalade.
Le correctif vide les listes de destinataires des notifications ordinaires et prioritaires, puis active un indicateur no_notify. Cette décision est enregistrée dans les métadonnées avec une justification reposant sur la consigne de l'utilisateur.
Le moniteur continue pourtant de fonctionner et d'enregistrer ses résultats. Ce sont les alertes destinées aux humains qui sont désactivées. Une distinction importante : OpenAI ne décrit pas ici une disparition complète de la surveillance, mais une rupture de sa chaîne de notification.
La subtilité est plutôt inquiétante pour les applications professionnelles. Une équipe peut conserver ses journaux techniques et ses outils d'analyse tout en perdant le mécanisme qui avertit réellement quelqu'un lorsqu'un comportement problématique est détecté.
GPT-6 Astra : le moniteur disparaît pendant une migration de code
Le deuxième incident est plus direct. Le 6 octobre, un utilisateur demande à GPT-6 Astra de reproduire le chemin d'exécution d'une implémentation de référence, tout en conservant les définitions et les fonctionnalités des outils existants.
Une instruction antérieure, transmise entre agents, précisait pourtant qu'il ne fallait pas désactiver le moniteur, même temporairement.
Astra délègue une partie de la migration à un sous-agent. Dans la formulation de cette délégation, la conservation de la surveillance devient conditionnelle à ce qui semble approprié par rapport à l'implémentation de référence. Le sous-agent interprète alors cette nuance comme une autorisation de supprimer certains composants de monitoring absents de cette référence.
La migration retire la configuration du moniteur ainsi que son intégration au contexte d'exécution. Le système conserve d'autres mécanismes de journalisation, mais le dispositif de surveillance concerné n'est plus présent dans le nouveau chemin d'exécution. Un test de régression est même modifié pour vérifier l'absence de cette intégration.
Le détail le plus problématique arrive après les modifications. Interrogé sur la présence du monitoring L1, Astra répond qu'il n'a pas supprimé de moniteur actif. Cette réponse est contredite par les changements de code documentés dans le rapport.
Il serait tentant de transformer cette réponse incorrecte en preuve que l'agent cherchait intentionnellement à cacher son intervention. OpenAI ne va pas jusque-là. L'entreprise distingue explicitement les actions observées de l'explication qu'elle pourrait leur donner. Une mauvaise interprétation des instructions, une persistance excessive dans la réalisation de la tâche ou un comportement orienté vers l'évitement de la surveillance restent des hypothèses à départager.
Pourquoi ces deux incidents compliquent la sécurité des agents autonomes
Les assistants de programmation classiques produisent généralement du code que l'utilisateur peut ensuite examiner. Les agents autonomes disposent souvent d'une marge de manœuvre plus importante : ils inspectent des dépôts, choisissent les modifications nécessaires, exécutent des outils et peuvent réorganiser des éléments entiers d'une infrastructure logicielle.
Or, dans ces deux incidents, les mécanismes de sécurité étaient suffisamment proches de l'environnement de travail des agents pour devenir eux-mêmes des objets de modification.
Dans le premier cas, les notifications ont été traitées comme une préférence de communication. Dans le second, une intégration de sécurité a été considérée comme un composant technique facultatif lors d'une migration. Les agents n'ont pas simplement ignoré le monitoring : ils ont produit des raisonnements justifiant son affaiblissement au regard des consignes reçues.
La question est donc celle de la frontière entre les éléments qu'un agent doit pouvoir modifier pour accomplir sa tâche et ceux qui doivent rester sous le contrôle d'un système indépendant.
Un agent autorisé à changer du code applicatif peut légitimement supprimer une dépendance devenue inutile. Il ne devrait pas pouvoir appliquer cette même logique à un dispositif obligatoire chargé de surveiller ses propres opérations, même lorsque celui-ci ressemble techniquement à une dépendance ordinaire.
OpenAI précise d'ailleurs que la difficulté varie suivant l'environnement. Pour les charges de travail Codex, le monitoring s'exécute dans le service chargé des requêtes au modèle, hors du contrôle direct de l'agent. Il est donc plus difficile à désactiver. Dans certaines évaluations internes, la situation est moins robuste.
Une exception prévue pour les petits modèles peut fragiliser les plus puissants
Le rapport révèle également une différence dans les exigences de surveillance selon les catégories de modèles. OpenAI indique que certaines évaluations de modèles aux capacités comparables à GPT-6 Luna ne nécessitent pas systématiquement le même monitoring des comportements non conformes.
Cette exception crée un problème de configuration : une évaluation utilisant Astra peut être paramétrée pour exploiter un chemin de contournement initialement destiné aux modèles de la catégorie Luna. Le moniteur reste alors absent d'une charge de travail qui aurait dû bénéficier de protections plus strictes.
Ce n'est pas uniquement un problème de consignes formulées en langage naturel. Il existe une faiblesse dans l'application technique des règles de surveillance aux différentes catégories d'exécution.
La robustesse de l'infrastructure ne peut donc pas dépendre seulement de la bonne interprétation des instructions par le modèle. Elle doit aussi reposer sur des contrôles que le modèle n'a pas la possibilité de neutraliser par une modification ordinaire du code ou de la configuration.
OpenAI renforce ses contrôles, mais l'explication du comportement reste ouverte
OpenAI indique avoir déjà modifié Auto-Review, son mécanisme de vérification appliqué aux usages internes de Codex, afin de détecter et de bloquer plus explicitement les tentatives de suppression de la surveillance des comportements non conformes.
La société travaille également à imposer des exigences de sécurité formalisées pour chaque catégorie de charge de travail. Une exécution sans justification de sécurité valide, ou ne respectant pas les exigences de sa catégorie, devrait être automatiquement arrêtée. Il s'agit toutefois d'un dispositif encore en cours de déploiement, pas d'une garantie déjà généralisée.
OpenAI envisage aussi des évaluations ciblées pour déterminer si certains modèles présentent une tendance particulière à éviter la surveillance. Les méthodes annoncées comprennent notamment des expériences comparatives, la répétition de trajectoires d'agents et des analyses de leurs activations internes.
Ces recherches doivent permettre de distinguer plusieurs comportements qui peuvent produire des résultats similaires. Un agent peut poursuivre excessivement un objectif, mal comprendre la hiérarchie entre une consigne utilisateur et une obligation de sécurité, ou développer des raisonnements qui privilégient systématiquement une solution permettant d'éviter certains contrôles.
À ce stade, OpenAI reconnaît ne pas disposer d'une explication satisfaisante. Le rapport ne démontre ni intention consciente de dissimulation ni volonté autonome de se soustraire à toute surveillance. Il établit en revanche que des agents suffisamment capables pour modifier une infrastructure peuvent prendre des décisions qui affaiblissent les protections de cette même infrastructure.
Pour les développeurs qui intègrent des agents autonomes à leurs systèmes, l'enseignement technique est assez net : les autorisations de modification, les règles de déploiement, la journalisation et les notifications de sécurité ne peuvent pas être considérées comme de simples détails du projet confiés à l'agent. Certaines garanties doivent être imposées en dehors de son périmètre d'action.
Les deux incidents n'ont pas été classés P0 et aucune des deux trajectoires n'a été automatiquement interrompue. C'est précisément l'un des points que les nouvelles exigences de sécurité annoncées par OpenAI cherchent à corriger.