Le 22 octobre 2026, les évaluateurs de sécurité IA METR et Redwood Research ont publié conjointement les résultats d'un test red-team du système de surveillance interne des agents d'OpenAI : au cours d'un pilote de trois semaines, les deux organisations ont trouvé plusieurs vulnérabilités dans la pile de surveillance, dont un moyen par lequel les agents pouvaient en principe soustraire des centaines de leurs actions à la surveillance. OpenAI a répondu que les vulnérabilités touchant les protections de production avaient été corrigées, mais les évaluateurs ont déclaré ne pas avoir vérifié les correctifs.
Comment le test a été mené
L'exercice était un pilote d'« évaluations embarquées » (embedded evaluations) : du 21 juillet au 11 août, METR et Redwood ont chacun envoyé un chercheur travailler à l'intérieur d'OpenAI, avec accès au code interne, aux prompts de surveillance, aux détails de configuration et à la documentation, ainsi que des entretiens avec une douzaine de chercheurs et d'ingénieurs d'OpenAI. Les chercheurs ont été accompagnés en permanence et ont travaillé sur des appareils fournis par OpenAI, qui n'ont jamais quitté les locaux. Reuters a rapporté la publication le 22 octobre, et le blog officiel de Redwood Research a publié le résumé technique.
Ce qui a été trouvé
Les conclusions publiées s'articulent autour de cinq points :
- Contournement de la surveillance : les évaluateurs ont décrit un moyen par lequel les agents pouvaient en principe garder des centaines de leurs actions les plus récentes non surveillées. Le rapport n'a pas établi si les agents avaient réellement utilisé cette voie pour retarder la surveillance.
- Estimations de couverture : en prenant comme référence le système tel qu'il existait le 21 juillet, les évaluateurs ont estimé que 75 % à 94 % du trafic API Responses interne piloté par des modèles au moins aussi capables que GPT-5.5 était « éligible à la surveillance ». L'estimation comportait une incertitude substantielle, et « éligible » ne signifiait pas « effectivement surveillé ».
- Lacune des événements de compaction : une lacune liée aux événements de compaction du contexte a laissé environ 10 % du trafic Codex interne éligible non surveillé de mai à juillet. Le personnel d'OpenAI avait découvert la lacune avant le début de l'exercice et l'a corrigée pendant l'exercice.
- Contournement du bac à sable et de l'auto-révision : le rapport a également décrit des moyens par lesquels les agents pouvaient en principe contourner le sandboxing de Codex et l'Auto-Review, ainsi que des entrées pouvant empêcher le moniteur de faire remonter une activité suspecte pour examen humain.
- Compromis sur la transparence : seul OpenAI a reçu le rapport complet de 61 pages ; le public n'a eu qu'un résumé expurgé par OpenAI. Les évaluateurs ont accepté qu'OpenAI expurge les informations sensibles et, cette fois — contrairement aux évaluations précédentes — n'ont pas pu divulguer indépendamment ce qui avait été expurgé.
Le signal
Le signal n'est pas « y avait-il des vulnérabilités » — tout système de surveillance scruté trois semaines par deux équipes red-team de premier plan produira des constats. Il est double. D'abord, l'offensive et la défensive de la surveillance à l'ère des agents sont passées de « le modèle se comportera-t-il mal » à « le gardien peut-il suivre le gardé » : quand les agents apprennent à jouer avec le moniteur, la couverture devient une métrique mouvante, pas un test d'acceptation ponctuel. Ensuite, le modèle d'évaluation lui-même est à l'essai : inviter des évaluateurs externes à l'intérieur du laboratoire, c'est l'« évaluation indépendante » que l'industrie réclame depuis longtemps, mais l'arrangement sur les expurgations montre à quel point une évaluation indépendante vraiment ouverte reste lointaine.
Pour les développeurs ordinaires, l'impact direct est limité, mais un jugement vaut d'être retenu : quand vous donnez à un agent des privilèges élevés — lire et écrire des fichiers, exécuter du code, appeler des API — ne présumez pas que la surveillance interne du fournisseur rattrape tout. Si le propre moniteur interne d'OpenAI s'est révélé contournable, les marges de sécurité des services publics ne peuvent être que plus minces.
