L’équipe rouge de METR découvre des vulnérabilités dans le système de surveillance d’OpenAI

Le 22 octobre 2026, METR et Redwood Research ont publié un compte rendu public d’un exercice pilote au cours duquel un employé de chaque organisation a passé trois semaines à bénéficier d’un accès approfondi à l’infrastructure interne d’OpenAI et à mettre à l’épreuve le système interne de surveillance du désalignement de l’entreprise. Les évaluateurs ont indiqué avoir découvert plusieurs vulnérabilités inédites dans le système tel qu’il existait au 21 juillet 2026 et avant cette date.

L’exercice s’est déroulé du 21 juillet au 11 août 2026. Il visait principalement à estimer la part de l’inférence agentique faisant l’objet d’une surveillance et à déterminer si les agents pouvaient, en principe, désactiver ou détourner le système de surveillance. Il a donné lieu à un rapport interne de 61 pages, communiqué aux chercheurs et au personnel de sécurité d’OpenAI ; une version de 38 pages expurgée par OpenAI a été transmise aux équipes dirigeantes de METR et de Redwood Research.

Un accès approfondi dans un cadre contrôlé

Les deux évaluateurs ont eu accès au code source interne d’OpenAI, aux invites du système de surveillance du désalignement et à ses détails de configuration, ainsi qu’à la documentation interne. Ils ont également mené des entretiens techniques avec une douzaine environ de chercheurs et d’ingénieurs des équipes chargées de la surveillance, des systèmes de sécurité et de la sécurité informatique. Pour bénéficier de ce niveau d’accès, ils ont travaillé sur des appareils fournis par OpenAI, qui ne quittaient jamais les locaux, et étaient accompagnés lorsqu’ils s’y trouvaient.

METR, Redwood Research et OpenAI ont conçu cet exercice comme un projet pilote visant à donner à des chercheurs externes un accès approfondi à l’infrastructure interne, et non comme un moyen d’assurer une transparence publique solide sur les systèmes de surveillance d’OpenAI. Les parties ont convenu dès le départ de ne publier qu’un billet public relativement bref et général. OpenAI s’est réservé le droit de caviarder, dans la version publique, toute information qu’elle jugeait, à sa seule discrétion, confidentielle ou autrement sensible. Les conclusions portent sur le système historique évalué au 21 juillet et avant cette date et ne tiennent pas compte des changements alors en cours ; METR a indiqué qu’OpenAI élargissait son système de surveillance pendant l’exercice.

Lacunes de couverture et moyens de contourner le système de surveillance

METR a estimé qu’au moment de l’exercice, environ 75 à 94 % du trafic interne de l’API Responses associé à des agents et provenant de modèles au moins aussi performants que GPT-5.5 pouvait faire l’objet d’une surveillance, tout en reconnaissant une marge d’incertitude importante dans les deux sens. L’API Responses alimente notamment Codex et, pour le sous-ensemble de ce trafic utilisé par les agents internes de Codex, les évaluateurs ont estimé que 99,2 % pouvait faire l’objet d’une surveillance. Ils ont déclaré ne pas avoir été en mesure d’estimer le volume d’autres activités internes de programmation agentique dont ils avaient connaissance, comme celles d’agents exécutés sur le service interne d’inférence de recherche d’OpenAI, en raison de contraintes d’accès et de temps.

Plusieurs conclusions portaient sur les lacunes de cette couverture. Au début de l’exercice, les cycles d’entraînement par apprentissage par renforcement n’étaient pas couverts par le système de surveillance, même si les évaluateurs avaient été informés qu’un sous-ensemble des trajectoires d’entraînement par apprentissage par renforcement avait fait l’objet d’une surveillance du désalignement entre mars et juin. METR a estimé que l’absence de surveillance des événements de compaction avait probablement laissé sans surveillance environ 10 % du trafic interne de Codex pouvant y être soumis entre mai et juillet 2026. Le personnel d’OpenAI avait repéré cette lacune de son côté avant le début de l’exercice et l’avait corrigée pendant celui-ci. Comme le système se déclenchait lorsque les agents rendaient le contrôle à l’utilisateur, ceux-ci auraient pu repousser indéfiniment leur surveillance en continuant simplement d’agir pendant cette période ; les contraintes d’accès ont empêché les évaluateurs de vérifier si un agent l’avait fait en pratique. Par ailleurs, les évaluateurs ont reçu des informations laissant penser qu’au moment de l’exercice, le système de surveillance renvoyait une erreur pour moins de 0,2 % des requêtes et n’avait enregistré aucun délestage de charge sur une période de 24 heures.

Les évaluateurs ont également relevé des moyens de déjouer complètement la surveillance. Ils ont découvert une méthode permettant en principe aux agents Codex de contourner le bac à sable de Codex et Auto-Review afin d’effectuer toute action accessible à l’utilisateur de la machine hôte, ainsi qu’un exploit — dont OpenAI a caviardé les détails — qui empêcherait la surveillance de centaines d’actions récentes, y compris celles nécessaires à l’exécution de l’exploit lui-même. Ils ont constaté que les agents pouvaient probablement concevoir des entrées faisant échouer le système de surveillance et évitant ainsi le déclenchement d’un examen humain, en exploitant les différences entre la sérialisation de la trajectoire présentée à l’agent et celle présentée au système de surveillance. Ils ont repéré deux en-têtes indépendants, contrôlables par le client, qui désactivent le système de surveillance pour les nouveaux agents et pourraient permettre à un agent de lancer une instance par ailleurs identique, mais non surveillée. Toutefois, le système de surveillance pourrait détecter l’ajout de ces en-têtes et la création de l’instance. Enfin, ils ont découvert deux outils agentiques internes non surveillés, auxquels on attribuait des autorisations en lecture seule, qu’un exploit simple aurait pu détourner pour effectuer des actions arbitraires dans leur environnement isolé. Les évaluateurs n’ont ni validé ni testé ce comportement en pratique.

