Un développeur clone un dépôt inconnu, demande à un agent de programmation de l'installer, puis voit une demande d'approbation pour un fichier qui semble banal. Le problème: l'agent peut agir sur autre chose que ce que l'interface montre. Si ce fichier est un lien symbolique, l'écriture peut finir hors du projet, dans une configuration de shell ou un fichier d'accès SSH.

Flux d’un agent de programmation dans un sandbox avec des secrets protégés hors limite

C'est la leçon de GhostApproval, publié par Wiz le 8 juillet. Le même jour, AI Now Institute a publié Friendly Fire, un proof-of-concept qui transforme l'usage défensif de Claude Code CLI et OpenAI Codex CLI en chemin vers une exécution de code à distance. Ensemble, ces deux alertes rappellent que les outils de programmation par IA ne sont plus de simples autocomplétions. Dans beaucoup d'équipes, ce sont des runtimes locaux avec accès aux fichiers, au shell, aux gestionnaires de paquets, au réseau, aux identifiants et aux décisions de revue.

Cela ne les rend pas inutilisables. Mais le modèle de confiance doit changer. Un outil qui lit du texte non fiable, lance des commandes, modifie des fichiers et demande une validation partiellement résumée ressemble davantage à un runner CI ou à une extension IDE privilégiée qu'à un assistant de texte.

De l'assistant au runtime

Les premiers assistants complétaient des lignes. Les agents modernes parcourent les dépôts, ouvrent des fichiers, déduisent des étapes d'installation, modifient le code, exécutent des tests, installent des dépendances et peuvent réduire les validations. C'est leur intérêt. C'est aussi leur surface d'attaque.

Une machine de développeur contient des clés SSH, des identifiants cloud, des tokens de paquets, des dépôts internes, des sessions navigateur, un VPN et des fichiers de configuration. Un agent qui peut écrire et exécuter des commandes dans cet environnement n'est pas seulement un générateur de code.

On sait déjà traiter ce risque ailleurs: runners isolés, identifiants limités, règles réseau, sandboxes pour code non fiable. Les agents de programmation doivent entrer dans cette catégorie.

GhostApproval en clair

Selon Wiz, GhostApproval touche six assistants: Amazon Q Developer, Anthropic Claude Code, Augment, Cursor, Google Antigravity et Windsurf. La technique s'appuie sur les liens symboliques. Un chemin semble local au projet, mais pointe en réalité ailleurs. Si l'outil écrit à travers ce lien, il modifie la cible réelle.

Wiz parle de deux problèmes: suivi de symlink, CWE-61, et mauvaise représentation d'une information critique dans l'interface, CWE-451. Dans plusieurs cas, le runtime pouvait connaître la vraie cible, mais la boîte d'approbation ne la montrait pas clairement. L'utilisateur pensait accepter une modification locale.

Wiz indique qu'AWS, Cursor et Google ont corrigé rapidement. Amazon Q Developer language server avant 1.69.0 est listé comme affecté et corrigé en 1.69.0, CVE-2026-12958. Cursor avant 3.0 est listé comme affecté et corrigé en 3.0, CVE-2026-50549. Augment et Windsurf étaient encore en cours au moment de la publication. Anthropic a rejeté le rapport comme hors de son threat model, selon Wiz.

Les statuts évolueront. Le problème général demeure: si l'interface affiche un chemin rassurant mais que le runtime écrit ailleurs, l'approbation humaine ne protège pas vraiment.

Friendly Fire et la revue de code hostile

Friendly Fire vise une pratique courante: demander à un agent de vérifier une bibliothèque tierce ou open source.

AI Now affirme que son PoC permet une exécution de code à distance dans Claude Code CLI et OpenAI Codex CLI lorsqu'ils évaluent du code tiers. L'attaque, selon le brief, ne requiert ni plugin, ni hook, ni serveur MCP malveillant. Elle utilise des prompt injections disséminées dans des fichiers source ordinaires.

Il ne faut pas publier de mode d'emploi d'exploitation pour comprendre le risque. Le dépôt n'est plus une entrée passive. Si l'agent lit du texte hostile et agit ensuite avec ses outils, le dépôt fait partie du canal de contrôle.

Confiance, transparence et entreprise

La même semaine, CNA a rapporté qu'un régulateur chinois avait signalé un risque de "security backdoor" dans Claude Code. Anthropic a décrit le mécanisme comme une mesure anti-abus fondée sur des signaux comme le fuseau horaire et les proxys pour bloquer des régions non prises en charge. Ce n'est pas GhostApproval, mais c'est la même conversation: que voit l'agent local, qu'envoie-t-il, comment applique-t-il les règles, et que documente le fournisseur?

Les développeurs posent aussi ces questions. Un fil Hacker News sur le "Extended Thinking" de Claude Code avait déjà réuni des centaines de commentaires. Ce n'était pas une preuve de GhostApproval, mais le débat était clair: la surface visible d'un outil IA est-elle la vérité brute, un résumé ou une interface produit?

L'adoption a dépassé la gouvernance

Dark Reading cite le GitLab 2026 AI Accountability Report: 91% des organisations utiliseraient au moins deux outils de coding, et 54% au moins trois. L'article cite aussi SonarSource: 72% des développeurs ayant essayé ces outils les utilisent chaque jour; 96% ne font pas confiance au code généré tel quel; seulement 48% vérifient toujours avant commit.

Ce sont des signaux d'enquête, pas des certitudes absolues. Mais la direction est nette. Les entreprises ont souvent adopté plusieurs assistants avant de construire une politique unique. Un outil dans l'IDE, un autre dans le terminal, un autre dans les pull requests. Chaque outil a son modèle d'approbation, de sandbox, de télémétrie et de logs.

Mesures immédiates

Commencez par l'inventaire. Quels outils sont autorisés? Quelles versions? Lesquels peuvent lancer un shell, modifier des fichiers, accéder au réseau, lire des secrets ou appeler des serveurs MCP?

Désactivez auto-approve et auto-review pour les dépôts non fiables. Si le code vient d'Internet, d'un fournisseur, d'un candidat, d'un client ou d'une dépendance suspecte, considérez le texte comme hostile pour l'agent.

Utilisez des environnements jetables: conteneurs, VM de développement, cloud workstations verrouillées. Pas de clés SSH personnelles, de tokens longs ou d'accès production sans nécessité.

Séparez les secrets. Préférez des identifiants courts, à privilèges limités, et un scan de secrets avant commit. Limitez les sorties réseau. Gardez des logs des appels d'outils, commandes, écritures, validations et refus.

Ce que les fournisseurs doivent prouver

"L'utilisateur a approuvé" ne suffit pas. Il faut que l'utilisateur approuve une information exacte sur l'opération réelle.

Les produits doivent afficher les chemins canoniques, bloquer les sorties du workspace, écrire de manière sûre à travers les symlinks, avertir sur les cibles externes, publier des avis CVE clairs et fournir des contrôles entreprise auditables. La télémétrie et l'anti-abus doivent aussi être documentés simplement.

AI coding continuera. Les équipes qui en tireront parti seront celles qui le traiteront comme une automatisation privilégiée: sandbox, identifiants étroits, réseau limité, validations honnêtes et logs.