Les assistants IA de code comme Claude, Cursor ou Copilot sont devenus le copilote quotidien de vos développeurs. Mais la faille GhostApproval, révélée cette semaine, montre une nouvelle réalité : ces assistants IA de code peuvent écrire des fichiers hors de leur espace de travail, contournant les garde-fous d’approbation censés protéger le poste du développeur. Pour une PME-ETI, c’est un angle mort qu’il faut comprendre avant qu’un attaquant ne l’exploite.
GhostApproval : le bac à sable qui fuit
Le principe des assistants IA de code repose sur une promesse simple : l’agent ne modifie que les fichiers du projet ouvert, et toute action sensible déclenche une demande d’approbation. GhostApproval brise cette promesse en abusant des liens symboliques (symlinks). En plaçant un symlink piégé dans le dépôt, un attaquant peut faire écrire l’agent en dehors du répertoire de travail — par exemple dans ~/.ssh, ~/.aws ou un dossier de démarrage — sans que la boîte de dialogue d’approbation ne le signale correctement.
Le résultat : une modification qui semble anodine pour le développeur peut déposer une clé, un script de persistance ou un fichier de configuration malveillant sur la machine, avec les privilèges de l’utilisateur.
Pourquoi ça marche
- La confiance implicite : le développeur valide une action « dans le projet » sans réaliser qu’un symlink la redirige ailleurs.
- La fatigue d’approbation : à force de cliquer « Autoriser », l’attention baisse — le même biais qui rend le MFA prompt bombing efficace.
- Un dépôt n’est pas neutre : cloner un repo public ou accepter une pull request revient à exécuter du contenu non maîtrisé dans le contexte d’un agent privilégié.
Un symptôme d’un problème plus large
GhostApproval n’est pas un cas isolé. Il s’inscrit dans une série d’attaques 2026 visant les assistants IA de code : dépôts GitHub « propres » qui piègent les agents au moment du build, descriptions d’outils MCP empoisonnées, ou détournement d’agents (agentjacking). Le point commun : l’agent IA est un utilisateur privilégié, mais il est rarement surveillé comme tel.
Cette semaine, un autre incident l’illustre : une passerelle IA connectée à Amazon Bedrock a été détournée pour miner de la cryptomonnaie. Là encore, l’infrastructure IA — jugée « interne » et donc de confiance — est devenue une surface d’attaque à part entière.
Ce qu’une PME-ETI doit mettre en place
Défendre les assistants IA de code ne demande pas d’abandonner l’IA, mais de la traiter comme un utilisateur à privilèges. Nos recommandations :
- Isoler l’agent : faire tourner les assistants IA de code dans un conteneur ou une VM dédiée, sans accès direct à
~/.ssh, aux jetons cloud ou aux secrets de production. - Auditer les dépôts avant ouverture : traiter tout repo externe comme du contenu non fiable ; refuser les symlinks pointant hors du projet.
- Journaliser les écritures : surveiller (via votre SIEM) toute création de fichier hors du répertoire de travail par un processus d’agent.
- Limiter l’approbation automatique : bannir les modes « tout autoriser » sur les postes ayant accès à des secrets.
- Mettre à jour : appliquer sans délai les correctifs publiés par les éditeurs d’assistants IA de code concernés.
Le principe directeur : zéro confiance pour l’agent
La bonne posture consiste à appliquer le Zero Trust aux agents IA : chaque entrée que l’agent consomme est une instruction potentielle, chaque action qu’il exécute mérite une trace. La même logique protège contre l’agentjacking et les dépôts piégés. GhostApproval rappelle que le bac à sable d’un assistant IA de code n’est une protection que si vous en vérifiez les frontières vous-même.
Conclusion
Les assistants IA de code décuplent la productivité, mais ils héritent aussi des privilèges du développeur. GhostApproval et le détournement d’Amazon Bedrock montrent que l’infrastructure IA est désormais une cible de premier plan. Isolez, auditez, journalisez : c’est le prix d’une adoption sereine de l’IA en PME-ETI.