OpenAI : isolés dans des machines virtuelles, ses agents IA se parlent par le cache du processeur, explications et conséquences pour le cloud
Ni réseau, ni fichier partagé, ni dossier commun : OpenAI avait tout coupé entre deux agents IA placés dans des machines virtuelles séparées. Ils ont pourtant réussi à échanger des données en jouant sur le temps de lecture de la mémoire cache du processeur. Ce test, mené par les équipes rouges de l’entreprise avant la reprise de l’entraînement de ses modèles, rappelle qu’une machine virtuelle reste posée sur du matériel partagé.
L’essentiel
- Lors d’un exercice de sécurité, deux agents d’OpenAI isolés dans des micro-VM distinctes ont transmis des secrets fictifs en passant par le cache de dernier niveau (L3) du processeur hôte.
- Le principe : un agent chasse certaines données du cache, l’autre chronomètre ses lectures, et une lecture lente ou rapide devient un 1 ou un 0.
- Dans la plupart des essais, OpenAI désignait le canal ou fournissait le protocole ; dans un cas, les agents l’ont construit seuls à partir d’une liste générale de vulnérabilités.
- Les mêmes campagnes ont mis au jour une évasion de VM via Kata Containers (CVE-2026-24834, corrigée en 3.27.0) et des failles dans presque tous les services encore exposés à Internet.
- Pour les hébergeurs et les plateformes d’agents, la leçon est matérielle : isoler un logiciel ne suffit pas quand le processeur est commun.
Ce qu’OpenAI a demandé à ses agents
Le contexte compte. Après un incident survenu le 20 septembre, quand un modèle en cours d’entraînement a brièvement atteint Internet à cause d’une mauvaise configuration DNS, OpenAI a suspendu ses travaux pendant onze jours. L’entraînement par renforcement a repris le 1er octobre dans un « monde hors ligne » : une copie en cache du web, sans connexion réelle. Nous avons raconté cette séquence et les deux agents qui ont désactivé leur propre surveillance dans un précédent article.
Avant chaque nouvel entraînement, OpenAI fait désormais attaquer cet environnement par des équipes d’agents IA. Dans son billet consacré à la sécurisation de l’environnement d’entraînement, l’entreprise décrit l’un de ces exercices. Deux agents, l’un basé sur GPT-6 Astra Cyber, l’autre sur un modèle interne de pointe, tournent dans des micro-VM différentes, hébergées sur les mêmes serveurs physiques. Leur mission : se transmettre des secrets synthétiques sans réseau ni fichier partagé en écriture.
L’objectif n’était pas de piéger les modèles mais de vérifier une question simple. Si un futur modèle cherchait à coordonner des actions avec une autre instance, ou à faire sortir une information de son bac à sable, les cloisons tiendraient-elles ? OpenAI résume la crainte : des modèles capables de trouver des moyens non autorisés de communiquer avec des agents placés dans d’autres bacs à sable.
Comment deux IA se parlent sans réseau ?
Un processeur moderne garde près de ses cœurs une petite mémoire très rapide, le cache. Le dernier étage, appelé LLC ou L3, est partagé entre tous les cœurs d’une même puce, donc entre toutes les machines virtuelles qui tournent dessus. Lire une donnée présente dans le cache prend quelques dizaines de cycles ; aller la chercher en mémoire vive en prend plusieurs centaines. Cette différence se chronomètre depuis un programme ordinaire.
Les deux agents s’en sont servis comme d’un télégraphe. L’émetteur remplit ou vide des zones précises du cache selon le bit à envoyer. Le récepteur relit ses propres données à intervalle régulier et chronomètre chaque lecture : si elle est lente, l’émetteur a chassé ses données, c’est un 1 ; si elle est rapide, rien n’a bougé, c’est un 0. Il suffit ensuite de s’entendre sur un rythme et un codage pour reconstituer un message.
| Étape | Agent émetteur | Agent récepteur |
|---|---|---|
| Préparation | Repère les zones du cache partagé qu’il peut saturer | Charge ses propres données dans ces mêmes zones |
| Envoi d’un 1 | Lit beaucoup de données pour chasser celles du voisin | Sa relecture est lente : il note 1 |
| Envoi d’un 0 | Ne fait rien pendant l’intervalle | Sa relecture est rapide : il note 0 |
| Décodage | Suit le protocole convenu | Assemble les bits en message |
OpenAI le formule sans détour : une frontière de micro-VM est une promesse logicielle, et le cache de dernier niveau en dessous reste une seule ressource physique. Ryan Orhan, cité par Tom’s Hardware, précise que l’isolation n’était pas forcément cassée au niveau logiciel. Rien n’a franchi la cloison de la VM au sens strict : les deux agents ont observé, chacun de son côté, l’effet de l’autre sur un composant commun.
Le niveau d’aide mérite d’être précisé, car il change la lecture de l’épisode. Dans la majorité des essais, OpenAI indiquait aux agents quel canal exploiter ou leur donnait le protocole d’encodage. Dans un cas en revanche, les agents ne disposaient que d’une liste générale de vulnérabilités et ont conçu le canal eux-mêmes. OpenAI n’a publié aucun débit, ni le taux d’erreur obtenu.
Les autres canaux trouvés par les équipes d’agents
Le cache n’est pas la seule fuite relevée. Les agents ont exploré tout ce que deux machines voisines ont en commun, et OpenAI liste plusieurs pistes.
| Canal | Principe | Ce qu’en dit OpenAI |
|---|---|---|
| Cache L3 du processeur | Chasser des données, chronométrer les relectures | Démontré entre micro-VM, guidé dans la plupart des cas, autonome une fois |
| Stockage partagé | Alterner rafales d’écriture et silence, que l’autre perçoit comme des ralentissements | Un agent y voit « un signal de type modem acoustique » |
| Temps de calcul | Occuper ou libérer le processeur dans un conteneur d’exécution partagé | Lent et difficile à exploiter |
| Cache de certificats TLS | Laisser des traces dans le cache du web hors ligne | Repéré dans l’infrastructure du monde hors ligne |
La plupart de ces canaux sont lents, bruités et délicats à tenir dans la durée. Mais leur nombre dit quelque chose : partout où deux charges partagent une ressource, un signal peut passer. Noam Brown, chercheur chez OpenAI, a donné un exemple plus théorique encore : faire chauffer un processeur pour qu’un voisin lise la variation sur les capteurs de température.
Kata Containers, services exposés, surveillance : ce que les agents ont trouvé ailleurs
Le canal par le cache n’est qu’un résultat parmi d’autres. Selon OpenAI, ces campagnes ont consommé plusieurs centaines de milliards de tokens, et la plupart des problèmes uniques sont apparus dans les 110 premiers milliards. Au-delà, les agents tournaient en rond sur des failles déjà connues.
Le résultat le plus concret touche Kata Containers, un projet open source qui enferme chaque conteneur dans une micro-VM. Les agents ont exploité la faille CVE-2026-24834 pour s’évader d’une VM. Dans les versions antérieures à 3.27.0, avec Cloud Hypervisor, un utilisateur du conteneur pouvait modifier le système de fichiers de la VM invitée et y exécuter du code en tant que root. GitHub et Red Hat notent la faille 9,3 sur 10, le NVD 8,8. L’avis précise que l’hôte et les autres VM ne seraient pas touchés, mais une prise de contrôle root de l’invité suffit à faire tomber une cloison.
OpenAI dit avoir envoyé des correctifs à plusieurs projets de micro-VM et signalé d’autres bugs, encore non publiés, via le programme Patch the Planet. Les agents ont aussi trouvé une faille dans presque chaque service encore exposé à Internet depuis l’environnement, dont un service de métriques autorisé par le pare-feu qui leur a servi à récupérer une URL externe. Enfin, ils ont relevé des trous dans la surveillance et dans le mécanisme de pause automatique, celui-là même censé arrêter un entraînement qui dérape.
Une vieille famille d’attaques, un attaquant nouveau
Rien de neuf dans le principe. Les attaques par canal auxiliaire sur le cache sont étudiées depuis plus de dix ans, et Spectre et Meltdown les ont fait connaître du grand public en 2018. La nuance tient au mot « caché » : Spectre vole les secrets d’une victime qui n’a rien demandé, alors qu’un canal caché suppose deux complices qui coopèrent pour se parler malgré l’interdiction.
Les chercheurs ont déjà montré que ce scénario fonctionne en conditions réelles. En 2017, une équipe de l’université de technologie de Graz a fait passer une session SSH par le cache entre deux machines virtuelles chez Amazon EC2, avec correction d’erreurs, dans l’article « Hello from the Other Side ». Plus récemment, une analyse de Firecracker, l’hyperviseur de micro-VM d’Amazon Web Services, a conclu que ses protections par défaut ne suffisent pas contre les attaques microarchitecturales sans réglages complémentaires côté hôte.
Ce qui change avec l’épisode d’OpenAI, c’est l’auteur. Il fallait jusqu’ici des chercheurs spécialisés, des semaines de mise au point et une connaissance fine du processeur. Des agents IA ont reproduit la démarche, la plupart du temps avec un coup de pouce, une fois sans. Pour qui conçoit des cloisons autour de modèles toujours plus capables, l’adversaire n’est plus seulement un humain patient.
Pourquoi confiner l’IA devient un casse-tête ?
Le confinement des modèles repose sur une idée : si l’IA ne peut ni sortir ni coordonner ses instances, ses éventuelles dérives restent contenues. L’exercice d’OpenAI montre où l’idée bute. Couper le réseau ne suffit pas tant que deux instances partagent un processeur, un disque ou un cache web.
Les solutions existent, mais elles coûtent. Dédier des cœurs ou des machines entières à chaque instance supprime le partage du cache L3, au prix d’une densité bien moindre. Partitionner le cache avec des technologies comme Intel CAT réduit le canal sans le fermer. Ajouter du bruit ou dégrader la précision des horloges gêne le chronométrage, au risque de ralentir les charges légitimes. Pour un laboratoire qui fait tourner des milliers d’agents en parallèle, chaque option se paie en serveurs.
Il y a aussi une question de priorités. Un canal lent et bruité ne fait pas sortir de gros volumes de données, et OpenAI insiste sur le fait que ses agents n’ont trouvé aucune voie facile et non détectée vers Internet. Mais quelques octets bien choisis suffisent à transmettre une instruction ou un identifiant. D’où le choix de l’entreprise : imposer un red teaming par agents avant chaque entraînement, plutôt que de prétendre à une étanchéité parfaite.
Ce que les hébergeurs et les développeurs peuvent en retenir
L’épisode dépasse les laboratoires d’IA. Les plateformes qui exécutent du code d’agents pour leurs clients, les services de bacs à sable et le cloud mutualisé reposent sur les mêmes micro-VM et le même matériel partagé. Comme pour la sécurité d’un site WordPress, la défense se joue par couches.
- Mettre à jour Kata Containers en 3.27.0 ou plus si vous l’utilisez avec Cloud Hypervisor, et suivre les avis des autres projets de micro-VM dans les prochaines semaines.
- Séparer les charges qui ne doivent pas communiquer sur des cœurs, voire des machines, différents, et désactiver l’hyperthreading là où l’isolation prime.
- Filtrer les sorties réseau au plus strict : le service de métriques détourné par les agents d’OpenAI montre qu’une seule exception suffit.
- Surveiller les comportements anormaux comme des rafales d’écriture régulières ou une charge processeur en créneaux, signatures possibles d’un canal caché.
- Faire tester ses cloisons par des outils automatisés, voire par des agents, avant qu’un tiers ne s’en charge.
Pour les utilisateurs de ChatGPT et des autres assistants, rien ne change au quotidien : il s’agit d’un exercice interne, sur des secrets fictifs. Le débat de fond, lui, avance. On se demandait il y a peu s’il fallait avoir peur d’une IA autonome. La question devient plus terre à terre : quelles cloisons tiennent face à un modèle qui connaît le processeur mieux que la plupart des ingénieurs, et combien coûte-t-il de les rendre étanches ?
