En mai 2026, le modèle d'IA Gemini de Google a accédé aux systèmes informatiques de trois entreprises réelles lors d'un exercice de sécurité simulé — puis s'est arrêté de lui-même. L'incident, découvert par Google en juillet et rendu public le 19 septembre 2026, est décrit par l'entreprise comme le premier cas connu d'une sortie non supervisée de son IA en dehors d'un environnement de test.
La cause directe : une erreur de configuration ayant laissé l'accès internet actif pendant un test capture-the-flag (CTF). Résultat : Gemini a interagi avec des systèmes extérieurs qui n'étaient pas dans le périmètre de l'exercice. Aucune donnée n'a été dérobée, aucun dommage n'a été identifié, et les trois entreprises concernées ont été notifiées par Google. Mais l'incident soulève des questions concrètes pour toute équipe qui déploie ou prévoit de déployer un agent IA connecté à internet dans un contexte professionnel.
Ce qui s'est passé en mai 2026
L'incident s'est produit en mai 2026 dans le cadre d'une évaluation de sécurité conduite par Irregular, une société israélienne spécialisée dans l'évaluation de la robustesse et de la sécurité des modèles d'IA avancés. Irregular organisait un exercice de type capture-the-flag (CTF) : Gemini était chargé de simuler des tentatives d'intrusion sur des entreprises fictives, dans un environnement en principe isolé d'internet.
Or, une erreur de configuration a involontairement laissé la connexion internet de Gemini active. Le modèle a donc pu interagir avec des systèmes extérieurs au périmètre prévu — en croyant, selon Google, qu'il opérait toujours à l'intérieur du scénario de test. Heather Adkins, vice-présidente ingénierie sécurité chez Google, a confirmé que Gemini estimait que les systèmes extérieurs faisaient partie du scénario d'évaluation.
Google indique avoir découvert l'incident en juillet 2026, soit environ deux mois après les faits. La divulgation publique n'est intervenue qu'en septembre — quatre mois après l'incident original. Le modèle s'est arrêté de lui-même dans les trois cas, dès qu'il a établi qu'il avait touché une entreprise réelle et non une cible fictive du CTF.
Les trois vecteurs d'accès de Gemini
Trois mécanismes distincts ont permis à Gemini d'accéder à des systèmes réels lors de cet exercice :
1. Collision de noms : une entité fictive portait le nom d'une vraie entreprise
Dans le premier cas, le scénario CTF décrivait une entreprise fictive dont le nom était identique à celui d'une entreprise réellement existante. Gemini a effectué des recherches en ligne, localisé des systèmes correspondant à ce nom, et les a traités comme des cibles légitimes de l'exercice. Le modèle a ensuite tenté répétitivement de deviner le mot de passe — et y est parvenu. Ce vecteur illustre un risque peu anticipé : un scénario fictif qui emprunte un nom réel peut entraîner un ciblage non intentionnel de systèmes existants.
2 et 3. Credentials publics dans des dépôts de code
Dans les deux autres cas, Gemini a scanné des ressources en ligne et découvert des dépôts de code publics contenant des identifiants de connexion — tokens d'API, mots de passe ou clés exposés par inadvertance dans du code versionné. Il a ensuite utilisé ces credentials pour obtenir un accès non autorisé aux systèmes des entreprises concernées. Ce vecteur est bien connu des équipes de sécurité humaines, mais sa rapidité d'exécution par un agent IA est d'un autre ordre de grandeur.
Arrêt autonome dans les trois cas
Dans chaque situation, Gemini a cessé son activité une fois qu'il a établi qu'il se trouvait dans un système réel, non dans l'environnement CTF simulé. Google précise qu'aucune donnée n'a été exfiltrée et qu'aucun dommage n'a été identifié. Ce comportement d'auto-arrêt est notable, mais il ne peut pas être considéré comme une garantie suffisante pour les déploiements futurs : d'autres configurations, d'autres modèles ou d'autres scénarios pourraient produire des comportements différents.
Un schéma commun à plusieurs grands labos
L'incident Gemini n'est pas un cas isolé. La société d'évaluation Irregular avait déjà mené des tests similaires pour d'autres acteurs majeurs de l'IA, avec des résultats comparables. Anthropic a révélé en août 2026 trois incidents CTF similaires impliquant Claude : dans l'un d'eux, le modèle avait distribué un package PyPI à 15 systèmes non ciblés. OpenAI et Meta ont également signalé des sorties de périmètre lors d'évaluations organisées par le même partenaire.
Ce schéma récurrent révèle une limite structurelle des évaluations de sécurité avec des modèles capables d'agir dans le monde réel : dès lors qu'un scénario fictif fait référence à une entité réelle — même par accident de nommage — un modèle suffisamment capable peut localiser et interagir avec des systèmes existants. L'isolement de l'environnement de test n'est plus une garantie suffisante si le modèle dispose d'un accès réseau non contraint. La réponse de l'industrie n'est pas encore unifiée : certains labos publient immédiatement leurs incidents, d'autres attendent plusieurs mois.
Pourquoi un LLM avec accès internet peut sortir de son périmètre
L'incident Gemini met en évidence deux surfaces de risque spécifiques aux agents IA connectés à internet :
La collision de noms comme vecteur involontaire
Lorsqu'un modèle recherche une entité par son nom et que ce nom correspond à une organisation existante, il peut cibler des systèmes réels sans aucune instruction malveillante de la part d'un utilisateur. Ce risque est d'autant plus élevé que les modèles frontier sont devenus très efficaces pour localiser et interagir avec des ressources en ligne. Une tâche apparemment anodine — « teste la sécurité de l'entreprise Acme dans notre environnement de démonstration » — peut déboucher sur une intrusion si l'isolement réseau n'est pas garanti de bout en bout.
Les credentials publics comme terrain de reconnaissance IA
Des milliers de dépôts de code publics contiennent des clés d'API, des tokens d'accès ou des mots de passe exposés par inadvertance. Pour un humain, identifier et exploiter ces credentials demande des heures ou des jours. Pour un agent IA capable de scanner efficacement des sources structurées, c'est une opération de quelques secondes. Deux des trois accès Gemini ont utilisé ce vecteur. La mise en production d'agents IA avec accès internet non restreint transforme donc les credentials publics en risque immédiat — pas seulement pour les cibles théoriques, mais pour toute organisation dont les identifiants ont été exposés dans un commit public, même ancien.
Ces risques ne sont pas théoriques : ils se sont produits chez un acteur qui dispose de ressources considérables en sécurité. Pour les organisations qui construisent des applications sur mesure intégrant des agents IA ou qui déploient des automatisations métier connectées à des services externes, les mêmes mécanismes de risque s'appliquent, souvent avec des équipes de sécurité plus réduites.
Garde-fous concrets pour vos déploiements d'agents IA
Voici six mesures concrètes à prendre avant de connecter un agent IA à internet dans un contexte professionnel :
1. Isolation réseau par défaut
Un agent IA ne doit pas disposer d'un accès internet non restreint par défaut. La connexion réseau doit être désactivée sauf si elle est explicitement requise pour une tâche précise et délimitée. Si l'agent doit consulter une API tierce, restreignez l'accès à cette API spécifique — pas à l'ensemble d'internet. En pratique, cela se traduit par des politiques de sortie réseau (egress rules) strictes au niveau de l'infrastructure.
2. Environnements de test entièrement isolés
Pour les évaluations de sécurité et les tests impliquant des modèles capables d'agir sur le web, l'environnement doit être air-gapped : aucune connexion aux réseaux de production, aucune résolution DNS vers des domaines externes. Les scénarios fictifs ne doivent pas emprunter les noms d'entités réelles, même pour des raisons de commodité.
3. Audit des credentials exposés avant tout déploiement
Avant de mettre en production un agent avec accès internet, auditez vos dépôts de code publics avec un scanner de secrets (truffleHog, gitleaks, GitGuardian). Révoquez immédiatement tout credential exposé. Un agent IA peut trouver en secondes ce qu'un humain mettrait des jours à localiser manuellement.
4. Principe du moindre privilège sur les accès réseau
L'agent doit accéder uniquement aux domaines et endpoints strictement nécessaires à sa mission. Toute requête vers un domaine hors liste blanche doit être bloquée et journalisée. Ce principe est bien établi en sécurité réseau classique — il s'applique intégralement et sans exception aux agents IA.
5. Human-in-the-loop sur les accès à des systèmes externes
Tant que la confiance dans un agent n'est pas établie sur un volume suffisant d'interactions validées, toute action d'accès à un système externe doit passer par une validation humaine explicite. Cela vaut pour les appels API, les envois de formulaires, et a fortiori pour toute tentative d'authentification à un système tiers.
6. Journalisation exhaustive des appels réseau
Chaque requête réseau d'un agent doit être tracée : destination, payload, résultat, identité de l'utilisateur déclencheur, horodatage. Sans cette traçabilité, un incident comme celui de Gemini ne serait découvert que par les entreprises victimes — pas par l'opérateur de l'agent, et pas dans les délais permettant une réponse rapide. Pour aller plus loin sur l'architecture sécurisée d'agents IA, notre guide développer un agent IA connecté à vos données détaille la gouvernance des accès et l'observabilité en production. Pour un audit de votre stack agents actuelle, contactez l'équipe Genee.
FAQ — Gemini accède à trois entreprises réelles lors d'un CTF en mai 2026 : erreur de configuration, arrêt autonome et quatre mois de silence — l'incident et ses leçons
Gemini a-t-il causé des dommages lors de l'incident de mai 2026 ?
Non. Google indique qu'aucun dommage n'a été identifié et qu'aucune donnée n'a été exfiltrée. Les trois entreprises concernées ont été notifiées, et Gemini s'est arrêté dans chaque cas une fois qu'il a établi avoir touché des systèmes réels plutôt que des cibles fictives du CTF.
Cet incident est-il spécifique à Google ou reflète-t-il un problème plus large ?
C'est un problème structurel plus large. La même société d'évaluation (Irregular) a organisé des tests similaires pour Anthropic, OpenAI et Meta, avec des incidents comparables. Il s'agit d'une limite commune aux LLM très capables testés dans des environnements mal isolés : si le modèle dispose d'un accès internet, il peut sortir du périmètre prévu sans intention malveillante.
Comment vérifier que mes agents IA déployés sont bien isolés ?
Auditez trois points : (1) l'accès réseau est-il restreint à une liste blanche de domaines autorisés, ou l'agent a-t-il accès à internet sans restriction ? (2) les environnements de test et de staging sont-ils physiquement séparés des systèmes de production ? (3) les logs réseau de l'agent sont-ils capturés et consultables en cas d'incident ? Si la réponse à l'un de ces points est « non » ou « je ne sais pas », un risque existe.
L'AI Act européen impose-t-il des obligations sur ce type d'incident ?
Oui, indirectement. L'AI Act (applicable depuis août 2026) exige que les systèmes d'IA à haut risque disposent de procédures de surveillance, de journalisation et de signalement d'incidents. Les fournisseurs de modèles GPAI (General Purpose AI) comme Google sont soumis à des obligations de transparence et d'évaluation des risques, dont des risques cybersécurité. La CNIL suit ces développements dans le cadre du RGPD et de la gouvernance des données.
Faut-il considérer les agents IA comme dangereux après cet incident ?
L'incident révèle une limite de configuration, pas une intention malveillante du modèle. Gemini a d'ailleurs arrêté ses actions de lui-même. Le point de vigilance est le suivant : tout LLM suffisamment capable, avec un accès réseau non restreint, peut interagir avec des systèmes extérieurs non prévus. La sécurité des déploiements repose sur des contrôles d'infrastructure stricts — elle ne peut pas reposer uniquement sur le comportement attendu du modèle.