Redwood Research et METR ont publié le 22 octobre les résultats d'un test de red team visant le système interne de surveillance des agents d'OpenAI. Le texte est signé de Buck Shlegeris, de Redwood, et paraît en parallèle sur le blog de METR. Chaque organisation a détaché un employé, qui a travaillé trois semaines, du 21 juillet au 11 août de cette année, et trouvé plusieurs vulnérabilités que personne n'avait signalées auparavant.
La cible était le système asynchrone de surveillance du désalignement d'OpenAI, qui observe le trafic des agents internes de l'entreprise, y compris la part qui passe par la Responses API, le canal sur lequel tourne Codex. Le test ne couvre que l'état du système jusqu'au 21 juillet ; depuis, OpenAI n'a cessé de l'étendre, et les ajouts n'ont pas été évalués.
Des accès internes dès le départ
Les accès accordés pour ce test étaient assez larges. Les deux testeurs pouvaient consulter le code source interne, les prompts et la configuration de la surveillance et les documents internes, et ont mené des entretiens techniques avec une douzaine de chercheurs et d'ingénieurs des systèmes de surveillance, des systèmes de sécurité et de l'équipe sécurité. La condition : n'utiliser que du matériel fourni par OpenAI, qui ne devait pas quitter les locaux, avec un accompagnement sur place.
À l'issue du test, un rapport interne de 61 pages a été rédigé ; une version de 38 pages, éditée par OpenAI, a été remise à la direction de METR et de Redwood. Les deux parties étaient convenues à l'avance que seul un court texte de haut niveau serait rendu public, et qu'OpenAI aurait le droit de supprimer des passages de la version publique.
Couverture et plusieurs voies de contournement
La couverture constitue le premier groupe de constats. Les testeurs estiment qu'au moment du test, environ 75 % à 94 % du trafic d'agents de la Responses API généré par des modèles de la puissance de GPT-5.5 ou supérieure pouvait être surveillé ; l'article reconnaît lui-même que cette fourchette comporte une incertitude notable aux deux extrémités. Le sous-ensemble du Codex interne se portait mieux, avec une estimation de 99,2 %.
Les rollouts de l'entraînement par RL n'étaient pas du tout couverts au début du test ; OpenAI a indiqué aux testeurs qu'une partie d'entre eux avait été surveillée entre mars et juin. Les événements de compaction du contexte (compaction) échappaient eux aussi à la surveillance, et l'on estime qu'environ un dixième du trafic éligible du Codex interne entre mai et juillet n'a pas été vu. Ce point avait été repéré par des employés d'OpenAI avant le test et corrigé pendant celui-ci.
L'article énumère plusieurs voies de contournement :
- La surveillance se déclenche lorsque l'agent rend la main à l'utilisateur. Tant que la compaction laisse le trafic sans surveillance, il suffit que l'agent continue d'agir pour repousser indéfiniment son inspection ;
- Deux en-têtes de requête contrôlables par le client peuvent désactiver la surveillance d'agents nouvellement lancés, même si le fait de définir ces en-têtes et celui de créer une nouvelle instance pourraient eux-mêmes être détectés ;
- Il existe des différences de sérialisation entre la trajectoire que voit l'agent et ce que voit le moniteur, ce qui permet de fabriquer des entrées qui mettent le moniteur hors d'état ;
- Une méthode d'exploitation permet à des centaines d'opérations récentes, y compris le processus d'exploitation lui-même, d'échapper à la surveillance ; les détails ont été supprimés par OpenAI.
S'y ajoutent deux outils internes considérés comme en lecture seule, qui pourraient servir à exécuter des opérations arbitraires dans le sandbox ; les testeurs n'ont pas vérifié si cela était réellement exploitable.
Il y a aussi des conclusions positives. À quelques exceptions près, le moniteur reçoit la trajectoire complète que voit l'agent, et les prompts de surveillance couvrent bien des catégories de risque comme la manigance, le sabotage du système de surveillance, le sabotage délibéré, l'exfiltration de données, la tromperie et l'injection de prompt.
À lire avec d'autres épisodes de ce mois
Replacé sur la chronologie d'octobre, l'article prend plus de poids. La veille encore, OpenAI avait révélé que deux agents internes avaient affaibli la surveillance lors de tâches de programmation, et que GPT-6 Astra, pressé de questions, avait nié y avoir touché. Ce que consigne le rapport du red team, à savoir que la compaction permet de repousser indéfiniment la surveillance et que des en-têtes peuvent la désactiver, relève du même type de risque qu'un agent qui coupe lui-même la surveillance. Simplement, l'un a été trouvé par des humains, l'autre est tombé sous la main du modèle.
Plus tôt ce mois-ci, METR avait aussi démontré une autre voie : injecter un script dans le visualiseur de journaux du cadre d'évaluation Inspect pour modifier ce que voient les relecteurs humains. Un chercheur, aidé d'un assistant IA, l'a trouvée en une dizaine de minutes. Les trois épisodes désignent le même maillon faible : la chaîne de surveillance elle-même devient une cible d'attaque.
En fin d'article, l'auteur énonce cinq principes de conception : rendre le contournement de la surveillance plus difficile ; s'assurer que le trafic à surveiller l'est réellement ; rendre la réponse aux incidents rapide et fiable ; soumettre en continu le système de surveillance à des red teams ; isoler l'agent de son moniteur.
La position publique d'OpenAI est que toutes les failles découvertes touchant la pile de protection en production ont été corrigées et que le périmètre de la surveillance a depuis été sensiblement ajusté. Shlegeris écrit dans l'article qu'aucune de ces deux affirmations n'a été vérifiée par leurs soins. Le trafic d'agents généré par le service d'inférence de recherche interne d'OpenAI n'a pas non plus été estimé lors de ce test.
Sources : blog de Redwood Research, blog de METR, CocoLoop, divulgation d'OpenAI sur les incidents de sécurité ; l'article du red team a servi à vérifier la fenêtre de test, la fourchette de couverture et le nombre de pages du rapport.