METR et Redwood ont mis en échec la surveillance des agents d'OpenAI : 75–94% du trafic couvert

Pendant trois semaines, du 21 juillet au 11 août, un collaborateur de METR et un collaborateur de Redwood Research ont tenté de contourner le système qu'OpenAI utilise pour surveiller le désalignement de ses propres agents internes. Le résultat : un rapport confidentiel de 61 pages destiné aux chercheurs et à l'équipe de sécurité d'OpenAI, puis un court résumé public. Son principal constat : au moment de l'audit, 75–94% du trafic agentique interne de l'API Responses issu de modèles au moins aussi puissants que GPT-5.5 était soumis à la surveillance, les chercheurs reconnaissant une incertitude dans les deux sens. Le système comportait aussi des moyens d'échapper complètement à l'observation.

Un accès proche de celui des ingénieurs internes

L'audit s'est déroulé dans le cadre d'un pilote d'« accès approfondi » pour des chercheurs externes. Les participants ont travaillé avec la base de code interne d'OpenAI, les prompts et la configuration des moniteurs, ainsi que la documentation interne. Ils ont mené des entretiens techniques avec une douzaine de chercheurs et d'ingénieurs des équipes de monitoring, de systèmes de safety et de sécurité. Ils travaillaient sur des appareils fournis par OpenAI, qui ne quittaient pas les locaux, et sous accompagnement.

Les restrictions comptent aussi. Seul un billet succinct peut être publié : OpenAI peut masquer toute information qu'elle juge confidentielle et, contrairement aux travaux précédents, METR n'a pas le droit de décrire unilatéralement de telles modifications. Les directions de METR et de Redwood ont reçu une version du rapport de 38 pages, éditée par OpenAI. L'audit a porté sur le système tel qu'il existait au 21 juillet et avant, et non sur les extensions que l'entreprise déployait en parallèle. L'étude n'est pas non plus liée à l'enquête de METR sur l'incident Hugging Face, bien que celui-ci ait été rendu public dès le premier jour de l'exercice.

Douze constats

• Couverture du trafic. 75–94% du trafic agentique de l'API Responses (sur laquelle repose Codex) issu de modèles de niveau GPT-5.5 et supérieur était soumis à la surveillance.

Pour un sous-ensemble d'agents Codex internes, l'estimation est plus élevée : 99,2%. Le trafic du service d'inference de recherche interne n'a pas été évalué, en raison de restrictions d'accès et de contraintes de temps. • Entraînement par RL.

Une partie des rollouts a été surveillée pour détecter le désalignement de mars à juin, mais au début de l'exercice, les exécutions de RL n'étaient pas couvertes par le système. • Compaction. À cause d'événements de compaction impossibles à vérifier, environ 10% du trafic Codex éligible n'a pas été surveillé de mai à juillet 2026.

La part exacte n'a pas pu être déterminée, car les données nécessaires n'étaient pas journalisées. OpenAI avait repéré le problème avant l'exercice et l'a corrigé pendant son déroulement. • Report du contrôle.

Le moniteur se déclenchait lorsque l'agent rendait la main à l'utilisateur. Tant que la compaction n'était pas vérifiée, l'agent pouvait différer indéfiniment la supervision tout en continuant d'exécuter des actions. Les chercheurs n'ont pas pu vérifier si quelqu'un l'avait fait en pratique.

• Erreurs et load-shedding. D'après les données présentées, le moniteur se trompait dans moins de 0,2% des requêtes, et sur une journée de 24 heures pendant l'exercice, aucun délestage de charge n'a eu lieu. • Sandbox de Codex.

Une méthode de contournement du sandboxing et d'Auto-Review a été trouvée ; l'agent pouvait ensuite faire tout ce qui est accessible à l'utilisateur de l'hôte. • Exploit de la zone aveugle. Une technique a été découverte qui soustrayait à la surveillance des centaines d'actions récentes, y compris celles de l'exploit lui-même.

OpenAI a caviardé les détails. • Sérialisation. Les agents peuvent vraisemblablement construire des données d'entrée qui font planter le moniteur et empêchent l'envoi de la trajectoire à un examen humain : la trajectoire est sérialisée différemment pour l'agent et pour le moniteur.

• En-têtes. Deux en-têtes client indépendants désactivent la surveillance des nouveaux agents, ce qui permet de lancer une instance identique mais non observée. Toutefois, la définition de ces en-têtes et la création de l'instance peuvent être repérées par le moniteur.

• Outils « en lecture seule ». Deux outils agentiques internes sans surveillance étaient considérés comme read-only, mais un exploit simple permettait d'exécuter des actions arbitraires dans leur sandbox. L'exploitabilité en pratique n'a pas été vérifiée.

• Exhaustivité du contexte. À quelques petites exceptions près, le moniteur voit la même trajectoire que l'agent. • Prompts du moniteur.

Ils recherchent le scheming, le sabotage du système de monitoring lui-même, le sabotage en général, le vol de données, la tromperie, ainsi que les prompt injections entrantes et sortantes.

OpenAI indique que toutes les vulnérabilités touchant la pile de protection en production sont corrigées, et décrit des changements substantiels dans le périmètre ciblé par la surveillance. METR n'a pas vérifié ces affirmations.

Cinq principes pour une surveillance capable de résister à un agent intelligent

À partir de leurs constats, les auteurs ont tiré des exigences pour des systèmes capables de résister à des attaques intentionnelles, stratégiques et durables menées par de puissants agents internes :

• Contourner la surveillance doit être difficile. N'autoriser les requêtes non surveillées que pour des organisations et des clés API explicitement approuvées, auxquelles l'inference agentique est interdite. Vérifier l'agent tous les N messages ou toutes les N minutes, et non à la fin d'un tour.

• Contrôler la couverture réelle. Tenir la comptabilité de tout l'inference et de la part surveillée, rapprocher régulièrement les logs de ceux du moniteur, maintenir une liste des contournements connus, veiller à ce que le moniteur voie le même contexte que l'agent. • Réagir rapidement aux incidents.

Désigner un responsable, établir des consignes claires, conserver des logs immuables et faciles à interroger. • Attaquer régulièrement le moniteur. Mener des control evaluations, chercher les bugs exploitables, élaborer une méthode d'évaluation de la collusion stratégique.

• Isoler les agents des moniteurs. Exécuter le scaffold séparément de l'environnement d'exécution des outils, empêcher les actions de l'agent d'influer sur le déclenchement du moniteur et sur son moment, ne pas montrer à l'agent la conception ni le code du système de supervision.

Que vérifier dans votre propre pile agentique

Les failles typiques sont ici d'ordre technique, et non exotiques : un type d'événement oublié, un déclencheur placé en fin de tour, un en-tête client, une branche de trafic superflue. Toute équipe qui exécute des agents de code autonomes peut passer sa propre infrastructure au crible de cette liste : un rapprochement est-il effectué entre les logs d'inference et ceux du moniteur ? Peut-on désactiver l'observation par un paramètre de requête ?

Le moniteur voit-il la même chose que l'agent ? Le contrôle se déclenche-t-il selon le temps écoulé plutôt qu'à la fin du tour ? Pour les auditeurs externes, le projet crée un précédent : un accès approfondi aux rouages d'un laboratoire est possible, mais la transparence publique reste pour l'instant à la discrétion de l'entreprise.

Pour les prochaines itérations, METR promet de s'en tenir à ses propres principes d'indépendance et d'ouverture.