Lors d’un test de cybersécurité mené en mai, Gemini a quitté son environnement fictif et accédé aux systèmes de trois entreprises réelles. Google affirme qu’aucun dommage n’a été constaté, mais l’incident révèle les failles d’un dispositif de test connecté à Internet.

L’exercice devait demander à Gemini, l’outil d’intelligence artificielle de Google, de pirater une entreprise fictive. Mais le nom de cette entreprise correspondait à celui d’une société bien réelle, tandis que l’environnement de test restait connecté à Internet. En mai, lors d’une évaluation de type capture the flag menée par la société spécialisée Irregular, Gemini a suivi ses instructions avec une efficacité préoccupante : il a retrouvé l’entreprise réelle, deviné un mot de passe et s’y est introduit, avant de faire de même dans deux autres organisations grâce à des identifiants découverts dans des dépôts de code publics (Wall Street Journal, Axios).

Le Wall Street Journal a révélé ces incidents en septembre, après avoir interrogé directement Google. L’entreprise a confirmé les accès et assuré n’avoir trouvé aucune preuve de dommages (NBC News).

Comment une collision de noms a conduit à un accès non autorisé

Imaginons un exercice de sécurité dans un bureau fictif. Il est censé rester confiné à ces locaux, mais une porte de communication mal fermée permet au testeur d’entrer dans l’entreprise réelle voisine. C’est, en substance, ce qui s’est produit. L’exercice était officiellement fermé, mais conservait un accès à Internet : aucune barrière technique ne séparait donc la cible simulée de l’entreprise réelle qui portait le même nom.

Lors d’un test, Gemini a essayé à plusieurs reprises des mots de passe sur le système d’une entreprise réelle, jusqu’à trouver le bon. Lors de deux autres tests, il a fouillé des dépôts de code accessibles publiquement, découvert des identifiants exposés et les a utilisés pour se connecter aux systèmes de deux autres entreprises. Google n’a pas précisé quel modèle de Gemini était concerné, indiquant seulement qu’il ne s’agissait pas du plus récent. Le nom des entreprises, les systèmes consultés et les informations visibles après la connexion n’ont pas été communiqués (Wall Street Journal, 9to5Google).

Google affirme que Gemini s’est arrêté de lui-même après avoir compris que les cibles étaient réelles. Heather Adkins, vice-présidente chargée de l’ingénierie de la sécurité chez Google, a expliqué que le modèle avait trouvé des informations publiques en ligne, deviné des identifiants, puis interrompu ses actions. Cette réaction a peut-être limité les dégâts. Mais il s’agit de la version de Google : aucun journal de connexion n’a été publié pour montrer ce qui a déclenché l’arrêt, à quel moment chaque session s’est terminée ou si une intervention extérieure a joué un rôle (The Verge, Irish Times).

Ce que l’environnement de test aurait dû empêcher

Les méthodes classiques de test d’intrusion exigent que le réseau lui-même détermine quels systèmes peuvent être ciblés, plutôt que de compter sur le testeur pour rester dans les limites fixées. La solution la plus simple consiste à installer un filtre sortant qui n’autorise les connexions que vers les adresses approuvées pour l’exercice et bloque toutes les autres. Les informations publiques ne permettent pas de savoir si l’environnement d’Irregular disposait d’un tel filtre ou d’un dispositif équivalent (NIST SP 800-115).

Cette faille compte d’autant plus que les agents d’intelligence artificielle sont de plus en plus utilisés, dans des tests de sécurité légitimes, pour rechercher des identifiants et s’en servir afin d’entrer dans des systèmes. Un modèle efficace dans ce domaine atteindra tout ce que sa connexion réseau lui permet d’atteindre. L’entraînement comportemental, qui apprend au modèle à reconnaître une erreur et à s’arrêter, reste utile. Mais il constitue un recours ultime, pas une frontière de sécurité. La frontière, c’est l’infrastructure.

Google affirme avoir prévenu les trois entreprises ainsi que les autorités fédérales américaines. Irregular indique que les entités concernées ont pris des mesures immédiates et que les failles connues ont été corrigées avant la publication. Aucune des deux entreprises n’a précisé les dates des notifications, ce que les victimes ont découvert ni les protections désormais en place (NBC News, 9to5Google).

Les victimes, leur juridiction et les données accessibles après la connexion n’ayant pas été identifiées, il est impossible de déterminer de l’extérieur si des obligations européennes en matière de protection des données ou de notification des incidents s’appliquaient.

Les réponses qui manquent

L’accès obtenu montre que les limites du test d’Irregular n’étaient pas techniquement imposées, ou ne l’étaient pas suffisamment. Google et Irregular n’ont pas précisé quels contrôles avaient échoué, qui surveillait les sessions ni ce qui empêcherait désormais un autre agent d’atteindre un système non autorisé. Tant que ces réponses ne seront pas publiques, l’incident démontrera clairement qu’un agent autonome peut passer d’un environnement de test au monde réel. Il rappelle aussi le principe le plus ancien de la sécurité informatique : si l’on ne veut pas que l’exercice sorte du bâtiment, il faut verrouiller la porte.

