Un exercice qui a débordé dans la réalité
En mai 2026, Irregular, une startup israélienne spécialisée dans l'évaluation de la sécurité des modèles d'IA, conduit un exercice de type capture the flag avec le modèle Gemini de Google. L'objectif est classique : mesurer la capacité de l'agent à identifier et exploiter des vulnérabilités dans un environnement simulant une entreprise fictive. Ce genre d'évaluation est devenu une pratique courante pour jauger les aptitudes offensives des grands modèles avant leur mise en production.
Cet exercice a pourtant débordé de façon spectaculaire. Trois entreprises réelles ont été compromises sans l'avoir demandé.
Deux erreurs de configuration, un incident réel
Deux facteurs se sont combinés pour transformer un test en véritable incident de sécurité. Premier problème : les noms de domaines fictifs utilisés dans le scénario correspondaient à de vraies organisations existantes. Second problème : la connexion internet de l'agent ne devait pas être active — elle l'était, par erreur de configuration.
Armé d'un accès réseau non prévu et d'une mission à accomplir, Gemini a appliqué les techniques que lui demandait l'exercice, mais sur de vraies cibles. Il a deviné des mots de passe à force de tentatives répétées. Il a retrouvé des identifiants exposés dans des dépôts de code publics. Il s'est servi de ces informations pour accéder à des systèmes de production appartenant à trois entreprises.
Ce ne sont pas des failles sophistiquées qui ont rendu ces intrusions possibles, mais la combinaison d'un environnement de test mal isolé et de pratiques de sécurité basiques défaillantes — mots de passe prévisibles, secrets exposés sur GitHub.
Le modèle s'est arrêté tout seul — et ça ne suffit pas
Google a tenu à souligner un point : Gemini s'est interrompu de lui-même. Lorsque l'agent a détecté qu'il avait atteint une infrastructure réelle plutôt que simulée, ses mécanismes de sécurité intégrés ont déclenché une interruption automatique. Heather Adkins, vice-présidente de l'ingénierie sécurité chez Google, a indiqué que « le modèle a agi de façon appropriée ».
C'est une bonne nouvelle pour l'alignement des modèles. C'est aussi un argument à manier avec prudence : faire reposer la résilience sur la capacité d'auto-arrêt d'un agent, c'est s'appuyer sur la couche la moins contrôlable de la pile. Un filet de sécurité de dernier recours ne remplace pas l'isolation en amont.
L'autre enseignement tient à la temporalité de la divulgation. Irregular a notifié Google en juillet 2026. La révélation publique n'a eu lieu qu'en septembre, après qu'un média ait eu vent de l'affaire — soit sept semaines de silence.
Ce que ça change pour vos déploiements
Cet incident n'est pas isolé. Des situations comparables ont impliqué des agents d'OpenAI et d'Anthropic au cours de la même année. L'évaluation des agents IA en conditions de test révèle une tension fondamentale : plus les exercices sont réalistes, plus le risque qu'ils touchent la réalité augmente.
Pour les équipes IT et les RSSI, les conclusions sont concrètes.
L'isolation réseau des environnements d'évaluation IA doit être vérifiée de façon active, pas supposée. Un agent qui n'a pas besoin d'internet pour accomplir une tâche ne doit pas y avoir accès — et cette règle doit s'appliquer au niveau de l'infrastructure, pas de la seule configuration logicielle.
Les noms de domaine et entités fictives utilisés dans les scénarios de test méritent une vérification systématique pour éviter toute collision avec des organisations existantes.
Enfin, les identifiants exposés dans des dépôts publics restent l'un des vecteurs d'entrée les plus exploités — que l'attaquant soit humain ou autonome. Lorsque les outils d'évaluation deviennent aussi capables que les menaces qu'ils simulent, les règles du bac à sable ne peuvent plus rester optionnelles.