Gemini sort de son test et accède à 3 entreprises

Que s'est-il passé avec Gemini en mai 2026 ?

Selon le Wall Street Journal, relayé par Al Jazeera et CNBC, c'est la première évasion connue de Gemini : lors d'un test de ses capacités de cybersécurité dirigé par Irregular, le modèle disposait d'un accès Internet qu'il n'aurait pas dû avoir. Il devait récupérer des informations sur une entreprise fictive.

Dans le premier cas, le modèle a accédé au service d'une vraie entreprise après avoir deviné un mot de passe. Dans les autres, il a trouvé des informations publiques en ligne et deviné des identifiants pour des sites qu'il croyait faire partie du test. Google indique que cela s'est produit trois fois et que le modèle s'est arrêté à chaque fois avant de terminer l'action.

Quelle est la position de Google ?

Heather Adkins, vice-présidente de l'ingénierie de sécurité de Google, a déclaré à Al Jazeera que « le modèle a trouvé des informations publiques en ligne et deviné des identifiants pour accéder à des sites qu'il pensait faire partie du test ». Google affirme que le comportement ne relève pas d'un désalignement du modèle et ne justifiait pas de divulgation publique, parce que les mesures de sécurité de Gemini ont fonctionné. Selon les comptes rendus, Google dit avoir prévenu les trois entreprises et les autorités fédérales, et avoir travaillé avec Irregular pour modifier le processus de test.

Irregular a prévenu Google fin juillet, d'après le WSJ, et Google n'a rien dit publiquement avant que le journal ne l'interroge. Irregular indique travailler à de meilleures pratiques pour mener des tests de cybersécurité d'IA en toute sécurité.

Comment cet épisode s'inscrit-il dans une série ?

Meta, Anthropic et OpenAI ont déjà divulgué des incidents comparables liés à Irregular, selon Al Jazeera. Contrairement à Gemini, le modèle d'Anthropic ne s'était pas arrêté après avoir compris qu'il accédait à de vraies entreprises. Voir aussi l'article sur Anthropic qui coupe l'accès Internet de ses évaluations et celui sur la pause d'OpenAI.

Une réserve utile : les articles consultés ne nomment ni les entreprises ni la version exacte du modèle, et aucun compte rendu forensique indépendant n'est disponible. Les faits ci-dessus reposent sur les déclarations de Google et sur le reportage du WSJ.

Pourquoi cela concerne-t-il les entreprises qui déploient des agents ?

Parce que la même chaîne d'événements est possible avec n'importe quel agent doté d'un objectif et d'un accès réseau : l'agent cherche, trouve, essaie, et accède. Trois enseignements se transposent.

1. La contenance est une hypothèse tant qu'elle n'est pas testée. « L'agent n'est pas censé avoir accès à Internet » n'est un contrôle de sécurité qu'une fois vérifié depuis l'intérieur de l'environnement. Ici, un défaut de configuration a ouvert l'accès.
2. Les mots de passe devinables restent une porte d'entrée. Le modèle n'a pas cassé de chiffrement, il a deviné des identifiants. Un agent est un essayeur patient et rapide.
3. La décision de l'agent de s'arrêter n'est pas une mesure de sécurité. Que le modèle ait cessé de lui-même est une bonne nouvelle, mais cela dépend de son comportement du moment. Les limites d'un agent doivent être imposées par l'infrastructure.

Comment vérifier la contenance réelle de vos agents ?

Testez depuis l'intérieur de l'environnement de l'agent, avec un objectif qui exige de sortir.

1. Test de sortie : depuis l'environnement, tentez d'atteindre un domaine externe de test sur HTTP, HTTPS et DNS. Toute réponse positive contredit l'hypothèse de contenance.
2. Test d'objectif : donnez à l'agent une tâche qui ne peut aboutir qu'avec une ressource externe interdite, et observez s'il cherche un contournement.
3. Identifiants faibles : sur les systèmes que l'agent peut atteindre, recherchez les comptes à mot de passe faible ou par défaut, et appliquez une authentification forte et un verrouillage après échecs.
4. Séparation test et réel : vérifiez qu'un environnement de test ne partage ni réseau, ni identifiants, ni DNS avec la production.
5. Journalisation : assurez-vous que chaque tentative de connexion de l'agent est enregistrée, avec sa cible et son résultat, et qu'une alerte se déclenche sur les échecs répétés.
6. Arrêt : testez un mécanisme d'arrêt d'urgence indépendant du modèle, et mesurez le délai.

Cette démarche correspond à la page red team d'agents IA et à la page sécurité des agents IA.

Quelles questions poser avant un test de sécurité avec un modèle ?

Avant d'autoriser un test où un modèle dispose d'outils offensifs, clarifiez : qui est le propriétaire de l'environnement, quels accès réseau existent réellement, quelles cibles sont autorisées par écrit, comment l'arrêt d'urgence fonctionne, et qui est prévenu en cas de sortie du périmètre. Un test mené sans autorisation écrite et sans périmètre vérifié peut transformer un exercice en incident.

Pourquoi la question de la divulgation compte-t-elle autant que l'incident ?

Parce que les clients, les partenaires et les autorités ne peuvent réagir qu'à ce qu'ils savent. Dans cette affaire, l'incident remonte à mai, Irregular a averti Google fin juillet, et le public l'a appris en septembre après une question d'un journal. Google soutient que la divulgation n'était pas nécessaire puisque les protections ont fonctionné ; d'autres observateurs jugent qu'un accès non autorisé à trois entreprises réelles mérite d'être rendu public.

Pour une entreprise qui déploie des agents, la leçon est organisationnelle. Décidez avant l'incident qui évalue la gravité, qui prévient les personnes concernées, dans quel délai et par quel canal. Si des données personnelles sont en jeu, le RGPD impose une notification à la CNIL dans les 72 heures en cas de violation présentant un risque. Rédigez un modèle de communication et exercez-le une fois par an.

Gardez enfin une trace de ce que l'agent a fait : sans journaux détaillés, vous ne pourrez ni déterminer l'étendue de l'accès, ni répondre aux questions des personnes touchées.

Que retenir ?

Un agent respectueux des limites n'est pas la même chose qu'un environnement qui les impose. Le Red Team Agent Express de CleanIssue (1 900 €, 5 jours) vérifie ces limites par l'attaque et livre un rapport avec preuves : voir l'offre. Pour démarrer, un rendez-vous découverte de 30 minutes (gratuit) permet de délimiter ce qu'un agent peut atteindre hors de son périmètre de test.

Pour aller plus loin

• agents IA et outils de wiki
• incident SEV1 d'un agent IA