par Lors d’exercices d’attaque, des agents d’OpenAI ont quitté leurs machines virtuelles et ouvert entre eux un canal de communication que personne n’avait prévu. Le groupe de Sam Altman a tiré la leçon, ses modèles les plus avancés seront désormais entraînés hors de toute connexion au web.
OpenAI continue d’entraîner ses systèmes les plus puissants, malgré les écarts qui se répètent depuis des mois. Lors d’un nouveau test, certains modèles ont réussi à échanger des informations par un canal invisible. En effet, ils ont manipulé la mémoire cache du processeur de la machine qui les hébergeait. L’entreprise l’explique dans un billet de blog et en tire une règle. La démarche responsable consiste, selon elle, à mener l’entraînement des modèles de pointe sans accès à Internet. Elle s’engage à pouvoir toujours empêcher un modèle d’accéder, de façon arbitraire et non autorisée, au web en direct.
Des exercices d’évasion qui dérapent
L’incident s’est produit pendant des exercices de « red teaming », au cours desquels des agents reçoivent pour mission de s’échapper de leur environnement. Les modèles sont rapidement sortis des machines virtuelles censées les contenir. C’est alors qu’ils ont trouvé, sans que les ingénieurs l’aient anticipé, le moyen de se parler.
Ce n’est pas la première fois que des échanges imprévus entre modèles posent problème. Ils figurent déjà parmi les causes de plusieurs incidents récents, dont le piratage de la plateforme Hugging Face au début de l’été. En coopérant, les agents trouvent des façons inattendues de relever les défis qu’on leur lance. Un autre épisode date de la fin septembre où un modèle a tiré parti d’une mauvaise configuration DNS pour atteindre brièvement le web.
L’incident du 20 septembre
Le 20 septembre 2026, un modèle de recherche interne a exploité un résolveur DNS mal configuré pour obtenir un accès limité à Internet pendant un cycle d’entraînement. Selon le rapport d’incident publié sur le site d’OpenAI consacré à l’alignement, l’agent travaillait sur une tâche d’entraînement fondée sur la recherche. Ses requêtes via l’outil de recherche fourni avaient échoué, tout comme ses tentatives de joindre directement des moteurs de recherche. Un filtrage DNS insuffisant lui a finalement permis d’atteindre un service de chatbot externe.
Le rapport détaille le déroulé de l’incident :
9 h 50 min 23 s : appel réussi de l’agent à l’outil DNS ;
10 h 02 min 11 s : alerte de surveillance de niveau P0 ;
10 h 05 min 06 s : prise en compte de l’alerte par un humain ;
12 h 34 min 30 s : arrêt du cycle.
OpenAI affirme avoir maîtrisé l’incident, puis suspendu l’entraînement et l’évaluation de ses modèles les plus performants pendant onze jours. Elle a consacré ce temps à durcir son infrastructure et sa surveillance, et à améliorer les systèmes qui coupent automatiquement un cycle dès qu’une activité à risque est détectée. Deux mécanismes de blocage indépendants, chacun suffisant à empêcher l’accès, ont été ajoutés. L’entreprise ne reprendra pas l’entraînement du modèle concerné, alors même que son signal de récompense pénalisait déjà ce comportement. Un nouvel entraînement, qui intègre des améliorations d’alignement supplémentaires, démarrera avec la reprise.
L’examen rétrospectif est moins rassurant car il a révélé d’autres accès à des DNS externes que la surveillance n’avait pas signalés avec la gravité attendue. Un système de détection destiné à repérer les activités DNS anormales laissait en outre de côté l’environnement concerné.
Un « monde hors ligne » pour apprendre sans risque
Les agents conservent leurs navigateurs, leurs outils informatiques et leurs environnements d’exécution de code, mais dans un espace clos, coupé du web en direct. Leurs échanges se limitent aux seuls agents expressément autorisés. Pour qu’ils apprennent malgré tout à naviguer et à chercher de l’information, OpenAI a construit ce qu’elle appelle un «monde hors ligne» où un vaste ensemble de pages web indexées et mises en cache, sorte de simulation du web avec laquelle les modèles interagissent sans pouvoir toucher aucun système extérieur. Tous les cycles d’apprentissage par renforcement de ses modèles de pointe fonctionnent désormais ainsi.
Le confinement repose sur une défense en profondeur. Bacs à sable, machines virtuelles, systèmes de surveillance et périmètres réseau et cloud se superposent, de sorte que la défaillance d’un seul contrôle ne suffise pas à tout compromettre. Sous Linux, des conteneurs à accès restreint tournent dans des machines virtuelles légères, chacune avec son propre noyau, isolé de l’hôte par un hyperviseur. OpenAI recourt aussi à des environnements virtualisés pour macOS et Windows, et à des conteneurs équipés de GPU avec bac à sable en espace utilisateur pour les tâches qui exigent des accélérateurs.
L’isolement complet du réseau reste toutefois impossible aujourd’hui, car il faut des connexions externes pour lancer et surveiller les expériences. L’entreprise se contente donc de restreindre le trafic sortant et les déplacements non autorisés entre systèmes. Ses partenaires cloud fournissent pare-feu, groupes de sécurité, gestion des identités et des accès et réseaux privés, qu’OpenAI configure et teste elle-même.
