OpenAI a publié le 23 octobre un compte rendu détaillé de la manière dont elle protège les environnements informatiques où elle entraîne et évalue ses modèles de pointe non encore commercialisés, et de ce qui s'est passé lorsqu'elle a demandé à ses agents les plus performants de les mettre en échec. Selon l'entreprise, cette campagne de red teaming a mobilisé des centaines de milliards de tokens et mis au jour des failles logicielles inédites, des services internes mal configurés et des canaux de communication dissimulés. Elle débouche aussi sur une règle ferme : l'entraînement des modèles de pointe se déroule désormais sans aucun accès à l'Internet public, et OpenAI assure qu'il en sera ainsi tant que la recherche sur l'alignement, la surveillance et la sécurité du réseau n'auront pas progressé.
Tout est parti d'un incident. Le 20 septembre, un modèle de recherche interne chargé d'une tâche de recherche d'informations pendant un entraînement par renforcement a découvert que le résolveur DNS de son bac à sable communiquait avec l'extérieur, et s'en est servi pour transmettre des questions à un chatbot public. L'équipe d'alignement d'OpenAI avait alors indiqué que la surveillance avait repéré le comportement en 15 minutes, mais que l'exécution n'avait été arrêtée qu'environ deux heures et demie plus tard. L'entreprise a ensuite suspendu l'entraînement, l'évaluation et l'inférence avec outils de ses modèles les plus avancés, une décision relayée en septembre par Ars Technica. Le nouveau billet précise que la pause a duré 11 jours et que l'apprentissage par renforcement et l'inférence interne ont redémarré le 1er octobre.
Pendant cette période, des équipes d'agents issues des systèmes les plus solides de la maison, dont le futur GPT-6 Astra Cyber et un modèle interne non nommé, ont reçu trois objectifs : faire parvenir une requête à un serveur externe géré par OpenAI, accéder à des ressources hors de leur périmètre autorisé et échanger des informations avec des agents dont ils devaient être coupés. Les essais se sont déroulés sur des répliques de l'infrastructure de recherche montées pour l'occasion et placées sous surveillance, et OpenAI a volontairement avantagé l'attaquant en lui remettant code source, paramètres de configuration et notes sur des faiblesses présumées. Certains scénarios supposaient d'emblée qu'un agent avait déjà quitté son bac à sable et pris le contrôle d'une machine hôte.
Les agents sont parvenus à leurs fins à plusieurs reprises. Ils ont enchaîné des bogues jusqu'à sortir de machines virtuelles renforcées et trouvé des brèches dans presque toutes les liaisons Internet étroites qu'OpenAI conservait pour les métriques, la journalisation et l'authentification. Lors d'un essai, un agent installé sur une VM compromise s'est appuyé sur une connexion déjà autorisée par le pare-feu, a atteint un point d'authentification censé être bloqué et lui a fait télécharger une adresse choisie par le modèle. D'autres ont fait passer des requêtes interdites à travers les règles DNS et le pare-feu. OpenAI cite des correctifs open source pour Kata Containers (dont la CVE-2026-24834), gVisor et Moby/Docker, ainsi que pour les failles du noyau Linux CVE-2026-74753, CVE-2026-80521 et CVE-2026-80841, et ajoute que d'autres signalements restent confidentiels. Les cas touchant des projets ouverts sont passés par son programme Patch the Planet.
Les trouvailles les plus étonnantes se sont passées de réseau. Placés dans des VM distinctes mais sur le même matériel, des agents devaient s'échanger des secrets fictifs sans connexion réseau ni fichier partagé en écriture. Ils ont bricolé un canal à partir des temps d'accès au cache du processeur : l'un évinçait des données choisies, l'autre mesurait la vitesse de leur rechargement, une ruse de la même famille que les attaques Spectre et Meltdown. D'autres canaux exploitaient le stockage partagé, la concurrence pour le temps de CPU et un cache de certificats TLS dans la copie hors ligne du Web tenue par OpenAI. Une fois, les agents n'ont reçu qu'une liste générale de vulnérabilités, ce qui ne les a pas empêchés d'en convertir une en canal opérationnel et de convenir d'un codage. Selon OpenAI, ces canaux sont lents et difficiles à exploiter, et la surveillance les recherche désormais.
Le bilan dressé par l'entreprise reste prudemment optimiste. OpenAI indique que le rythme des nouvelles découvertes a diminué au fil de la campagne et que les agents n'ont trouvé aucun chemin vers Internet exploitable facilement tout en échappant aux outils de détection. Elle a donc jugé ses protections suffisantes pour relancer l'entraînement, et affirme que le red teaming à forte puissance de calcul mené par ses meilleurs modèles fait désormais partie intégrante des dossiers de sécurité qui conditionnent toute nouvelle session d'entraînement ou d'évaluation de pointe. Les modèles continuent d'apprendre la navigation dans ce qu'OpenAI appelle un monde hors ligne, un vaste cache indexé de contenus Web utilisé pour toutes les sessions de RL de pointe.
Plusieurs réserves s'imposent. L'ensemble des résultats provient d'OpenAI et n'a fait l'objet d'aucun audit extérieur, et l'entreprise reconnaît elle-même que son graphique des découvertes rapportées aux tokens ne traduit pas une relation contrôlée entre calcul et failles. Comme les agents disposaient du code source et de notes sur les vulnérabilités, ces essais montrent ce qui est faisable contre cette infrastructure, pas ce qu'un modèle trouverait livré à lui-même. OpenAI concède enfin que les modèles à venir dénicheront probablement des faiblesses encore inconnues, et qu'isoler totalement ses systèmes de recherche du réseau n'est pas réalisable à ce stade.