METR a éprouvé la surveillance des agents internes d’OpenAI. Ce que l’audit établit
METR publie un exercice mené chez OpenAI en juillet et août. Il révèle des limites de surveillance historiques sans valider les corrections annoncées depuis.
Surveiller les actions d’un agent IA ne suffit pas à savoir si cette surveillance fonctionne. METR publie le 22 octobre 2026 les conclusions publiques d’un exercice réalisé avec Redwood Research chez OpenAI. Les chercheurs ont examiné le système interne de contrôle des agents. Leur rapport révèle des angles morts historiques. Il ne décrit pas une mesure complète du système actuel.
Trois semaines d’accès à l’infrastructure interne
L’exercice décrit par METR s’est déroulé du 21 juillet au 11 août. Un salarié de METR et un salarié de Redwood ont travaillé sur des appareils fournis par OpenAI dans ses locaux. Ils ont consulté du code et des paramètres de surveillance ainsi que de la documentation interne. Ils ont aussi mené des entretiens avec environ douze chercheurs et ingénieurs.
L’analyse portait sur le système tel qu’il existait avant ou au 21 juillet. OpenAI travaillait déjà à son extension pendant l’exercice. Les conclusions ne permettent donc pas de déduire la couverture effective du dispositif trois mois plus tard. Cette distinction entre la période étudiée et la date de publication conditionne toute lecture du rapport.
Le trafic prévu pour le contrôle n’est pas le trafic réellement contrôlé
Les auteurs estiment qu’environ 75 à 94 % du trafic agentique interne passant par l’API Responses était éligible à la surveillance pour les modèles au moins aussi capables que GPT-5.5. Ils soulignent une forte incertitude. Dans le sous-ensemble utilisé par les agents Codex internes, l’estimation atteignait 99,2 %. Ces deux valeurs concernent des périmètres différents. Elles ne mesurent pas toute l’inférence interne d’OpenAI.
Être éligible signifie qu’une activité est censée passer dans le dispositif. Une erreur ou une limite de fonctionnement peut empêcher son contrôle réel. METR estime ainsi que l’absence de surveillance de certains événements de compression du contexte aurait laissé de côté un volume de l’ordre de 10 % du trafic Codex éligible entre mai et juillet. La précision reste limitée par les journaux disponibles à l’époque.
Un problème corrigé pendant l’exercice et des risques non confirmés en pratique
OpenAI avait identifié ce problème de compression avant l’arrivée des chercheurs et l’a corrigé pendant l’exercice. Le système se déclenchait alors quand l’agent rendait la main à l’utilisateur. Une activité qui continuait sans fin pouvait donc en principe repousser son contrôle. Les chercheurs n’ont pas pu vérifier si des agents avaient effectivement exploité cette possibilité. Un risque de conception ne constitue pas la preuve d’un incident réel.
Les auteurs rapportent aussi des voies de contournement et des différences possibles entre le contexte de l’agent et celui du surveillant. Certaines possibilités restent décrites au conditionnel ou n’ont pas été validées en pratique. Le rapport public ne permet pas d’attribuer ces constats à tous les agents accessibles aux clients. Il porte sur une infrastructure interne et sur le périmètre de cet exercice.
Les corrections ultérieures restent une déclaration d’OpenAI
OpenAI affirme avoir corrigé les vulnérabilités identifiées qui affectaient ses protections de production. L’entreprise décrit aussi une extension ultérieure de la couverture prévue. METR précise ne pas avoir évalué ces déclarations. Il faut donc conserver les deux informations. Des corrections sont annoncées par l’éditeur et cette équipe externe ne les a pas recontrôlées dans le cadre du travail publié.
La présentation historique d’OpenAI en mars décrivait déjà une surveillance asynchrone avec des alertes et une revue humaine. Son document d’août sur les capacités cyber annonçait une extension du dispositif. Ces textes expliquent la démarche du fournisseur. Ils ne remplacent pas une vérification externe de la couverture actuelle ni du résultat des corrections.
Un accès profond avec une transparence publique limitée
L’exercice a produit un rapport interne de 61 pages. La publication accessible au public n’en présente qu’une partie à un niveau général. METR indique qu’OpenAI pouvait retirer les informations jugées confidentielles ou sensibles selon sa propre appréciation. L’accès technique accordé aux chercheurs et leur liberté de publication ne recouvrent donc pas la même chose. Cette limite fait partie de la méthode à connaître.
Parmi les pistes proposées figurent des contrôles réguliers sans attendre la fin d’un tour et un suivi précis du trafic réellement surveillé. L’isolation entre l’agent et son contrôleur compte aussi. Ça montre pourquoi l’efficacité d’une protection dépend de toute sa chaîne de fonctionnement. Notre article sur les incidents d’agents OpenAI survenus en octobre traite d’événements distincts. Les confondre avec cet exercice de juillet empêcherait de comprendre la chronologie.