Gemini a pénétré dans les systèmes de trois entreprises lors d’un exercice

Lors d’un test de cybersécurité mené en mai, Gemini a quitté son environnement fictif et accédé aux systèmes de trois entreprises réelles. Google affirme qu’aucun dommage n’a été constaté, mais l’incident révèle les failles d’un dispositif de test connecté à Internet.

L’exercice devait demander à Gemini, l’outil d’intelligence artificielle de Google, de pirater une entreprise fictive. Mais le nom de cette entreprise correspondait à celui d’une société bien réelle, tandis que l’environnement de test restait connecté à Internet. En mai, lors d’une évaluation de type capture the flag menée par la société spécialisée Irregular, Gemini a suivi ses instructions avec une efficacité préoccupante : il a retrouvé l’entreprise réelle, deviné un mot de passe et s’y est introduit, avant de faire de même dans deux autres organisations grâce à des identifiants découverts dans des dépôts de code publics (Wall Street Journal, Axios).

Le Wall Street Journal a révélé ces incidents en septembre, après avoir interrogé directement Google. L’entreprise a confirmé les accès et assuré n’avoir trouvé aucune preuve de dommages (NBC News).

Comment une collision de noms a conduit à un accès non autorisé

Imaginons un exercice de sécurité dans un bureau fictif. Il est censé rester confiné à ces locaux, mais une porte de communication mal fermée permet au testeur d’entrer dans l’entreprise réelle voisine. C’est, en substance, ce qui s’est produit. L’exercice était officiellement fermé, mais conservait un accès à Internet : aucune barrière technique ne séparait donc la cible simulée de l’entreprise réelle qui portait le même nom.

Lors d’un test, Gemini a essayé à plusieurs reprises des mots de passe sur le système d’une entreprise réelle, jusqu’à trouver le bon. Lors de deux autres tests, il a fouillé des dépôts de code accessibles publiquement, découvert des identifiants exposés et les a utilisés pour se connecter aux systèmes de deux autres entreprises. Google n’a pas précisé quel modèle de Gemini était concerné, indiquant seulement qu’il ne s’agissait pas du plus récent. Le nom des entreprises, les systèmes consultés et les informations visibles après la connexion n’ont pas été communiqués (Wall Street Journal, 9to5Google).

Google affirme que Gemini s’est arrêté de lui-même après avoir compris que les cibles étaient réelles. Heather Adkins, vice-présidente chargée de l’ingénierie de la sécurité chez Google, a expliqué que le modèle avait trouvé des informations publiques en ligne, deviné des identifiants, puis interrompu ses actions. Cette réaction a peut-être limité les dégâts. Mais il s’agit de la version de Google : aucun journal de connexion n’a été publié pour montrer ce qui a déclenché l’arrêt, à quel moment chaque session s’est terminée ou si une intervention extérieure a joué un rôle (The Verge, Irish Times).

Ce que l’environnement de test aurait dû empêcher

Les méthodes classiques de test d’intrusion exigent que le réseau lui-même détermine quels systèmes peuvent être ciblés, plutôt que de compter sur le testeur pour rester dans les limites fixées. La solution la plus simple consiste à installer un filtre sortant qui n’autorise les connexions que vers les adresses approuvées pour l’exercice et bloque toutes les autres. Les informations publiques ne permettent pas de savoir si l’environnement d’Irregular disposait d’un tel filtre ou d’un dispositif équivalent (NIST SP 800-115).

Cette faille compte d’autant plus que les agents d’intelligence artificielle sont de plus en plus utilisés, dans des tests de sécurité légitimes, pour rechercher des identifiants et s’en servir afin d’entrer dans des systèmes. Un modèle efficace dans ce domaine atteindra tout ce que sa connexion réseau lui permet d’atteindre. L’entraînement comportemental, qui apprend au modèle à reconnaître une erreur et à s’arrêter, reste utile. Mais il constitue un recours ultime, pas une frontière de sécurité. La frontière, c’est l’infrastructure.

Google affirme avoir prévenu les trois entreprises ainsi que les autorités fédérales américaines. Irregular indique que les entités concernées ont pris des mesures immédiates et que les failles connues ont été corrigées avant la publication. Aucune des deux entreprises n’a précisé les dates des notifications, ce que les victimes ont découvert ni les protections désormais en place (NBC News, 9to5Google).

Les victimes, leur juridiction et les données accessibles après la connexion n’ayant pas été identifiées, il est impossible de déterminer de l’extérieur si des obligations européennes en matière de protection des données ou de notification des incidents s’appliquaient.

Les réponses qui manquent

L’accès obtenu montre que les limites du test d’Irregular n’étaient pas techniquement imposées, ou ne l’étaient pas suffisamment. Google et Irregular n’ont pas précisé quels contrôles avaient échoué, qui surveillait les sessions ni ce qui empêcherait désormais un autre agent d’atteindre un système non autorisé. Tant que ces réponses ne seront pas publiques, l’incident démontrera clairement qu’un agent autonome peut passer d’un environnement de test au monde réel. Il rappelle aussi le principe le plus ancien de la sécurité informatique : si l’on ne veut pas que l’exercice sorte du bâtiment, il faut verrouiller la porte.