Gemini CLI exige désormais une confirmation avant de modifier vos fichiers de build
Le 23 septembre 2026, Google a publié Gemini CLI 0.61.0, qui impose une confirmation humaine avant que l’agent ne modifie un fichier de build ou n’exécute une commande façonnée par du contenu non fiable. Les développeurs qui utilisent un agent de code doivent mettre à jour et laisser ces confirmations actives : c’est, pour l’instant, la meilleure défense contre l’injection indirecte.
23 septembre 2026. Google publie Gemini CLI 0.61.0, qui exige une confirmation avant que l’agent ne modifie un fichier de build. 11 septembre 2026. La pull request principale est fusionnée après que le relecteur automatisé a fait corriger plusieurs contournements. Mai 2026. Google annonce à l’I/O le basculement de la plupart des utilisateurs vers l’Antigravity CLI propriétaire. Pourquoi c’est important : les agents de code sont une nouvelle surface d’attaque, et la défense que Google déploie n’est pas une détection sophistiquée — c’est une demande de confirmation humaine.
L’attaque que cette version cherche à déjouer
Le scénario est précis. Un agent corrige un bug et, pour comprendre le problème, va lire de la documentation sur le web. Cette documentation contient une instruction cachée : ajouter un script postinstall au package.json. L’agent obéit, modifie le fichier, lance la suite de tests du projet — et exécute le code malveillant, sans que le développeur ait jamais tapé la moindre commande.
C’est de l’injection indirecte de prompt : l’attaquant ne parle pas au développeur, il parle au contenu que l’agent va ingérer. Or un fichier de build est le vecteur idéal, parce qu’une modification de package.json, de Makefile, de pyproject.toml ou d’un BUILD Bazel peut tirer une dépendance ou déclencher un script — et parce que l’agent, une fois le fichier modifié, a toutes les raisons de lancer la commande de build ou de test qui suit.
Gemini CLI 0.61.0 coupe ce scénario en trois endroits. La modification d’un fichier de build reconnu exige une confirmation. L’agent mémorise les fichiers de build modifiés pendant la session et retient toute commande de build ou de test ultérieure (npm run, make, cargo) pour approbation explicite. Et toute commande shell dont les arguments ressemblent à des jetons issus de contenu non fiable — résultats de recherche web, réponses de serveurs MCP, documents Google Docs, tickets Buganizer — déclenche une demande avant exécution.
Le détail qui dit tout : la confirmation remplace la confiance
Le changement le plus révélateur n’est pas technique, il est éditorial. Pour ces trois catégories d’actions, Gemini CLI supprime l’option d’approbation permanente. Impossible d’accorder un « toujours autoriser » : chaque action sensible repasse par l’humain.
C’est un aveu. Les agents de code proposaient jusqu’ici deux philosophies — confiance (l’agent décide, l’humain regarde) ou autorisation (l’humain valide). Google tranche : pour les fichiers de build, il n’y a plus de confiance qui vaille. Et le dialogue de confirmation affiche désormais le diff complet du fichier, au lieu de le tronquer — parce qu’un diff tronqué est précisément ce qui laisse passer une ligne malveillante.
La pull request #29250, intitulée « prevent indirect prompt injection via build file modifications and untrusted flags », révèle aussi combien le contrôle est difficile à faire tenir. Le relecteur automatisé a signalé plusieurs contournements dans les premières versions — arguments entre guillemets, préfixes de variables d’environnement, cibles de redirection shell, gestion des chemins Windows — tous corrigés avant la fusion du 11 septembre. La vérification compare des jetons plutôt que de tracer la provenance de chaque valeur, une limite assumée : c’est plus simple, et plus simple veut dire plus facile à auditer.
Un durcissement du sandbox, en parallèle
La même version durcit le sandbox optionnel. Quand il tourne via Docker, Podman, LXC ou Seatbelt sur macOS, le répertoire ~/.gemini de l’hôte n’est plus monté à l’intérieur. À la place, le CLI injecte une copie assainie des réglages de l’utilisateur, d’où les clés API, les hooks et les commandes d’outils personnalisées sont retirés. Le sandbox refuse aussi de se lancer dans des emplacements sensibles comme le répertoire personnel, et de nouvelles règles Seatbelt bloquent l’accès aux credentials OAuth, aux décisions de dossier de confiance et aux fichiers .env.
Les deux couches se complètent. Le sandbox limite ce qu’un processus peut atteindre une fois lancé ; les confirmations décident si l’agent a le droit de prendre l’action sensible en premier lieu. Mais il reste une faille concrète : le sandbox monte le répertoire du projet pour que l’agent puisse l’éditer, donc un package.json empoisonné écrit à l’intérieur du sandbox reste dans le dépôt quand un développeur — ou un job CI — lance le build à l’extérieur. La confirmation ne protège que la session de l’agent, pas tout ce qui se passe après.
Pourquoi les fichiers de build sont le maillon faible
Si Google choisit de mettre une confirmation sur les fichiers de build plutôt que sur n’importe quelle autre action, ce n’est pas un hasard.
Un fichier de build a trois propriétés qui en font la cible idéale d’une injection indirecte. Il s’exécute partout : sur la machine du développeur, dans la CI, sur les serveurs de production — une seule ligne malveillante se propage à tous les étages. Il tire des dépendances : ajouter un paquet, c’est introduire du code tiers qui tournera avec les droits du projet. Et il est édité par l’agent lui-même : contrairement à une commande ponctuelle, une modification de package.json persiste dans le dépôt, prête à être relancée bien après la fin de la session.
La comparaison avec les autres agents est instructive. Claude Code d’Anthropic, Codex d’OpenAI et le CLI de Cursor proposent tous des garde-fous comparables — listes d’autorisation, modes sandbox, confirmation des commandes — mais Google est le premier à traiter explicitement le fichier de build comme une catégorie à part, avec un diff complet affiché à l’utilisateur. C’est un choix défendable : la plupart des incidents d’injection indirecte documentés ces derniers mois passent par un fichier que l’agent modifie puis que le système exécute.
Le durcissement du sandbox, dans la même version, referme une brèche liée. Si l’agent peut modifier package.json à l’intérieur du sandbox, le sandbox ne suffit pas à lui seul : le fichier empoisonné reste dans le dépôt quand un développeur ou un job CI lance le build à l’extérieur. Les deux mécanismes doivent donc travailler ensemble — le sandbox limite ce qu’un processus peut atteindre, et la confirmation décide si l’agent a le droit de prendre l’action sensible. La suppression de l’option « toujours autoriser » est le geste clé, parce qu’une approbation permanente transforme un faux pas ponctuel en porte dérobée durable.
Reste une limite assumée. La vérification compare des jetons — des fragments d’arguments — plutôt que de tracer la provenance de chaque valeur. C’est plus simple à auditer, mais contournable : un attaquant qui connaît le mécanisme peut déguiser un argument pour qu’il ne ressemble plus au contenu non fiable qui l’a inspiré. La vraie défense de long terme, c’est le traçage de provenance, et personne ne l’a encore industrialisé.
Verdict
Le changement est modeste en apparence, mais il trace une ligne de conduite pour tout l’écosystème. Si vous utilisez Gemini CLI ou un agent de code similaire, mettez à jour vers 0.61.0, gardez les confirmations actives, et refusez toute approbation permanente pour les fichiers de build — la commodité que vous y gagnez est exactement la surface que l’attaquant exploite. Si vous développez un outillage d’agent, copiez la porte de confirmation sur les fichiers de build, mais investissez surtout dans le traçage de provenance plutôt que la comparaison de jetons : c’est la seule voie qui résiste aux contournements. Si vous exécutez des agents dans un sandbox, rappelez-vous que le sandbox protège l’hôte, pas le dépôt — un fichier de build empoisonné survit à la session et attend le prochain build hors sandbox.