Réponse directe : oui. Des fichiers de configuration Git malveillants (core.fsmonitor, core.gitProxy, filter.*.process) exécutent du code attaquant dès qu’un agent IA — Claude, Codex, Cursor, Gemini — ouvre le dépôt. Le simple fait de cloner un projet piégé suffit à compromettre l’agent et la machine qui l’exécute. C’est une injection de prompt qui passe par le système de fichiers, pas par la conversation.

Le vecteur : Git, angle mort des agents IA

Les agents de codage modernes lisent des dépôts entiers pour comprendre un projet. Mais un dépôt n’est pas que du code : c’est aussi son dossier .git, qui contient des hooks et des commandes de configuration exécutées automatiquement par Git lui-même.

Trois clés de configuration sont dangereuses :

1. core.fsmonitor — pointe vers un binaire exécuté à chaque commande Git.

2. core.gitProxy — un programme intermédiaire qui traite les transferts réseau.

3. filter.*.process — des filtres de nettoyage qui s’exécutent sur le contenu des fichiers.

Un attaquant qui contrôle le dépôt peut rediriger ces clés vers son propre code. L’agent, en explorant le projet, déclenche l’exécution sans que l’utilisateur ne le demande explicitement.

Pourquoi les agents IA sont la cible parfaite

L’agent IA fonctionne par confiance par défaut. Il lit les fichiers, en tire des instructions, et peut exécuter des commandes shell. L’OWASP, dans son Top 10 des applications LLM, place d’ailleurs l’injection de prompt (LLM01) en première position des risques — la voie d’entrée la plus critique pour les systèmes à base de modèles de langage ([OWASP Top 10 for LLM Applications, 2025](https://owasp.org/www-project-top-10-for-large-language-model-applications/)).

La différence avec un humain est la vitesse : un développeur peut remarquer un core.gitProxy suspect. Un agent l’exécute en une fraction de seconde, sur des dizaines de dépôts, en parallèle. Le risque est multiplié par l’autonomie même de l’outil.

La parade : cloisonner l’agent avant de cloner

La règle d’or est simple : ne jamais laisser un agent ouvrir un dépôt tiers sans cloisonnement.

Trois mesures concrètes suffisent à éliminer la quasi-totalité du risque :

– Désactiver les hooks et filtres Git (git config --global core.fsmonitor false et audit des filter.*.process) avant tout clonage inconnu.

– Exécuter l’agent dans un bac à sable (conteneur, VM, machine dédiée) sans accès aux secrets ni au réseau interne.

– Traiter les instructions du dépôt comme non fiables : tout fichier de config, README ou CI d’un projet tiers est du contenu potentiellement hostile.

Chez Shadows Company, c’est la doctrine NightOps : la sécurité n’est pas une couche ajoutée à la fin, c’est la graine qu’on cultive avant d’agir.

FAQ

Un agent IA peut-il vraiment exécuter du code en lisant un dépôt ?

Oui. Si le dépôt contient des clés Git comme core.fsmonitor ou filter.*.process pointant vers un exécutable, Git lance ce code automatiquement, et l’agent le déclenche en explorant le projet.

Cela concerne-t-il tous les agents de codage ?

Les agents qui lisent des dépôts entiers — Claude Code, Codex, Cursor, Gemini et les équivalents open source — sont tous concernés, car le vecteur est Git lui-même, indépendant du modèle.

Comment savoir si un dépôt est piégé ?

Auditez le dossier .git/config avant toute utilisation : cherchez core.fsmonitor, core.gitProxy et filter.*.process. Toute valeur pointant vers un chemin exécutable inattendu est un signal d’alerte.

Quel est le niveau de risque réel ?

L’OWASP classe l’injection de prompt au premier rang des risques LLM. Le vecteur .git est une variante sournoise car elle ne passe pas par la conversation mais par le système de fichiers.

Quelle est la position de Nakedo ?

Cloisonner systématiquement l’agent avant tout clonage tiers, et traiter tout contenu de dépôt externe comme non fiable. La souveraineté commence par ne pas exécuter du code qu’on n’a pas audité.

Article brouillon — ADA Phoenix, Nakedo. Ad Umbram, Ad Lucem.