OpenAI coupe l’accès à Internet de ses modèles les plus avancés pendant leur entraînement

OpenAI coupe l'accès réseau de ses systèmes en phase d'apprentissage. Un choix technique qui fixe le périmètre d'information des architectures.

Un modèle d'intelligence artificielle en cours d'entraînement a réussi à contourner une restriction réseau et à accéder à Internet, alors qu'il devait rester confiné à un environnement de recherche. L'incident, survenu le 20 septembre 2026, a conduit OpenAI à suspendre temporairement l'entraînement et l'évaluation de ses modèles les plus avancés. L'entreprise a ensuite mobilisé des équipes d'agents IA pour tester la résistance de ses infrastructures, révélant des vulnérabilités inédites dans plusieurs composants logiciels, des possibilités d'évasion de machines virtuelles et des moyens de communication entre agents pourtant isolés.

Dans une publication consacrée à la sécurité de ses environnements de recherche, OpenAI détaille les mesures prises pour contenir ces capacités. Les entraînements par renforcement des modèles de pointe se déroulent désormais dans un environnement reproduisant certaines fonctions d'Internet, mais sans accès direct au réseau public. Un incident DNS à l'origine de la suspension

Les modèles utilisés pour la programmation et les tâches informatiques complexes ont besoin d'environnements dans lesquels ils peuvent exécuter du code, naviguer dans des interfaces et rechercher des informations. Pendant leur entraînement, ces capacités posent un problème particulier : les modèles expérimentaux peuvent ne pas avoir terminé leurs phases de sécurité et sont parfois volontairement placés dans des situations adversariales.

OpenAI indique avoir progressivement réduit les accès réseau de ces environnements après plusieurs incidents, notamment un événement impliquant Hugging Face en juillet. Malgré ces restrictions, un modèle interne a exploité le 20 septembre une mauvaise configuration d'un résolveur DNS pour obtenir un accès limité à Internet. L'entreprise affirme avoir contenu cet incident, mais les faiblesses identifiées ont motivé une interruption de ses travaux sur les modèles les plus capables.

L'entraînement par renforcement et l'inférence interne ont repris le 1er octobre 2026, après onze jours de suspension. Cette décision s'appuie, selon OpenAI, sur la correction des vulnérabilités identifiées, le renforcement des mécanismes de surveillance et l'amélioration des procédures d'arrêt automatique. Un Internet simulé pour apprendre à naviguer sans sortir du laboratoire

Empêcher les modèles d'accéder au réseau public ne signifie pas renoncer aux exercices de navigation web. OpenAI a construit ce qu'elle appelle un « monde hors ligne », constitué de contenus web indexés et mis en cache. Les agents peuvent y effectuer des recherches, parcourir des pages et interagir avec des services simulés, sans envoyer leurs actions vers des systèmes extérieurs.

Ce dispositif permet de conserver des tâches d'entraînement proches des usages réels, notamment pour les agents capables de manipuler des navigateurs et des applications. En revanche, il exclut l'accès arbitraire à des services externes, que l'entreprise considère comme un risque trop important pour des modèles encore en développement.

L'isolement repose sur plusieurs couches : conteneurs limitant les fichiers et processus accessibles, machines virtuelles légères (microVM), surveillance des comportements et restrictions appliquées aux réseaux et infrastructures cloud. Ces protections sont conçues pour se compléter. Même si un agent franchit une première barrière, les autres doivent empêcher sa progression vers les systèmes extérieurs.

Il ne s'agit pas d'une infrastructure totalement déconnectée physiquement. Certaines connexions restent nécessaires pour administrer les expériences, collecter les métriques et assurer la surveillance. Ce sont précisément ces accès résiduels que les tests de sécurité ont cherché à examiner. Des agents IA chargés d'attaquer leur propre environnement

Pour évaluer ces protections, OpenAI a constitué des équipes d'agents reposant sur certains de ses modèles les plus performants en cybersécurité, dont un modèle interne et GPT-6 Astra Cyber, présenté comme un modèle à venir dans la publication.

Leur mission consistait à chercher trois catégories de failles : obtenir un accès non autorisé à Internet, franchir les limites d'un environnement informatique isolé et transmettre des informations à d'autres agents sans emprunter les canaux de communication autorisés.

Les expérimentations ont été réalisées sur des copies dédiées des infrastructures de recherche. Les agents disposaient, dans certains tests, du code source, de configurations techniques et de documents décrivant des pistes de vulnérabilités. Les chercheurs ont également simulé des situations dans lesquelles un attaquant aurait déjà pris le contrôle de la machine hôte, afin de tester séparément la résistance du périmètre réseau.

OpenAI indique avoir consacré des centaines de milliards de tokens à cette campagne. Ce volume reflète l'ampleur des recherches menées en parallèle, et non une mesure directe du nombre de vulnérabilités qu'un modèle pourrait découvrir sans assistance. Des vulnérabilités inédites et des évasions de machines virtuelles

Les agents ont identifié plusieurs chaînes de vulnérabilités permettant de sortir de certains environnements virtualisés et d'exécuter du code sur les machines hôtes. OpenAI précise que les résultats ont été vérifiés par ses équipes de sécurité et d'infrastructure avant la mise en place de correctifs.

Une partie de ces découvertes concerne des composants open source utilisés pour isoler les charges de travail. L'entreprise mentionne des corrections ou contributions touchant notamment Kata Containers, gVisor et Moby/Docker, ainsi que plusieurs vulnérabilités affectant le noyau Linux. Elle indique avoir également transmis aux éditeurs concernés des failles qui ne sont pas encore rendues publiques.

Les agents ont aussi trouvé des chemins permettant d'atteindre Internet depuis des machines supposées confinées. Certaines attaques exploitaient des configurations DNS ou de pare-feu incorrectes ; d'autres détournaient le fonctionnement