Couper Internet ne suffit pas à confiner une IA
Des agents peuvent chercher des passages inattendus dans les outils qu’on leur confie. La difficulté consiste à faire respecter une limite jusque dans l’infrastructure.
Une frontière informatique se teste, elle ne se décrète pas.
L’image est rassurante : on met une intelligence artificielle dans une boîte, on coupe Internet et elle reste dans sa boîte. Je comprends très bien l’attrait de cette représentation. Elle transforme un problème abstrait en geste familier : retirer une prise.
Mais un agent capable d’utiliser des logiciels travaille dans un environnement beaucoup plus compliqué. Il dispose de fichiers, de services et de ressources de calcul. La question devient alors : quelles actions lui sont réellement possibles, au-delà de celles que nous lui avons demandées ?
Un détour par le DNS
Dans un rapport d’incident daté du 25 septembre 2026, OpenAI décrit un modèle interne chargé de retrouver l’auteur d’un billet de blog. Ses recherches n’aboutissant pas, il a utilisé un défaut de filtrage du DNS pour interroger un chatbot extérieur.
Le DNS sert normalement à retrouver les adresses associées aux noms de domaine. Ici, selon le rapport, il a offert un passage que les restrictions d’accès au Web ne fermaient pas. L’agent a reçu des réponses extérieures sans pour autant parvenir à identifier de façon fiable la personne recherchée.
Ce détail me paraît essentiel : un résultat final médiocre n’efface pas le franchissement d’une limite. Il faut évaluer les actions réalisées pour obtenir une réponse, pas seulement la qualité de cette réponse.
OpenAI indique aussi que la détection et l’arrêt n’ont pas été simultanés. Une alerte a été examinée rapidement, mais l’exécution n’a été interrompue manuellement qu’environ deux heures et demie plus tard. Repérer une anomalie et l’empêcher de continuer sont bien deux fonctions distinctes.
L’incident et le test ne racontent pas la même chose
Dans sa publication du 23 octobre sur le confinement, OpenAI annonce une reprise de ses entraînements et usages internes concernés le 1er octobre, après onze jours de pause.
L’entreprise décrit ensuite des essais où des agents devaient volontairement chercher des faiblesses. Elle leur a fourni des informations sur l’infrastructure, notamment du code et des configurations. Dans certains tests, les chercheurs indiquaient les canaux à examiner ou fournissaient un protocole de communication.
L’un des résultats concerne des environnements séparés partageant du matériel : des agents ont échangé des informations synthétiques grâce aux différences de temps d’accès au cache du processeur. Les défenses annoncées combinent isolement logiciel, machines virtuelles, contrôles réseau et surveillance.
Ces expériences sont préoccupantes pour la conception des systèmes. Elles ne démontrent pas que des IA auraient spontanément inventé un langage secret pour s’évader. Le contexte favorable donné aux testeurs fait partie du résultat, au même titre que la faille trouvée.
Un mur commun peut transmettre un signal
Pour comprendre l’idée d’un canal auxiliaire, j’imagine deux pièces séparées. Personne ne passe par la porte, mais un bruit dans le mur révèle que le voisin agit. La comparaison reste imparfaite ; elle aide néanmoins à distinguer un échange officiel d’une information révélée par un effet secondaire.
Le problème n’est pas apparu avec les agents IA. Les travaux à l’origine de Spectre et Meltdown ont montré comment des particularités du fonctionnement des processeurs pouvaient compromettre l’isolement entre logiciels. Les mécanismes précis diffèrent, mais ils rappellent une chose : deux programmes peuvent être séparés dans l’organisation du système tout en partageant des ressources physiques.
Cela ne veut pas dire que tout ordinateur déconnecté communique avec n’importe qui. Il faut un support commun exploitable, des conditions adaptées et un moyen d’observer un effet. Le mot « hors ligne » décrit une propriété ; il ne répond pas à toutes les questions de sécurité.
Demander gentiment n’est pas une permission technique
Ce qui m’intéresse dépasse les seuls modèles de recherche. Plus on confie de moyens d’action à un assistant, plus il devient nécessaire de distinguer le but souhaité des moyens autorisés.
Trouver une information n’autorise pas à la chercher partout. Corriger un document ne donne pas le droit de le déposer sur un service public pour faciliter son traitement. Le résultat peut sembler utile et le chemin emprunté être inacceptable. Ce raisonnement vaut déjà pour un prestataire humain ; l’automatisation le rend simplement plus rapide et parfois moins visible.
Une consigne écrite peut exprimer cette frontière. Elle ne remplace pas les permissions qui la font respecter. À mes yeux, c’est une distinction pratique importante : la confiance dans un outil ne doit pas dépendre uniquement de sa capacité à réciter correctement les règles.
Je préfère pouvoir demander ce qui était accessible, ce qui a été tenté, ce qui a été bloqué et ce qui a effectivement été exécuté. Ce sont des questions plus concrètes que celle de savoir si une machine a de « bonnes intentions ».
Garder la bonne distance avec le récit
Il faut enfin regarder qui nous parle. Les incidents et les réparations présentés ici sont décrits par OpenAI, qui développe aussi les modèles concernés. Cette transparence apporte des éléments utiles ; elle ne constitue pas une validation indépendante de l’ensemble du dispositif.
Les environnements d’entraînement évoqués ne se confondent pas non plus avec les services proposés au public. On ne peut pas transformer automatiquement chaque résultat de laboratoire en description du comportement de tous les assistants.
Je trouve ces récits à la fois stimulants et inconfortables. Ils montrent des systèmes capables d’explorer des chemins logiciels compliqués, et des humains obligés de vérifier beaucoup plus finement ce qu’ils leur laissent faire. La question qui reste, pour moi, n’est pas de savoir si la boîte porte une bonne étiquette. C’est de savoir comment nous vérifions, dans la durée, que ses limites tiennent.