Google renforce Gemini CLI contre les injections via fichiers de build

Google a mis à jour Gemini CLI en version 0.61.0 avec un garde-fou concret contre les attaques par injection de prompt. L’agent de codage demande désormais une confirmation avant de modifier certains fichiers de build, avant de lancer des commandes de test ou de build après ces changements, et avant d’exécuter des commandes dont les arguments proviennent de contenus non fiables. Dans le même temps, Google renforce le sandbox afin de mieux isoler les secrets du système hôte.

Quand l’agent code trop vite, l’attaque peut suivre

Gemini CLI, l’outil en ligne de commande de Google pour piloter un agent de développement, part d’une idée simple : donner du contexte, laisser l’IA agir, puis vérifier le résultat. Sauf que cette autonomie ouvre une porte aux injections de prompt indirectes, quand du contenu récupéré sur le web ou via un outil externe contient des instructions cachées. Ici, le problème est moins théorique qu’opérationnel : un simple changement dans package.json, Makefile, pyproject.toml ou un fichier Bazel peut déclencher une chaîne d’actions difficile à repérer à temps.

Google explique que la version 0.61.0 coupe cette séquence à plusieurs endroits. Les modifications de fichiers de build connus exigent une validation explicite, et les commandes qui s’ensuivent, comme npm run, make ou cargo, attendent elles aussi un accord humain. Le message est clair : l’agent peut aider, mais il ne doit pas devenir un bras armé de l’attaquant. Les développeurs apprécieront sans doute de relire un diff plutôt que de découvrir un postinstall malveillant après coup ; les machines, elles, n’ont pas ce luxe.

Le sandbox se referme, mais sans promesse magique

Le second volet de la mise à jour concerne l’environnement d’exécution. Quand Gemini CLI tourne sous Docker, Podman, LXC ou macOS Seatbelt, le répertoire ~/.gemini de l’hôte n’est plus monté tel quel dans le sandbox. Google y injecte une copie nettoyée de la configuration, sans clés API, hooks ni commandes d’outils personnalisés. Le lancement est aussi bloqué dans certains emplacements sensibles, comme le répertoire personnel, et de nouvelles règles Seatbelt empêchent l’accès à des fichiers OAuth, aux décisions de confiance sur les dossiers et aux fichiers .env.

Google présente bien le sandbox comme une barrière de sécurité entre les opérations d’IA et le système hôte, mais précise aussi qu’il réduit le risque sans le supprimer. C’est la nuance qui compte : un fichier de build empoisonné peut rester dans le dépôt après coup, puis être exécuté plus tard hors du sandbox par un humain ou par une CI. Le problème se déplace, il ne disparaît pas.

Ce que Google corrige réellement dans Gemini CLI

Les correctifs publiés à découvert, via les pull requests citées par Google, visent deux scénarios précis. D’un côté, la protection contre les modifications indirectes des fichiers de build et contre les arguments de commande issus de contenus non fiables ; de l’autre, l’assèchement des chemins par lesquels un agent pourrait récupérer des secrets persistants. La logique reste la même : réduire la confiance par défaut, surtout quand la source du texte n’est pas maîtrisée.

La version 0.61.0 marque aussi une étape politique pour l’outil. Google a annoncé à I/O en mai qu’il ferait basculer les utilisateurs Pro, Ultra et gratuits de Gemini CLI vers Antigravity CLI, fermé, tandis que l’outil open source continue de recevoir des mises à jour de modèle, des correctifs et des patchs de sécurité. Dans ce contexte, cette salve de durcissement montre qu’un agent de développement n’est pas seulement un outil de productivité. C’est aussi une surface d’attaque. Et elle grandit vite.