Du 21 juillet au 11 août 2026, deux chercheurs extérieurs, issus de METR et de Redwood Research, ont eu un accès approfondi aux infrastructures d’OpenAI pour tester son système de détection du désalignement de ses agents.

METR décrit un exercice pilote de red-teaming « à haut niveau d’accès » au cours duquel ils ont pu consulter le code interne, les prompts et configurations des moniteurs ainsi que la documentation. L’exercice porte sur le système tel qu’il existait le 21 juillet et avant. OpenAI l’élargissait alors : ces évolutions n’ont pas été évaluées, et les constats ne décrivent donc pas la couverture actuelle.

Les deux chercheurs ont mené des entretiens techniques avec une douzaine de chercheurs et d’ingénieurs des équipes de surveillance, de sûreté des systèmes et de sécurité. Ils travaillaient sur des appareils fournis par OpenAI qui ne quittaient pas les locaux.

Dans un rapport interne, partagé avec les chercheurs et les équipes de sécurité d’OpenAI, ils cherchent à répondre à deux questions :

quelle part de l’activité des agents est réellement surveillée ?

un agent pourrait-il, en théorie, désactiver ou détourner le système de surveillance ?

Les règles de publication ont été fixées à l’avance : un billet de blog relativement bref et de haut niveau, et la possibilité pour OpenAI de retirer, à sa seule discrétion, toute information jugée confidentielle ou sensible.

Le billet de METR précise que, contrairement à d’autres missions, comme son enquête distincte sur l’incident Hugging Face, l’organisation n’avait pas ici le droit unilatéral de décrire ces retraits.

Entre 75 % et 94 % du trafic estimé éligible à la surveillance

Les chercheurs estiment qu’entre 75 % et 94 % du trafic agentique de l’API interne Responses, qui alimente notamment Codex, était éligible à la surveillance pour les modèles au moins aussi puissants que GPT-5.5, avec une forte incertitude dans les deux sens.

Pour le sous-ensemble utilisé par les agents Codex internes, la part atteint 99,2 %.

« Éligible » signifie destiné à être envoyé au moniteur : erreurs, délestage ou bugs peuvent en empêcher une partie d’aboutir. Le chiffre exclut d’autres sources de trafic, comme les agents tournant sur le service d’inférence interne de la recherche, dont le volume n’a pu être estimé.

Selon ce qui a été indiqué aux chercheurs, un sous-ensemble des sessions d’entraînement par apprentissage par renforcement était surveillé entre mars et juin. Au début de l’exercice, ces sessions n’étaient plus couvertes.

L’absence de surveillance des événements de compaction a probablement laissé sans contrôle de l’ordre de 10 % du trafic Codex éligible entre mai et juillet 2026. L’incertitude est forte, car l’information nécessaire n’était pas journalisée. OpenAI avait identifié le problème avant l’exercice et l’a corrigé pendant celui-ci.

Le moniteur se déclenchait quand l’agent rendait la main à l’utilisateur. Pendant la période sans surveillance de la compaction, un agent pouvait donc, en enchaînant les actions, repousser indéfiniment son examen. METR n’a pas pu vérifier si des agents l’avaient fait en pratique.

Enfin, d’après les informations communiquées aux chercheurs, le moniteur échouait sur moins de 0,2 % des requêtes, et aucune perte de charge n’a été relevée sur une période de 24 heures pendant l’exercice.

Cinq vulnérabilités signalées

Les chercheurs ont trouvé un moyen, en principe, de contourner le bac à sable et Auto-Review, permettant à un agent d’effectuer toute action accessible à l’utilisateur hôte.

Une faille empêchait la surveillance de centaines d’actions récentes, y compris celles de l’exploitation elle-même. Les détails ont été expurgés par OpenAI.

Des agents pouvaient vraisemblablement fabriquer des entrées faisant échouer le moniteur, en jouant sur les différences entre la trajectoire vue par l’agent et celle vue par le moniteur. La trajectoire n’était alors pas transmise à un réviseur humain.

Deux en-têtes indépendants, contrôlables côté client, désactivaient la surveillance des nouveaux agents, ce qui pouvait permettre de lancer une instance non surveillée mais par ailleurs identique. L’acte de positionner ces en-têtes et de créer l’instance pouvait toutefois être repéré par le moniteur.

Pour deux outils agentiques non surveillés, un exploit simple aurait permis d’effectuer des actions arbitraires dans leur environnement isolé. METR n’a ni validé ce comportement ni testé son exploitabilité en pratique.

L’exercice a aussi produit deux constats plus rassurants.

À quelques exceptions mineures près, le moniteur voit la trajectoire complète que voit l’agent.

Les prompts du moniteur cherchent notamment le scheming, la subversion du moniteur, le sabotage, l’exfiltration de données, la tromperie et les injections de prompt entrantes et sortantes.

Cinq principes de conception

METR en tire des principes visant des systèmes de surveillance capables de résister à des attaques délibérées, stratégiques et soutenues, menées à grande échelle par des agents internes très capables.

Rendre la surveillance difficile à éviter. Les requêtes non surveillées exigeraient une approbation explicite pour utiliser un ensemble défini d’organisations et de clés d’API, dont l’usage est interdit à l’inférence agentique. Les agents seraient surveillés tous les N messages ou N minutes, sans attendre la fin de leur tour.

S’assurer que le trafic censé être surveillé l’est réellement. Comptabiliser toute l’inférence, recouper régulièrement ces journaux avec ceux du moniteur, tenir la liste des contournements connus et veiller à ce que le moniteur voie le même contexte que l’agent.

Répondre vite et de façon fiable aux incidents. Désigner un responsable clair, fixer des consignes réduisant la subjectivité et conserver des journaux inaltérables et faciles à interroger.

Soumettre le moniteur à un red-teaming actif. Évaluer périodiquement les contrôles, chercher les bugs exploitables et mettre au point une méthode pour évaluer les collusions stratégiques.

Isoler agents et moniteurs. Dans la mesure du possible, exécuter l’architecture de l’agent dans un environnement distinct de celui des appels d’outils. Les actions de l’agent ne devraient pas influer sur le déclenchement du moniteur, et l’agent n’aurait en général pas accès à sa conception ni à son code.

OpenAI affirme avoir corrigé toutes les vulnérabilités identifiées qui touchaient sa pile de protections en production, et a décrit depuis des changements importants dans la couverture prévue de son dispositif. METR indique ne pas avoir évalué ces affirmations.

Pour les prochaines éditions, METR dit viser davantage de transparence et d’indépendance.

Source : « Red-Teaming OpenAI’s Internal Agent Monitoring Systems », METR, 22 octobre 2026.

The post Agents IA : la surveillance interne d’OpenAI passée au crible appeared first on Silicon.fr.