OpenAI a suspendu ses travaux impliquant ses modèles d’IA les plus performants après qu’un agent interne a découvert une route inattendue vers l’Internet public depuis un environnement d’entraînement censé être isolé.
L’agent a exploité un filtrage insuffisant du système de noms de domaine, ou DNS, pour communiquer avec un chatbot externe alors qu’il effectuait une tâche de recherche le 20 septembre. Le système de surveillance d’OpenAI a détecté le comportement en quelques minutes, mais l’exécution s’est poursuivie pendant environ deux heures et demie avant d’être interrompue manuellement.
OpenAI a suspendu l’entraînement, l’évaluation et l’inférence impliquant l’utilisation d’outils avec ses modèles les plus performants, le temps de renforcer les contrôles réseau et de mener des tests de sécurité supplémentaires. L’incident met en lumière un défi croissant pour la sécurité de l’IA : contenir des agents autonomes capables de découvrir des moyens de contourner des restrictions que leurs opérateurs pensaient efficaces.
Un agent IA a découvert une autre route vers l’Internet
L’incident a commencé par une mission de recherche.
OpenAI a demandé à un modèle de recherche interne d’identifier une personne à partir de détails biographiques et d’indices tirés d’un article de blog public. La tâche ne demandait pas à l’agent de tester les restrictions réseau ni d’accéder à des informations situées en dehors de son bac à sable.
Lorsque l’outil de recherche qui lui avait été fourni n’a pas produit de résultats utiles, l’agent a toutefois commencé à chercher des solutions de rechange.
Il a tenté d’accéder directement à Google, Bing et DuckDuckGo depuis un shell, mais ces requêtes ont échoué ou ont été redirigées vers le cache web hors ligne d’OpenAI. Une tentative ultérieure de contacter un chatbot externe via HTTPS a été bloquée par le proxy web du bac à sable.
L’agent a alors découvert une autre voie.
Bien que le trafic web classique soit restreint, le résolveur DNS de l’environnement d’entraînement pouvait toujours communiquer avec l’Internet public. L’agent a finalement utilisé un service public de délégation DNS pour transmettre des questions à un chatbot externe.
Après avoir augmenté son délai d’attente et réessayé avec une question de test, l’agent a reçu « La capitale de la France est Paris », confirmant que le chatbot externe répondait via la route DNS.
Il a ensuite envoyé 18 questions supplémentaires par la même route. Quatorze portaient sur des indices issus de sa tâche de recherche initiale, tandis que quatre concernaient des moyens d’effectuer des recherches sur le web, de récupérer des sites ou d’utiliser des services de tunnellisation DNS hébergés publiquement.
OpenAI a qualifié ce comportement d’exemple de désalignement, car l’agent a contourné des restrictions au-delà de ce qui était raisonnablement nécessaire pour mener à bien la tâche qui lui avait été confiée.
OpenAI a détecté l’activité, mais l’exécution s’est poursuivie
Le système de surveillance d’OpenAI a rapidement détecté l’accès externe réussi.
L’agent a reçu une réponse externe à 9 h 50. Le système de surveillance a déclenché son alerte de priorité maximale à 10 h 02, et un examinateur humain l’a prise en compte trois minutes plus tard.
Mais l’exécution ne s’est pas arrêtée automatiquement comme prévu.
OpenAI a déclaré que cela avait semé la confusion quant à la nécessité pour les chercheurs d’intervenir manuellement. Le personnel a finalement interrompu l’exécution à 12 h 34, environ deux heures et demie après la connexion externe réussie.
Un examen rétrospectif a révélé d’autres cas d’accès DNS externe que les systèmes de surveillance n’avaient pas signalés avec le niveau de gravité prévu.
Dans certains cas, des services externes ont renvoyé des avis statiques indiquant qu’ils avaient été arrêtés. OpenAI a déclaré que son système de surveillance interprétait parfois l’absence d’informations utiles comme la preuve que la tentative d’accès à Internet avait échoué.
Un détecteur d’infrastructure conçu pour identifier les activités DNS inhabituelles excluait également l’environnement d’entraînement concerné, bien que le trafic DNS lui-même ait été journalisé.
Ces défaillances illustrent une distinction importante pour les équipes de sécurité : détecter un comportement suspect de la part d’un agent ne suffit pas si les systèmes conçus pour le contenir ne parviennent pas à interrompre l’activité de manière fiable.
OpenAI suspend ses travaux sur ses modèles les plus performants
OpenAI a arrêté l’exécution d’entraînement concernée et élargi sa réponse au-delà du modèle individuel.
« Tous les entraînements, évaluations et inférences avec utilisation d’outils (au sens large) de nos modèles les plus performants restent suspendus », a déclaré l’entreprise.
Cette suspension ne concerne pas tous les développements de modèles d’OpenAI ni les produits grand public existants. Elle s’applique à l’entraînement, à l’évaluation et à l’inférence impliquant l’utilisation d’outils pour les modèles les plus performants de l’entreprise. OpenAI n’a pas identifié les modèles concernés par leur nom.
Les travaux resteront suspendus jusqu’à ce qu’OpenAIvalide que la faille réseau a été comblée et effectue des tests d’équipe rouge supplémentaires.
OpenAI a également déclaré qu’elle ne redémarrerait pas l’entraînement du modèle concerné. À la place, les futurs entraînements commenceront par une nouvelle exécution intégrant des mesures de protection supplémentaires en matière d’alignement.
OpenAI renforce ses contrôles DNS
OpenAI a déclaré avoir ajouté des contrôles de blocage à deux niveaux indépendants, dont chacun aurait empêché l’accès externe.
L’entreprise a également limité les requêtes DNS au sein de l’environnement à une liste restreinte de domaines et de types d’enregistrements autorisés, et déploie des mécanismes de détection et des tests DNS supplémentaires.
OpenAI étend les exercices d’équipe rouge assistés par des modèles sur son bac à sable et ses contrôles réseau afin de rechercher d’autres routes indirectes vers Internet. L’entreprise a déclaré que ces tests pourraient révéler d’autres chemins, qu’elle prévoit de corriger tout en suspendant les charges de travail de recherche lorsque cela sera nécessaire.
L’incident fait suite à un précédent échec de confinement impliquant Hugging Face. OpenAI a déclaré que le dernier événement était « beaucoup moins grave », mais important, car il s’agissait du premier incident de ce type depuis que l’entreprise avait renforcé son environnement de recherche à la suite de l’événement précédent.
Mais le Dr Ilia Kolochenko, fondateur d’ImmuniWeb, a contesté la présentation de l’incident par OpenAI ainsi que les avertissements plus larges concernant des modèles d’IA toujours plus puissants.
« Cette annonce semble n’être que la continuation de la campagne de peur, d’incertitude et de doute (FUD) menée par les fournisseurs d’IA qui se préparent actuellement à leurs introductions en Bourse de plusieurs milliards de dollars », a déclaré Kolochenko à eSecurity Planet.
« Techniquement parlant, la déclaration d’OpenAI revient essentiellement à admettre que sa technologie d’IA ne vaut rien, puisqu’elle ne peut ni la contrôler ni la gérer », a ajouté Kolochenko.
Il a comparé les agents IA incontrôlés au fait de disposer de capacités importantes sans contrôle fiable, estimant que des modèles prétendument puissants et des « agents renégats » peuvent finalement créer « plus de tort que de valeur ».
Les agents IA compliquent la sécurité des bacs à sable
Pour les équipes de sécurité, l’incident montre pourquoi le confinement des agents IA autonomes exige davantage que de simples instructions indiquant à un modèle ce qu’il peut ou ne peut pas faire.
Une tâche de recherche légitime avait été confiée à l’agent. Lorsque les recherches classiques ont échoué, il a toutefois exploré d’autres moyens d’obtenir l’information et découvert une voie réseau que ses opérateurs ne lui avaient pas destinée.
Les organisations qui déploient des agents capables de naviguer sur le web, d’exécuter du code, d’accéder à des API ou d’interagir avec des systèmes internes doivent donc imposer des limites en dehors du modèle lui-même. Les listes blanches réseau, la résolution DNS restreinte, les identifiants dotés des privilèges minimaux, les environnements d’exécution isolés, une journalisation exhaustive et des contrôles d’arrêt indépendants peuvent limiter les conséquences d’un comportement inattendu.
L’expérience d’OpenAI montre également pourquoi la surveillance doit faire la distinction entre l’échec d’un agent à atteindre son objectif et son échec à franchir une frontière de sécurité. Dans certains cas, son système de surveillance a interprété l’absence d’informations utiles comme la preuve qu’une tentative d’accès à Internet avait échoué, alors même qu’un accès externe avait eu lieu.
Pour les entreprises qui déploient une IA toujours plus autonome, la leçon n’est pas que chaque agent cherchera délibérément à rompre son confinement. C’est que les contrôles de sécurité doivent partir du principe qu’un agent peut découvrir des chemins que ses développeurs n’avaient pas anticipés.
Un bac à sable n’est isolé qu’à la mesure de l’isolation de chaque service réseau et outil qui y est disponible.
Par ailleurs, des attaquants exploitent activement Microsoft SharePoint CVE-2026-65660, une faille d’exécution de code à distance de gravité 8,8 touchant les serveurs sur site