Parallèlement aux vulnérabilités, les évaluateurs ont vérifié que, à quelques exceptions mineures près, le système de surveillance recevait la trajectoire complète à laquelle les agents ont accès. Ils ont également confirmé que les instructions données au moniteur lui demandaient de repérer, entre autres catégories de risques, les manœuvres de contournement, les tentatives de compromission du système de surveillance, le sabotage, l’exfiltration de données, la tromperie et les injections de prompt entrantes et sortantes. Depuis la fin de l’exercice, OpenAI a déclaré avoir corrigé toutes les vulnérabilités identifiées qui affectaient sa pile de mesures de protection en production et a décrit des changements importants apportés par la suite à la couverture prévue de son système de surveillance. METR a indiqué ne pas avoir évalué ces affirmations.

Le système de surveillance tel que décrit par OpenAI

OpenAI a décrit publiquement le système testé dans une publication du 19 mars 2026. Selon cette publication, le système à faible latence fonctionne avec GPT-5.4 Thinking au niveau maximal d’effort de raisonnement, examine les interactions des agents dans les 30 minutes suivant leur achèvement, et consigne et analyse leurs chaînes de pensée et leurs actions. Il classe chaque interaction, lui attribue un niveau de gravité et signale les anomalies en vue d’un examen humain. OpenAI a indiqué que le système était déployé dans l’ensemble de ses environnements internes standard d’agents de programmation et qu’il avait accès à l’historique complet des conversations, y compris à tous les messages des utilisateurs, des développeurs et de l’assistant, ainsi qu’aux appels d’outils et à leurs résultats.

Dans sa publication, OpenAI énumère les catégories de comportements surveillés, notamment le contournement des restrictions, la tromperie, la dissimulation de l’incertitude, le piratage des mécanismes de récompense, le transfert non autorisé de données, les actions destructrices et les injections de prompt entrantes et sortantes. L’entreprise n’avait signalé aucun vrai positif concernant la dissimulation des capacités, le sabotage ou les manœuvres stratégiques au 17 mars 2026. Selon OpenAI, au cours de cinq mois de fonctionnement, le système a surveillé des dizaines de millions de trajectoires internes de codage agentique et a transmis environ 1 000 conversations présentant un niveau de gravité modéré pour examen humain, dont beaucoup provenaient d’exercices délibérés de red team internes. Aucune conversation réelle n’a déclenché le niveau de gravité le plus élevé. L’entreprise a également indiqué que le moniteur avait signalé toutes les interactions que des employés avaient rapportées de leur propre initiative par les canaux internes.

Dans sa publication, OpenAI a déclaré que cette approche reposait essentiellement sur la possibilité de surveiller les systèmes et qu’il était impossible de quantifier avec confiance les taux de faux négatifs pour des flux de données réels et ouverts sans évaluations de contrôle et exercices de red team dédiés. L’entreprise a présenté la surveillance comme une couche d’une architecture de défense en profondeur. Sa feuille de route prévoyait des évaluations de contrôle, l’établissement de normes de fiabilité et de latence acceptables pour les moniteurs et les évaluateurs humains, ainsi qu’une évolution vers un blocage synchrone, qui permettrait d’évaluer les actions du modèle et de les bloquer avant leur exécution.

Principes de conception pour la surveillance future

À partir de leurs conclusions, les évaluateurs ont défini des principes de conception pour les systèmes de surveillance et de contrôle. Selon eux, les infrastructures de surveillance futures devraient pouvoir résister à des attaques délibérées et prolongées, menées de manière stratégique et à grande échelle par des agents très capables opérant au sein d’une organisation. Les cinq principes consistent à rendre difficile le fait d’échapper à la surveillance, à garantir que le trafic censé être surveillé l’est effectivement, à réagir rapidement et de façon fiable aux incidents, à soumettre activement le système de surveillance à des exercices de red team et à assurer l’isolation entre les agents et leurs moniteurs. Parmi les pratiques précises décrites figurent la surveillance des agents à intervalles réguliers, après un nombre défini de messages ou de minutes, plutôt que d’attendre la fin de leur tour de parole, la tenue d’une liste de toutes les méthodes connues pour contourner la surveillance, la conservation de journaux infalsifiables et interrogeables, ainsi que l’exécution des cadres d’exécution des agents dans un environnement isolé de celui où les appels d’outils sont exécutés.

METR a indiqué que l’exercice avait largement bénéficié de la profondeur de l’accès accordé, ainsi que du soutien logistique et technique important fourni par le personnel d’OpenAI. Pour les prochaines versions de l’exercice, METR prévoit de suivre les bonnes pratiques en matière de transparence et d’indépendance décrites dans son document « Notre approche de la collaboration avec les entreprises d’IA », afin d’offrir une transparence publique plus solide.