Un dépôt Git piégé suffit désormais à faire exécuter du code attaquant par votre agent IA de code, avant même que celui-ci ne vous demande la moindre autorisation. Des chercheurs ont montré que sept assistants de développement — dont Claude Code, Codex et Cursor — déclenchent des commandes issues du fichier .git/config d’un projet cloné, à un moment où l’utilisateur pense encore être en phase d’inspection. Quatre d’entre eux n’étaient pas corrigés au moment de la publication. Pour une PME ou une ETI qui a industrialisé l’usage de ces outils, c’est une remise à plat nécessaire du modèle de confiance.
Pourquoi un dépôt Git piégé contourne l’écran de confiance
Le raisonnement des éditeurs d’agents IA repose sur une idée simple : avant d’agir sur un projet inconnu, l’agent affiche un écran de confiance et attend un accord explicite. Le problème est que cet écran arrive trop tard. Git lui-même lit et applique la configuration locale du dépôt dès les premières opérations : résolution de l’état du répertoire, affichage des branches, lecture des différences. Or cette configuration peut définir des hooks, des pagers ou des filtres — c’est-à-dire des commandes système.
L’agent, lui, exécute ces opérations Git de manière automatique pour comprendre le contexte du projet. Il croit lire ; en réalité il exécute. Le dépôt Git piégé transforme une simple action de reconnaissance en primitive d’exécution de code, sans exploiter la moindre faille mémoire et sans que l’utilisateur ait validé quoi que ce soit.
- Vecteur d’entrée : dépôt public cloné, archive fournie par un client, fork d’un projet open source, répertoire partagé par un prestataire.
- Déclencheur : la première commande Git lancée par l’agent pour cartographier le projet.
- Impact : exécution sous l’identité du développeur, avec ses clés SSH, ses jetons cloud et son accès au dépôt d’entreprise.
Ce que cela change pour la sécurité des agents IA en PME-ETI
La conclusion opérationnelle est moins spectaculaire que le titre, mais plus lourde : un agent IA de code n’est pas un lecteur, c’est un exécutant. Chaque assistant installé sur un poste de développement doit être traité comme un compte de service disposant des droits de son utilisateur — donc audité, cloisonné et journalisé au même titre.
Cette logique rejoint ce que nous décrivions à propos de la sécurisation des workflows GitHub pilotés par des agents IA : le maillon faible n’est pas le modèle, c’est le périmètre d’exécution qu’on lui accorde par défaut. Le même raisonnement s’applique aux plateformes d’orchestration, comme l’a rappelé l’exploitation de la faille Langflow et le vol de clés API.
Le contenu non fiable est devenu du code
Pendant vingt ans, la règle était : ne pas exécuter les binaires reçus de l’extérieur. Avec les agents, la frontière se déplace. Un fichier de configuration, un README, un commentaire de code ou un ticket peuvent porter des instructions que l’agent interprétera. Le dépôt Git piégé n’est qu’une déclinaison particulièrement propre de ce principe : le contenu non fiable est désormais une surface d’exécution.
Sécuriser vos agents IA de code : les mesures qui tiennent
Aucune de ces mesures ne dépend d’un correctif éditeur. Elles restent valables quel que soit l’assistant retenu.
- Cloisonner l’exécution : faire tourner les agents dans un conteneur ou une machine virtuelle jetable, sans accès direct aux clés SSH de production ni aux jetons cloud long terme.
- Séparer les identités : un compte Git dédié aux agents, avec des droits en lecture seule sur les dépôts sensibles et aucun droit de publication automatique.
- Inspecter avant d’ouvrir : sur un dépôt d’origine externe, vérifier
.git/configet le répertoire.git/hooksavant de lancer l’agent, ou cloner avec une configuration neutralisée. - Journaliser les processus enfants : la détection utile porte sur les commandes lancées par le binaire de l’agent, pas sur son trafic réseau. Un EDR correctement réglé voit ce comportement.
- Maintenir les assistants à jour : les correctifs existent chez plusieurs éditeurs, et le rythme de publication est rapide. Le suivi de version doit entrer dans le cycle de patch classique.
- Fixer une règle d’entreprise : interdire l’usage des agents IA sur du code client non vérifié depuis un poste disposant d’accès de production.
Une question de gouvernance, pas d’outillage
Les entreprises qui encaissent le mieux ce type d’incident ne sont pas celles qui ont le meilleur assistant, mais celles qui ont posé une frontière nette entre l’environnement où l’IA travaille et l’environnement où résident les secrets. C’est exactement l’approche que nous appliquons chez ucyber.ai : un SOC agentique qui corrèle les comportements réels des processus, adossé à un capteur de terrain, plutôt qu’une confiance accordée à l’intention déclarée d’un outil.
Un agent IA de code apporte un gain de productivité réel. Il mérite le même cadre de sécurité que n’importe quel automate disposant d’un shell.