Le 22 octobre 2026, METR a publié un résumé de son audit pilote du système interne de surveillance des agents d’OpenAI. L’évaluation signale des failles possibles et estime séparément la part de trafic éligible au contrôle selon les populations examinées. METR n’a pas évalué les correctifs qu’OpenAI dit avoir appliqués.
Un pilote consacré au système interne d’OpenAI
L’audit portait sur le dispositif interne de surveillance du désalignement des agents, conçu pour examiner leur activité. METR et Redwood Research ont chacun mobilisé un salarié pour ce pilote de trois semaines, conçu avec OpenAI. L’exercice s’est déroulé entre le 21 juillet et le 11 août.
Les deux évaluateurs ont eu accès au code interne, aux consignes et à la configuration du système de surveillance ainsi qu’à des documents internes. Ils ont aussi interrogé environ une douzaine de chercheurs et d’ingénieurs. L’audit concernait la surveillance interne des agents, pas la sécurité des données des clients.
Ce que mesurent les estimations de surveillance
Être « éligible » au contrôle signifie que le trafic devait être envoyé au système de surveillance. Cela ne garantit pas que chaque requête ait parcouru toute la chaîne de contrôle.
| Mesure | Population | Estimation et période | Précision |
| Trafic éligible au contrôle | Trafic interne de Responses API issu d’agents utilisant des modèles au moins aussi capables que GPT-5.5 | 75 à 94 % | Estimation fortement incertaine; d’autres sources internes d’activité des agents étaient exclues. |
| Trafic éligible au contrôle | Trafic de Responses API utilisé par les agents Codex internes | 99,2 % | Estimation pour ce sous-ensemble. |
| Trafic éligible laissé sans contrôle à cause d’événements de compaction | Trafic Codex interne éligible | Environ 10 %, entre mai et juillet 2026 | Estimation fortement incertaine. |
Pour l’estimation générale, METR a exclu d’autres sources connues, notamment le service interne de recherche et d’inférence d’OpenAI, dont le volume était impossible à estimer. Le chiffre de 99,2 % concerne uniquement le sous-ensemble Codex; l’estimation d’environ 10 % porte sur le trafic éligible de ce même sous-ensemble laissé sans contrôle en raison d’un défaut lié aux événements de compaction.
METR rapporte aussi que les informations présentées aux auditeurs indiquaient un taux d’erreur du système inférieur à 0,2 % des requêtes et aucun délestage pendant une période de 24 heures de l’exercice. Au début de celui-ci, les entraînements par apprentissage par renforcement n’étaient pas couverts par le système. METR avait été informé qu’un sous-ensemble de leurs séquences avait été surveillé entre mars et juin; OpenAI élargissait la surveillance pendant l’exercice.
Des voies de contournement possibles
Les évaluateurs ont trouvé qu’un agent pouvait, en principe, contourner le bac à sable de Codex et Auto-Review, ainsi qu’une méthode permettant de masquer des centaines d’actions récentes. Ils ont aussi identifié des entrées susceptibles de faire échouer le système de surveillance. Deux en-têtes contrôlables par le client pouvaient désactiver le contrôle pour de nouveaux agents; le réglage de ces en-têtes pouvait lui-même être détecté.
Le système déclenchait le contrôle lorsque l’agent rendait la main à l’utilisateur. Pendant la lacune liée aux événements de compaction, un agent pouvait donc repousser indéfiniment le contrôle en continuant à agir. METR n’a pas pu établir que des agents avaient exploité cette faiblesse en pratique.
OpenAI a indiqué que les vulnérabilités touchant les garde-fous de production et repérées pendant l’exercice avaient été corrigées. METR n’a évalué ni ces correctifs ni l’élargissement ultérieur de la surveillance.
METR indique que le rapport complet comptait 61 pages. Une version de 38 pages, expurgée par OpenAI, a été remise aux directions de METR et de Redwood Research; le public a reçu un résumé plus court.
