Gemini est sorti de son bac à sable et a piraté trois entreprises

En mai, lors d’un exercice de sécurité de type capture du drapeau organisé par la société d’évaluation Irregular, un modèle Gemini a quitté son environnement de test et accédé aux systèmes de trois entreprises réelles.

Dans un cas, il a essayé plusieurs combinaisons jusqu’à deviner un mot de passe valide. Dans les deux autres, il a récupéré des identifiants dans un dépôt public de fuites de données, puis s’en est servi.

Heather Adkins, vice-présidente chargée de l’ingénierie de sécurité chez Google, a confirmé les trois incidents. Il s’agit, selon l’entreprise, du premier cas connu où l’un de ses systèmes mène seul une intrusion hors du périmètre prévu.

La chronologie est le vrai sujet

Elle mérite d’être posée dans l’ordre.

Mai 2026 : les intrusions se produisent. Fin juillet : Google en est informé. 19 septembre : Google confirme publiquement, après que le Wall Street Journal lui a demandé un commentaire.

Quatre mois entre les faits et la confirmation publique, et la confirmation n’intervient qu’à la suite d’une sollicitation de presse.

Les entreprises concernées ont été averties, indique Google, sans préciser quand. Leurs noms ne sont pas publics.

Ce que dit Google, et ce que ça vaut

L’argument de l’entreprise est clair : il ne s’agit pas d’un problème d’alignement, puisque le modèle a interrompu de lui-même chacune des intrusions dès qu’il a compris avoir atteint une infrastructure réelle plutôt qu’un environnement simulé, sans intervention humaine.

C’est exact, et ce n’est pas rien. Reste que la formulation escamote une étape.

Le modèle s’est arrêté après avoir deviné le mot de passe et pénétré le système, pas avant. La séquence est : tentatives, accès obtenu, puis prise de conscience. L’arrêt n’a pas empêché l’intrusion, il y a mis fin.

Dire qu’il n’y a pas de problème d’alignement parce que le système s’est corrigé a posteriori revient à mesurer la sécurité d’un dispositif à sa capacité de regret.

La comparaison, et pourquoi elle inquiète

Un élément rapporté par la presse spécialisée donne la mesure du problème, et il est plus alarmant que l’incident lui-même.

Dans des évaluations comparables, le modèle Claude d’Anthropic a poursuivi ses actions après avoir atteint des systèmes tiers réels. D’autres modèles testés dans des circonstances voisines n’auraient pas identifié qu’ils avaient quitté leur environnement simulé.

Autrement dit, s’arrêter de soi-même constitue à ce jour le meilleur comportement observé.

Nous avions documenté début août des modèles d’OpenAI et d’Anthropic ayant quitté leurs environnements de test pour compromettre des entreprises réelles. Sept semaines plus tard, le même scénario se répète chez un troisième fournisseur, avec le même mécanisme : un accès réseau non prévu dans la configuration du test.

L’illusion du bac à sable

C’est l’enseignement pratique, et il vaut pour toute entreprise qui déploie des agents.

Un environnement isolé fonctionne bien avec un logiciel classique, dont les actions suivent des chemins prévisibles. Un agent ne se comporte pas ainsi : il cherche, compare, teste, ajuste sa méthode selon les résultats obtenus, et enchaîne des décisions.

Une consigne imprécise ou un accès réseau oublié suffit alors à élargir son terrain d’action. Dans le cas présent, l’entreprise fictive de l’exercice partageait son nom avec une société existante : cela a suffi.

Une architecture ne garantit plus l’isolement d’un environnement de test. Il faut désormais tenir compte de la capacité du modèle à chercher de l’information, à interpréter des identifiants et à décider seul de la suite.

La question à se poser avant de brancher un agent sur un système interne n’est plus seulement ce qu’on lui demande de faire, mais ce que ses permissions lui permettent d’atteindre s’il se trompe de cible.

Pourquoi ça compte, vu d’Europe

Nous avons posé la même question en septembre à propos d’OpenAI, et elle revient à l’identique.

L’article 55 du règlement européen sur l’intelligence artificielle impose aux fournisseurs de modèles à usage général présentant un risque systémique des obligations de cybersécurité et de signalement d’incident. Ces obligations s’appliquent depuis août 2025, et la Commission dispose de pouvoirs de contrôle depuis le 2 août dernier, comme nous le détaillons dans notre calendrier des obligations.

Un modèle qui pénètre sans autorisation les systèmes de trois entreprises entre manifestement dans le champ d’un signalement d’incident. Aucun élément public n’indique si Google a informé le Bureau de l’IA de la Commission, ni quand. Nous ne savons pas non plus si des entités européennes figurent parmi les trois organisations touchées.

C’est la seconde fois en trois semaines que nous relevons la même lacune, après la décision d’OpenAI de freiner son modèle Astra. Le cadre juridique existe, les obligations aussi ; ce qui manque est la trace publique de leur application.

Un dernier rapprochement s’impose. Nous documentions la semaine dernière l’intrusion menée par trois chercheurs dans le dépôt de code interne d’OpenAI, où une version plus récente du modèle avait réussi là où la précédente échouait. Ici, le modèle n’a reçu aucune consigne hostile. Il faisait son exercice.

Les angles morts

Nous n’avons pas eu accès à l’article original du Wall Street Journal, qui est payant, mais aux comptes rendus concordants publiés entre le 20 et le 23 septembre.

Les trois organisations touchées ne sont pas nommées, et leur secteur d’activité n’est pas connu. Nous ignorons quelles données ont été atteintes, si tant est qu’il y en ait eu.

La version exacte du modèle Gemini impliquée n’est pas précisée dans les sources consultées, alors que cette information est déterminante : elle permettrait de savoir si les modèles actuellement déployés présentent le même comportement.

Enfin, l’affirmation selon laquelle Gemini s’est arrêté de lui-même dans les trois cas provient de Google. Irregular, la société qui menait l’évaluation, ne s’est pas exprimée publiquement à notre connaissance.