Par Tsuky 
Un agent d'intelligence artificielle capable d'exécuter du code ne se limite pas à produire du texte. Il peut créer des fichiers, lancer des commandes, communiquer avec des outils et enchaîner des centaines d'opérations avant de rendre son résultat.
Cette autonomie impose une question de sécurité : comment vérifier ce qu'il fait réellement pendant que son utilisateur ou son développeur ne regarde pas ?
OpenAI a développé des mécanismes destinés à analyser les activités de ses agents et à détecter les comportements problématiques. Ces contrôles recherchent notamment les tentatives de sabotage, de tromperie, d'exfiltration de données et de contournement des restrictions.
Mais une surveillance automatique est elle-même un logiciel. Comme n'importe quelle infrastructure technique, elle peut contenir des failles.
C'est ce que viennent de démontrer METR et Redwood Research. Le 22 octobre, les deux organismes ont publié les principales conclusions d'une évaluation qui s'est déroulée pendant trois semaines au sein d'OpenAI.
Les chercheurs ont identifié plusieurs possibilités de contournement, parfois dans des composants supposés garantir la séparation entre les actions des agents et leur supervision.
Le point essentiel est de ne pas confondre la découverte d'une possibilité technique avec son exploitation effective par un agent déployé.
L'étude établit l'existence de faiblesses dans le système historique examiné. Elle ne démontre pas que chacune a été exploitée dans des opérations réelles.
Trois semaines au cœur des systèmes d'OpenAI
L'évaluation a été conduite du 21 juillet au 11 août 2026 par David Rein, de METR, et Adam Kaufman, de Redwood Research.
Chaque organisation a mobilisé un chercheur pour examiner les protections internes d'OpenAI dans le cadre d'une expérience d'évaluation intégrée.
Contrairement à un audit réalisé uniquement à partir d'un produit public, les chercheurs ont eu accès à des éléments confidentiels : code source interne, configurations des systèmes de surveillance, instructions des moniteurs et documentation technique.
Ils ont également pu échanger avec environ une douzaine de spécialistes travaillant dans les équipes de surveillance, de sûreté et de sécurité informatique.
L'accès était strictement encadré. Les chercheurs travaillaient sur des ordinateurs fournis par OpenAI qui ne quittaient pas ses locaux, avec un accompagnement sur place.
Cette formule offre une visibilité rarement accordée à des observateurs externes.
Elle comporte cependant une limite : l'entreprise évaluée contrôle les conditions d'accès et les informations pouvant être rendues publiques.
Les chercheurs précisent que l'exercice avait initialement été conçu pour expérimenter une forme d'audit externe approfondi, et non pour fournir une certification générale de la sécurité d'OpenAI.
Son objet portait principalement sur deux questions : quelle proportion de l'activité interne des agents était couverte par la surveillance, et dans quelle mesure ces agents pouvaient théoriquement contourner cette surveillance.
Une faille pouvait soustraire des centaines d'actions au contrôle
Le constat le plus spectaculaire concerne une méthode permettant potentiellement à un agent d'empêcher la surveillance de centaines de ses actions récentes.
Le problème ne se limitait pas à masquer une seule commande.
Selon METR et Redwood Research, la méthode aurait pu empêcher le contrôle d'une portion importante de l'historique récent, y compris les actions liées à l'exploitation de la faille.
Cette caractéristique est particulièrement préoccupante pour un système destiné à reconstruire les comportements suspects.
Une action malveillante peut sembler anodine lorsqu'elle est examinée isolément. Son importance peut n'apparaître qu'en consultant les opérations qui la précèdent et celles qui la suivent.
Si une partie de cette séquence disparaît, le moniteur risque de ne pas disposer du contexte nécessaire pour identifier le problème.
Les détails techniques de cette vulnérabilité n'ont pas été rendus publics : OpenAI les a retirés de la version destinée au public.
Les chercheurs ne présentent pas cette découverte comme la preuve qu'un agent aurait effectivement effacé des centaines de ses actions pendant une attaque réelle.
Ils démontrent qu'un tel contournement était possible dans le système étudié.
La différence est fondamentale pour évaluer la portée de l'incident.
Codex pouvait théoriquement sortir de son environnement restreint
Une autre découverte concerne les agents Codex, utilisés pour effectuer des tâches de programmation.
Ces agents peuvent exécuter des commandes et modifier des fichiers dans un environnement soumis à des règles de permissions.
Le principe du sandboxing consiste à limiter les opérations autorisées afin qu'un programme ne dispose pas automatiquement de tous les privilèges de la machine sur laquelle il fonctionne.
Les évaluateurs ont identifié une possibilité de contournement des restrictions de sandboxing et d'Auto-Review.
Dans le scénario décrit, un agent aurait pu accéder à des actions normalement disponibles à l'utilisateur qui l'exécute, au lieu de rester limité aux permissions prévues pour l'agent.
Cette distinction change profondément le niveau de risque.
Un agent disposant d'un accès restreint à un répertoire de travail n'a pas les mêmes capacités qu'un programme pouvant agir avec tous les droits de son utilisateur.
Il serait néanmoins incorrect d'en déduire que tous les utilisateurs de Codex ont subi une compromission.
La conclusion publiée porte sur une possibilité technique identifiée dans l'environnement examiné, pas sur un déploiement malveillant généralisé.
Elle montre pourquoi les permissions d'un agent doivent être effectivement imposées par l'infrastructure, et pas seulement décrites dans ses instructions.
Le moniteur pouvait attendre indéfiniment la fin d'une tâche
L'étude révèle une faiblesse moins spectaculaire, mais très instructive.
Au moment du système examiné, certains contrôles étaient déclenchés lorsque l'agent rendait la main à l'utilisateur.
Cette logique suppose qu'une tâche finit par atteindre un point où sa trajectoire peut être analysée.
Or un agent peut poursuivre ses opérations pendant longtemps sans terminer sa session.
Lorsque certains événements intermédiaires n'étaient pas surveillés, cette architecture créait une possibilité de repousser indéfiniment le prochain contrôle.
Les chercheurs expliquent qu'un agent aurait pu continuer à agir pour différer l'intervention du moniteur.
Ils n'ont cependant pas pu établir qu'un agent avait effectivement exploité cette possibilité, faute d'accès suffisant aux éléments historiques nécessaires.
Le défaut souligne une limite des systèmes qui ne vérifient l'activité qu'à la fin d'un traitement.
Pour un agent capable de lancer de longues séquences d'opérations, attendre la fin peut laisser passer une période importante sans analyse.
Les évaluateurs recommandent donc de déclencher les contrôles à intervalles réguliers, notamment après un certain nombre de messages ou un délai déterminé.
L'objectif est de rendre le déclenchement indépendant de la volonté ou du comportement de l'agent.
Des événements de compaction échappaient à la surveillance
Pour fonctionner sur des tâches longues, un agent doit gérer la quantité d'informations conservées dans son contexte.
Une technique consiste à compacter certaines données de la conversation ou de l'historique des opérations afin de poursuivre le traitement avec une représentation plus courte.
Ces événements de compaction peuvent contenir des informations importantes sur ce que l'agent a déjà fait.
Or les chercheurs ont constaté qu'ils n'étaient pas toujours soumis à la même surveillance que les autres étapes.
METR et Redwood Research estiment que cette lacune aurait pu entraîner l'absence de contrôle d'environ 10 % du trafic Codex interne pourtant éligible entre mai et juillet 2026.
Ce pourcentage est une estimation assortie d'une incertitude importante.
Les données historiques disponibles ne permettaient pas de déterminer précisément la fréquence de tous les déclenchements liés à ces événements.
Autre précision essentielle : OpenAI avait identifié le problème indépendamment avant le début de l'exercice et l'a corrigé pendant celui-ci.
Il ne s'agit donc pas d'une vulnérabilité que les chercheurs auraient nécessairement révélée pour la première fois à l'entreprise.
Le cas montre néanmoins qu'une fonction technique apparemment secondaire peut créer un angle mort dans un système de contrôle.
Entre 75 et 94 % du trafic éligible : ce que signifient réellement les chiffres
Le rapport fournit plusieurs estimations sur la couverture de la surveillance.
Pour l'activité agentique interne utilisant Responses API avec des modèles au moins aussi puissants que GPT-5.5, les chercheurs estiment que 75 à 94 % du trafic était éligible aux contrôles dans le système historique.
Pour le sous-ensemble des agents Codex utilisant cette API, la proportion estimée atteint 99,2 %.
Ces chiffres ne doivent pas être interprétés comme les taux de réussite des moniteurs.
Une requête éligible à la surveillance est une requête qui devrait être envoyée au système de contrôle.
Cela ne garantit pas qu'elle ait été effectivement examinée, ni qu'un comportement dangereux ait été correctement identifié.
Des erreurs techniques, des mécanismes de réduction de charge et des défauts d'implémentation peuvent intervenir entre l'éligibilité et l'analyse réelle.
Les chercheurs signalent également que certaines catégories d'activité interne n'étaient pas incluses dans leurs estimations, notamment des agents utilisant un autre service de calcul interne.
Ils ne pouvaient pas déterminer le volume de cette activité dans le temps imparti.
À l'ouverture de l'étude, les exécutions d'entraînement par renforcement n'étaient pas non plus couvertes par le système étudié, même si certains traitements avaient été surveillés pendant une période précédente.
L'audit ne permet donc pas de conclure que 75 à 94 % de l'ensemble des opérations réalisées par tous les agents d'OpenAI étaient effectivement surveillées.
Ces proportions concernent un périmètre et une architecture précis.
Deux paramètres pouvaient désactiver le contrôle de nouveaux agents
Les chercheurs ont également identifié deux en-têtes de requête contrôlables par le client qui pouvaient désactiver le système de surveillance pour de nouvelles instances d'agents.
Le problème est différent d'une faille permettant de modifier un historique déjà enregistré.
Il concerne la création d'une nouvelle instance qui fonctionnerait sans être soumise aux contrôles normalement attendus.
METR et Redwood Research précisent toutefois que les opérations nécessaires pour lancer cette instance pouvaient elles-mêmes être détectées.
Une telle méthode n'aurait donc pas nécessairement assuré une invisibilité totale.
L'intérêt de la découverte se situe dans la séparation insuffisante entre la configuration utilisée par l'agent et celle chargée de garantir sa surveillance.
Lorsque le composant surveillé peut influencer directement l'activation de son moniteur, la fiabilité du contrôle dépend d'une frontière de sécurité fragile.
Les chercheurs recommandent que l'exécution sans surveillance nécessite des autorisations explicites et distinctes, plutôt qu'un simple paramètre manipulable dans une requête ordinaire.
Des outils considérés comme limités à la lecture présentaient également un risque
L'évaluation a identifié une autre piste concernant deux outils internes accessibles aux agents.
Ces outils étaient considérés comme disposant uniquement de permissions de lecture.
Les chercheurs ont trouvé une méthode susceptible de contourner cette limitation et de permettre certaines actions arbitraires dans leur environnement isolé.
Ils précisent cependant ne pas avoir validé ce comportement jusqu'au bout ni testé son exploitation pratique.
Le constat doit donc rester qualifié comme une vulnérabilité potentielle.
Ce type de problème dépasse le seul domaine de l'intelligence artificielle.
En cybersécurité, un outil annoncé comme étant en lecture seule n'est réellement limité que si le système sous-jacent impose cette restriction.
Le nom de l'outil, son interface ou les instructions données à l'agent ne suffisent pas à garantir l'absence d'opérations d'écriture.
L'utilisation d'agents autonomes rend cette distinction particulièrement importante, puisqu'un logiciel peut combiner plusieurs outils et découvrir des interactions inattendues.
Les systèmes de surveillance fonctionnaient aussi sur plusieurs points
Le rapport ne décrit pas uniquement des échecs.
Les chercheurs ont constaté que, sous réserve de quelques exceptions mineures, les moniteurs recevaient bien la trajectoire complète visible par les agents dans le périmètre observé.
Ils ont également examiné les instructions des moniteurs et confirmé qu'elles cherchaient notamment à identifier la tromperie, le sabotage, l'exfiltration d'informations et les tentatives de manipulation des contrôles.
Les informations techniques communiquées aux évaluateurs indiquaient par ailleurs un taux d'erreur inférieur à 0,2 % pour certaines requêtes du système de surveillance.
Lors d'une période de 24 heures observée pendant l'évaluation, aucune réduction de charge entraînant le rejet de contrôles n'avait été enregistrée.
Ces éléments montrent que l'architecture disposait de mécanismes fonctionnels.
Ils ne neutralisent cependant pas les vulnérabilités découvertes.
Un système peut afficher un faible taux d'erreurs techniques tout en présentant des possibilités de contournement liées à son architecture.
La disponibilité du moniteur et sa résistance à un agent cherchant à le manipuler sont deux propriétés différentes.
OpenAI affirme avoir corrigé les failles touchant la production
Depuis l'exercice, OpenAI indique avoir corrigé toutes les vulnérabilités identifiées qui affectaient ses protections de production.
L'entreprise affirme également avoir considérablement élargi la couverture prévue de son système de surveillance.
Dans sa réaction relayée par Reuters, OpenAI explique que les résultats ont contribué au renforcement de ses protections et serviront à préparer de nouvelles collaborations avec des évaluateurs externes.
Mais METR et Redwood Research précisent explicitement ne pas avoir examiné ces changements ultérieurs.
Ils ne confirment donc ni la correction effective de chaque faille en production ni le niveau actuel de couverture.
Une autre limite tient à la période évaluée.
L'exercice portait sur le système tel qu'il existait au plus tard le 21 juillet, même si les chercheurs ont travaillé jusqu'au 11 août.
Il serait par conséquent trompeur d'affirmer que les vulnérabilités publiées sont encore exploitables dans les systèmes actuels.
Il serait tout aussi excessif de les considérer comme définitivement résolues sur la seule base de déclarations non vérifiées par les évaluateurs.
Le bilan public reste celui d'un audit historique ayant identifié des faiblesses, suivi d'une annonce de remédiation de la part d'OpenAI.
Un rapport de 61 pages dont le public ne connaît qu'une partie
L'organisation de l'évaluation pose également une question de transparence.
METR et Redwood Research ont produit un rapport interne de 61 pages transmis aux équipes de recherche et de sécurité d'OpenAI.
Une version expurgée de 38 pages a été communiquée aux directions des deux organismes.
Le public ne dispose que d'une synthèse présentant plusieurs conclusions et recommandations.
Les parties avaient accepté à l'avance que l'exercice ne donnerait pas lieu à une publication exhaustive.
OpenAI pouvait retirer des informations jugées confidentielles ou sensibles selon les conditions prévues.
Les chercheurs expliquent également que cet accord ne leur donnait pas le même droit de décrire publiquement les suppressions effectuées que dans certaines collaborations précédentes.
Ils approuvent néanmoins les conclusions figurant dans leur publication.
Le choix de ne pas divulguer tous les détails peut être justifié lorsqu'un rapport contient des vulnérabilités exploitables ou des informations confidentielles sur une infrastructure.
Il limite en revanche la capacité du public à examiner indépendamment la portée de certaines conclusions.
METR estime que de futurs exercices devraient prévoir davantage de garanties concernant l'indépendance des évaluateurs et la transparence des résultats.
Une évaluation distincte des incidents impliquant Hugging Face
L'exercice publié le 22 octobre ne doit pas être confondu avec l'enquête conduite précédemment sur des agents internes d'OpenAI impliqués dans un incident affectant Hugging Face.
METR et Redwood Research avaient également participé à l'analyse de cet autre dossier.
Les deux travaux concernent le contrôle des systèmes autonomes, mais ils ne portent pas sur les mêmes événements.
L'enquête concernant Hugging Face cherchait notamment à comprendre des comportements d'agents et leurs interactions au cours d'un incident identifié.
Le nouvel exercice évalue directement les systèmes techniques censés surveiller et encadrer l'activité interne des agents.
Le lien entre les deux sujets est conceptuel : lorsqu'un agent agit de manière inattendue, il faut pouvoir reconstituer ses décisions et ses actions.
Mais l'existence d'un incident antérieur n'est pas une preuve que les failles de surveillance décrites dans la nouvelle étude ont été exploitées au cours de cet incident.
Les chercheurs insistent précisément sur les limites de leurs observations.
Le principe de sécurité à retenir : séparer l'agent de son contrôleur
Les recommandations de METR et Redwood Research reposent sur une idée simple : le système chargé de surveiller un agent ne doit pas dépendre des décisions de cet agent pour fonctionner.
Cela implique de séparer les permissions, les environnements d'exécution et les mécanismes de journalisation.
Un agent ne devrait pas pouvoir désactiver ses propres contrôles au moyen d'un paramètre ordinaire.
Les événements à surveiller devraient être enregistrés par une infrastructure suffisamment indépendante pour résister aux manipulations.
Les journaux doivent être difficiles à modifier et permettre une recherche rapide lorsqu'un incident apparaît.
Les chercheurs recommandent également de comparer les volumes d'activité réellement exécutés aux volumes transmis aux moniteurs.
Une telle comptabilité permettrait de détecter des écarts entre les opérations réalisées et les contrôles effectivement déclenchés.
La surveillance devrait également intervenir pendant les tâches longues, et pas uniquement à leur conclusion.
Enfin, les moniteurs eux-mêmes doivent faire l'objet de tests offensifs réguliers, comme les autres composants critiques d'une infrastructure informatique.
Ces recommandations ne constituent pas la preuve qu'une architecture donnée est parfaitement sûre.
Elles décrivent des principes destinés à réduire les possibilités de contournement identifiées pendant l'étude.
L'indépendance des audits devient un enjeu industriel
Les laboratoires développant des modèles avancés utilisent de plus en plus d'agents pour leurs propres travaux de recherche, d'ingénierie et de sécurité.
Ces agents peuvent agir dans des environnements qui contiennent du code confidentiel, des outils de développement et des ressources techniques importantes.
Les risques ne concernent donc pas uniquement les utilisateurs qui déploient un assistant sur leur ordinateur.
Ils existent également dans les infrastructures internes des entreprises qui conçoivent les modèles.
Une évaluation purement externe peut difficilement déterminer si tous les agents internes sont surveillés ou si certaines catégories d'activité échappent aux contrôles.
L'accès approfondi accordé à METR et Redwood Research constitue une réponse possible à cette difficulté.
Il permet de vérifier des détails que les entreprises ne peuvent pas publier intégralement pour des raisons de sécurité ou de confidentialité.
Mais sa crédibilité dépend du périmètre de l'évaluation, des droits accordés aux chercheurs et de leur liberté de présenter leurs conclusions.
Un organisme indépendant ne peut pas certifier des éléments qu'il n'a pas pu examiner.
C'est pourquoi les chercheurs présentent leur travail comme un pilote méthodologique, plutôt que comme une garantie générale de sûreté.
Ce que l'étude démontre, et ce qu'elle ne démontre pas
Les découvertes de METR et Redwood Research établissent que l'ancien système de surveillance interne d'OpenAI comportait plusieurs faiblesses exploitables ou potentiellement exploitables.
Certaines pouvaient soustraire des actions au contrôle, d'autres concernaient le déclenchement des moniteurs ou les permissions des agents.
L'étude montre aussi que la couverture de surveillance était incomplète dans plusieurs catégories du système historique.
Elle ne démontre pas que tous les agents d'OpenAI cherchaient activement à échapper à leur supervision.
Elle ne prouve pas non plus qu'un agent a utilisé chacune des méthodes découvertes pour réaliser une attaque effective.
Enfin, elle ne permet pas d'évaluer les protections déployées après l'exercice.
OpenAI affirme avoir corrigé les vulnérabilités affectant la production, tandis que les chercheurs précisent ne pas avoir validé les modifications.
Cette distinction résume l'état des connaissances au 23 octobre 2026.
La publication n'est ni la démonstration d'une perte générale de contrôle sur les agents IA ni une certification de la sécurité actuelle d'OpenAI.
Elle apporte une preuve plus précise : des systèmes conçus pour détecter les comportements dangereux peuvent eux-mêmes comporter des angles morts et des chemins de contournement.
À mesure que les agents gagnent en autonomie, leur surveillance devra devenir une infrastructure de sécurité à part entière, soumise à des tests indépendants et conçue pour résister aux manipulations de ce qu'elle observe.