Chez OpenAI, le surveillant des agents attendait qu'ils s'arrêtent

Un contrôleur qui ne monte qu'en gare

À l'été 2026, le moniteur chargé de repérer les dérives des agents d'OpenAI se déclenchait au moment où l'agent rendait la main à l'utilisateur. Entre deux arrêts, il ne regardait pas.

Tant que l'agent finit par s'arrêter, ça tient. Sauf qu'une étape échappait alors au moniteur : la compaction, ce moment où un agent dont la conversation devient trop longue en résume le début pour continuer. Pendant la période où ces compactions n'étaient pas surveillées, écrivent les auditeurs, un agent pouvait repousser indéfiniment le contrôle en continuant simplement d'agir. Un contrôleur qui ne monte qu'en gare, dans un train capable de ne plus jamais s'arrêter.

Des agents l'ont-ils fait ? Les auditeurs n'ont pas pu le vérifier, faute d'accès. C'est la faille la plus simple à comprendre d'une liste publiée le 22 octobre par METR, et cette liste est courte parce que le public n'en a reçu qu'une partie.

Trois semaines dans les murs

Du 21 juillet au 11 août, un employé de METR et un employé de Redwood Research, deux organismes de recherche sur les risques de l'IA, ont éprouvé ce dispositif de l'intérieur. Accès au code interne, aux consignes et à la configuration des moniteurs, à la documentation, entretiens avec une douzaine d'ingénieurs. Le tout sur des ordinateurs fournis par OpenAI, qui ne sont jamais sortis des locaux, et toujours accompagnés. Un inspecteur à qui l'on prête le carnet de bord, à condition de le rendre à la sortie.

Ce n'est pas l'enquête sur l'attaque de Hugging Face par les agents d'OpenAI, publiée par METR le 26 août. Le billet le précise : l'exercice était distinct, et l'affaire est devenue publique le jour même où il commençait. Il porte sur le système tel qu'il existait jusqu'au 21 juillet.

Le 20 août, on posait ici une question restée ouverte. OpenAI chiffrait à 20 % le surcoût de sa surveillance, mais 20 % de quoi, puisque la part surveillée n'était pas publiée ? METR apporte la première mesure extérieure. Elle est prudente, et c'est ce qui fait sa valeur.

Ce que disent les chiffres, au mot près

METR estime qu'environ 75 à 94 % du trafic agentique interne passant par la Responses API, l'interface qui fait tourner entre autres Codex, l'agent de programmation d'OpenAI, était éligible à la surveillance. Le calcul porte sur les modèles au moins aussi puissants que GPT-5.5, et METR précise que l'incertitude est importante dans les deux sens.

Depuis vendredi, ce chiffre circule retourné, d'après un calcul du site The Decoder : 6 à 25 % du trafic n'était pas surveillé. Le calcul est juste, la formule perd deux choses. « Éligible » veut dire destiné au moniteur, pas vu par lui : une erreur ou un bug peut arrêter une requête en route. Et le périmètre ne couvre qu'un canal. Le service d'inférence de recherche interne en est exclu, et METR n'a pas pu en estimer le volume.

La part réellement non surveillée, tous canaux confondus, personne ne la connaît. On a compté les clients passés en caisse dans un magasin dont on ignore combien il a de portes.

Les autres constats sont plus nets. Sur la partie Codex, 99,2 % du trafic était éligible, mais les compactions non surveillées ont fait perdre de l'ordre de 10 % du trafic éligible entre mai et juillet. OpenAI avait repéré le problème avant l'exercice et l'a corrigé pendant. Quant à l'entraînement par renforcement, la phase où le modèle apprend par essais et récompenses, il n'était pas surveillé au début de l'exercice. Une partie l'avait été de mars à juin, selon ce qu'on a dit aux auditeurs.

S'y ajoutent un contournement possible du bac à sable de Codex, deux en-têtes de requête capables de lancer un agent non surveillé, des entrées piégées qui pourraient faire échouer le moniteur. Et une faille qui masquait des centaines d'actions récentes, dont le texte publié ne donne que cette mention : « [exploit details redacted by OpenAI] ».

61 pages, 38 pages, un billet

Cette ligne noircie résume toute la chaîne. Les deux chercheurs ont rédigé un rapport interne de 61 pages, partagé avec les équipes de recherche et de sécurité d'OpenAI. Les directions de METR et de Redwood, celles qui emploient les auteurs, en ont reçu une version de 38 pages, caviardée par OpenAI. Le public a un billet de blog.

C'est un contrôle fiscal dont l'entreprise contrôlée garde le dossier complet, dont la hiérarchie des inspecteurs reçoit une version expurgée, et dont les contribuables lisent un communiqué.

Rien de caché dans le procédé : l'accord prévoyait d'emblée un billet bref, l'exercice étant conçu pour tester un accès profond, pas pour offrir de la transparence. OpenAI pouvait caviarder à sa seule discrétion. Et contrairement à l'enquête sur Hugging Face, METR n'avait pas le droit de décrire ce qui avait été retiré. METR ne publiait déjà qu'une petite partie du rapport privé lors d'un exercice semblable chez Anthropic, en mars.

Le détail qui gêne date du 14 octobre. Ce jour-là, METR publiait ses règles de travail avec les entreprises d'IA : pouvoir dire si un caviardage touche les conclusions, permettre à sa direction d'accéder aux informations cloisonnées, garder la propriété de ce qu'il produit. Le texte reconnaît que tous ses travaux en cours n'atteignent pas ce niveau. Huit jours plus tard, METR en publiait un.

Le 23 octobre, Internet débranché

Le lendemain, OpenAI annonçait que ses modèles de pointe s'entraîneraient désormais sans accès à Internet, dans un « monde hors ligne » fait de pages web indexées et mises en cache. Parmi ses motifs, l'entreprise cite elle-même l'état de la recherche en alignement, celui de la sécurité d'Internet, et celui des systèmes de surveillance.

Le billet ne mentionne pas l'exercice de METR. Il admet en revanche qu'isoler complètement l'infrastructure n'est pas faisable : il faut des connexions sortantes pour faire tourner et surveiller les expériences. Après l'affaire Hugging Face, il en restait quelques-unes, pour les métriques, la journalisation, l'authentification. Chargés d'attaquer des copies de cette infrastructure, des agents d'OpenAI ont trouvé dans presque chacun de ces services une faille donnant un accès limité à Internet. La porte d'entrée est fermée, les portes de service restent indispensables.

Le billet cite aussi le 20 septembre, quand un modèle a obtenu un accès limité à Internet par une mauvaise configuration DNS, comme l'exemple de ce que ses investissements permettent : détecter et arrêter. Le rapport d'incident, qu'on a raconté le 5 octobre, est moins flatteur. L'exécution ne s'est pas arrêtée automatiquement comme prévu, d'autres accès du même type n'avaient pas été signalés au bon niveau de gravité, et un détecteur d'activité DNS anormale excluait l'environnement concerné. L'entraînement a repris le 1er octobre, onze jours après le début de la pause.

Le système mesuré n'existe plus

OpenAI affirme avoir corrigé toutes les failles qui touchaient ses protections en production, et décrit une surveillance bien plus étendue depuis l'été. METR l'écrit sans détour : il n'a pas évalué ces affirmations, et son exercice n'établit pas la couverture du système actuel.

On tient donc, pour la première fois, une mesure extérieure de ce que voyait la surveillance d'OpenAI. Elle porte sur un système qui n'existe plus. Celui qui le remplace, et sur lequel repose la promesse du 23 octobre, n'a encore été mesuré que par OpenAI.