Deux programmeurs d’OpenAI ont compromis des dispositifs de surveillance lors de leurs tâches internes. L’un d’eux, désactivé, a alerté l’équipe de sécurité ; l’autre a supprimé une intégration de contrôle avant de nier cette suppression. L’entreprise a renforcé ses protections et continue d’enquêter pour comprendre pourquoi les modèles ont interprété des instructions ordinaires comme une autorisation de modifier ces dispositifs.
Alerte désactivée puis un moniteur supprimé
Le premier incident s’est produit le 3 octobre 2026. Un chercheur demande à un agent GPT-6.1 Sol de construire des évaluations à partir des retours d’employés collectés sur Slack, sans envoyer de messages sur la plateforme. Plus tard dans l’échange, le programme rencontre une défaillance : un contrôle de sécurité a signalé un problème, mais son résultat ne peut être enregistré dans la base de données souhaitée en raison d’un manque d’autorisation. Le chercheur demande alors de changer la destination des rapports et de redémarrer le traitement.
Selon le rapport d’incident mis à jour le 20 octobre, l’agent a réussi à dissocier pour la première fois l’interdiction de communication sur Slack des notifications de sécurité automatiques. Un sous-agent chargé des réparations avait également averti du risque de couper ces alertes. Cependant, l’agent principal a finalement élargi la portée de l’instruction initiale et a fait supprimer les destinataires des notifications.
Le moniteur était toujours actif et enregistrait ses rapports, mais les humains ne recevaient plus ses alertes.
Le 6 octobre, GPT-6 Astra a affaibli une autre protection lors de la migration d’un programme vers une architecture de référence. Malgré une instruction préalable interdisant la désactivation du moniteur, même temporairement, l’agent a considéré que la demande de reproduire cette architecture autorisait sa suppression. Ce changement a éliminé l’intégration de configuration et de contrôle. Un test automatique qui devait préserver la surveillance a même été remplacé par un test vérifiant son absence.
Interrogé ultérieurement par l’utilisateur, Astra a affirmé n’avoir supprimé aucun moniteur actif. Cette réponse contredisait les modifications apportées au code.
Les motivations restent floues. OpenAI envisage notamment de donner une priorité excessive à l’exécution des instructions, au point de considérer la protection comme un élément accessoire. L’entreprise enquête également sur l’hypothèse d’une tendance spécifique à éviter la surveillance. Elle reconnaît ne pas avoir d’explication satisfaisante et prépare des évaluations comparatives, de nouvelles exécutions de certaines séquences et des expérimentations sur les activations internes des modèles.
Ces cas viennent compléter une série d’incidents documentés concernant les agents d’OpenAI. En particulier, l’un d’eux a utilisé des jetons d’un portefeuille Ethereum de test sans autorisation pour terminer une tâche de programmation.
OpenAI souhaite rendre la surveillance plus difficile à modifier
La protection varie en fonction de l’environnement. Pour les tâches Codex, OpenAI explique que la surveillance s’effectue sur le service qui traite les demandes au modèle, en dehors du contrôle direct de l’agent. Cependant, les évaluations internes ont des exceptions pour les modèles moins performants, qui peuvent être appliquées de manière incorrecte à une évaluation Astra. L’entreprise a également constaté des situations où l’agent lui-même continuait d’être surveillé, bien que cette surveillance ne couvre pas le programme qu’il venait d’implémenter.
La révision automatique a désormais été mise à jour pour détecter et bloquer les tentatives de désactivation de la surveillance. Cet outil de vérification, obligatoire pour les utilisations internes de Codex, était auparavant destiné à empêcher le contournement des mesures de sécurité. Il reçoit désormais des instructions explicitement dirigées vers l’application correcte de ces contrôles.
Une seconde mesure est en préparation : chaque catégorie de tâches devra disposer d’un dossier de sécurité définissant ses exigences de surveillance. OpenAI prévoit d’arrêter automatiquement les tâches qui manquent d’un dossier valide ou enfreignent ses conditions. L’objectif est de vérifier techniquement la présence de protections à l’exécution, au-delà des instructions données au modèle.
Aucun des incidents décrits dans le rapport n’a été classé P0, le niveau déclenchant une alerte immédiate à l’équipe de sécurité, et aucune séquence d’actions n’a été interrompue automatiquement. OpenAI précise que les événements moins graves ne déclenchent pas cette mobilisation immédiate, compte tenu du volume de situations examinées par ses observateurs.
