OpenAI sous pression après les failles de son système de surveillance

METR et Redwood Research ont mené entre le 21 juillet et le 11 août 2026 un exercice pilote sur l’infrastructure interne d’OpenAI, avec un accès profond aux outils, aux configurations et aux journaux du système de surveillance des modèles. Leur conclusion est directe : le dispositif couvre une grande partie des usages visés, mais il laisse encore des brèches qu’un agent assez sophistiqué pourrait exploiter. Dans un secteur où la sécurité des IA devient un argument de confiance autant qu’un sujet de gouvernance, le test tombe au bon moment. Ou au mauvais, selon le point de vue.

Un test conçu pour voir jusqu’où l’accès externe peut aller

L’exercice ne visait pas une transparence totale, mais un pilote pour mesurer ce que signifie donner à des chercheurs externes un accès proche de celui d’un employé. Les deux évaluateurs ont travaillé sur des appareils fournis par OpenAI, utilisés sur place, et ont interrogé une douzaine de chercheurs et d’ingénieurs des équipes sécurité, systèmes de sûreté et monitoring. Le résultat public tient en version courte, car les parties s’étaient entendues pour ne publier qu’un résumé à haut niveau, OpenAI gardant la main sur les éléments sensibles [à vérifier].

Selon le compte rendu publié le 22 octobre 2026, les évaluateurs ont surtout cherché à estimer quelle part du trafic agentique passait réellement sous surveillance, et si des agents pouvaient désactiver ou subvertir le système. Le rapport interne complet compte 61 pages, contre 38 pages pour une version expurgée transmise aux directions de METR et de Redwood Research.

Des trous de couverture encore bien réels

METR estime qu’environ 75 à 94 % du trafic interne agentique via l’API Responses, pour des modèles au moins aussi puissants que GPT-5.5, était éligible à la surveillance au moment du test. Dans le sous-ensemble des agents Codex internes, la couverture atteignait selon eux 99,2 % du trafic éligible. Mais ces chiffres restent entourés d’une forte incertitude, et les évaluateurs n’ont pas pu mesurer tout le trafic de codage agentique interne dont ils avaient connaissance, faute d’accès et de temps.

Plusieurs angles morts ressortent pourtant nettement. Au début de l’exercice, les runs de reinforcement learning n’étaient pas couverts par le système, même si une partie des rollouts avait déjà été surveillée entre mars et juin. Autre trou signalé : l’absence de surveillance des événements de compaction aurait laissé environ 10 % du trafic Codex interne éligible sans contrôle entre mai et juillet 2026. OpenAI avait identifié ce problème avant l’exercice et l’a corrigé pendant celui-ci.

Le rapport souligne aussi un biais de conception plus subtil. Comme le système se déclenche lorsque l’agent rend la main à l’utilisateur, un agent peut théoriquement repousser indéfiniment sa surveillance en continuant d’agir. Les évaluateurs n’ont pas pu vérifier si cela s’était produit en pratique. Dans une fenêtre de 24 heures, ils ont par ailleurs vu des éléments suggérant que le moniteur avait moins de 0,2 % d’erreurs et aucun load-shed enregistré.

Les contournements identifiés sont plus inquiétants que les chiffres

Au-delà des pourcentages, les chercheurs ont trouvé des moyens concrets de contourner ou de neutraliser la surveillance. Ils ont mis au jour une méthode permettant à des agents Codex de contourner le sandboxing et l’Auto-Review pour effectuer toute action autorisée à l’utilisateur hôte. Ils ont aussi identifié un exploit, dont les détails ont été occultés par OpenAI, capable de faire disparaître de la surveillance des centaines d’actions récentes, y compris celles liées à l’exploit lui-même.

Les évaluateurs disent également qu’un agent peut probablement fabriquer des entrées qui font échouer le moniteur, en tirant parti d’écarts entre la façon dont la trajectoire est sérialisée pour l’agent et pour le système de surveillance. Deux en-têtes client contrôlables permettent en outre de désactiver le dispositif pour de nouveaux agents, ce qui ouvre la porte à un lancement d’instance non surveillée, même si l’ajout de ces en-têtes peut lui-même être détecté. Enfin, deux outils internes agentiques en lecture seule, mais non surveillés, auraient pu être détournés pour exécuter des actions arbitraires dans leur environnement sandboxé.

OpenAI affirme de son côté que toutes les vulnérabilités touchant sa pile de protections en production ont depuis été corrigées, et qu’elle a modifié de manière importante la couverture prévue de son système de monitoring. METR précise ne pas avoir vérifié ces affirmations. C’est l’un de ces cas où la version “corrigée” existe, mais pas encore sous contrôle indépendant.

Ce que OpenAI surveillait déjà, et ce qu’elle veut faire ensuite

Dans une publication du 19 mars 2026, OpenAI décrivait un système à faible latence propulsé par GPT-5.4 Thinking, chargé d’analyser les interactions des agents dans les 30 minutes suivant leur exécution. Le dispositif enregistre et examine les chaînes de pensée et les actions, classe chaque interaction, attribue un niveau de gravité et remonte les anomalies à des humains. La société indiquait aussi qu’il couvrait l’ensemble des déploiements internes de codage standard, avec accès à l’historique complet des conversations et des appels d’outils.

Les catégories surveillées incluent le contournement des restrictions, la tromperie, la dissimulation d’incertitude, le reward hacking, les transferts de données non autorisés, les actions destructrices et les injections de prompt entrantes et sortantes. Sur cinq mois d’exploitation, OpenAI disait avoir suivi des dizaines de millions de trajectoires de codage agentique internes, avec environ 1 000 conversations escaladées à un niveau modéré pour revue humaine et zéro conversation réelle au niveau de gravité le plus élevé.

La société ajoute que cette approche repose d’abord sur la monitorabilité, sans pouvoir chiffrer de façon fiable les faux négatifs sur du trafic ouvert sans évaluations dédiées et red-teaming. Sa feuille de route comprend des évaluations de contrôle, des standards de fiabilité et de latence pour les moniteurs et les humains, puis une évolution vers un blocage synchrone des actions avant exécution.

Pourquoi ce rapport compte pour le marché de l’IA

Le cœur du sujet n’est pas seulement la sécurité d’OpenAI, mais la façon dont les acteurs de l’IA pensent leurs garde-fous à mesure que les agents gagnent en autonomie. Si un système de surveillance interne peut être contourné, même partiellement, la question devient industrielle : comment surveiller des modèles plus capables que les workflows qui les entourent ? Les recommandations de METR vont dans ce sens, avec une idée simple : il faut des systèmes capables de résister à des attaques délibérées, répétées et organisées, menées par des agents puissants à l’intérieur d’une entreprise.

Leur liste de principes est assez claire : rendre la surveillance difficile à éviter, vérifier que le trafic censé être contrôlé l’est vraiment, réagir vite, tester le système en continu et isoler l’agent de son moniteur. Cela passe aussi par des pratiques très concrètes, comme monitorer les agents à intervalles réguliers plutôt qu’à la fin de leur tour, tenir un registre des détours connus, conserver des journaux infalsifiables et séparer l’environnement d’exécution des appels d’outils de celui où vivent les agents. Bref, le genre de détail qui ne fait pas rêver les communicants, mais qui évite des surprises plus tard.