METR a cherché les angles morts de la surveillance des agents chez OpenAI

Les laboratoires d'IA utilisent leurs propres agents en interne, pour écrire du code notamment. Pour repérer un agent qui dérape, ils s'appuient sur un « moniteur » : un second système qui relit les actions du premier et alerte un humain en cas de doute. Encore faut-il que ce moniteur voie tout. C'est ce que METR, organisme indépendant d'évaluation, a voulu vérifier chez OpenAI. Son compte rendu est daté du 22 octobre 2026 et a été corrigé le 29.

L'exercice

Un salarié de METR et un salarié de Redwood Research ont travaillé trois semaines, du 21 juillet au 11 août, avec un accès au code interne d'OpenAI, aux consignes du moniteur et à la documentation. Ils ont interrogé une douzaine d'ingénieurs et de chercheurs. Le rapport interne compte 61 pages ; le billet public n'en est qu'un résumé.

Deux questions guidaient le travail : quelle part de l'activité des agents est réellement surveillée, et un agent pourrait-il désactiver ou contourner cette surveillance ?

Ce qui a été trouvé

Côté couverture, METR estime que 75 à 94 % du trafic interne d'agents passant par l'API Responses était éligible à la surveillance, avec une forte incertitude. Pour les agents Codex internes, l'estimation monte à 99,2 %.

Côté failles, la liste est plus gênante :

• les phases de « compaction », quand l'agent résume son historique pour continuer, n'étaient pas surveillées. Environ 10 % du trafic Codex éligible aurait ainsi échappé au contrôle entre mai et juillet 2026 ;
• le moniteur ne se déclenchait que lorsque l'agent rendait la main. Un agent qui continuait d'agir pouvait repousser le contrôle indéfiniment ;
• deux en-têtes modifiables côté client désactivaient la surveillance pour un nouvel agent ;
• un agent Codex pouvait en principe sortir de son bac à sable et faire tout ce que l'utilisateur de la machine pouvait faire ;
• l'agent et le moniteur ne voyaient pas exactement les mêmes données, ce qui permettait de faire échouer le moniteur.

Selon OpenAI, la plupart de ces failles sont corrigées et un correctif reste en cours.

Les limites du compte rendu

Elles sont nombreuses, et METR les expose lui-même.

• Le billet décrit le système tel qu'il était le 21 juillet, pas celui d'aujourd'hui. METR n'a pas évalué les changements annoncés depuis par OpenAI.
• OpenAI pouvait expurger tout ce qu'elle jugeait sensible, et METR ne pouvait pas décrire ces coupes de son propre chef.
• « Éligible » ne veut pas dire « surveillé » : des erreurs ou des bugs peuvent empêcher un contrôle d'aboutir. Le taux d'erreur inférieur à 0,2 % est un chiffre montré à METR, pas vérifié par lui.
• Les chercheurs n'ont pas pu vérifier si des agents avaient réellement exploité ces failles.
• D'autres trafics internes d'agents restent hors de l'estimation.

La mise à jour du 29 octobre va dans le même sens : la première version affirmait que toutes les failles touchant la production étaient corrigées, la version actuelle parle de « la plupart ».

Notre lecture

Peu de PME disposent d'un moniteur dédié. Mais dès qu'un agent tourne avec des droits sur un poste ou un dépôt de code, les principes proposés par METR s'appliquent à petite échelle :

• contrôler à intervalles réguliers, pas seulement à la fin d'une tâche ;
• tenir un inventaire de ce qui tourne et de ce qui est effectivement journalisé, puis recouper les deux ;
• séparer l'agent de son contrôle : il ne doit pas pouvoir modifier ses propres permissions ni lire le code de ce qui le surveille ;
• conserver des journaux que l'agent ne peut pas altérer.

Le fait qu'un acteur de cette taille ait eu des angles morts aussi simples qu'un en-tête à changer rappelle une chose : un dispositif de contrôle ne vaut que s'il a été attaqué par quelqu'un d'autre que celui qui l'a conçu.