On a tous un réflexe débile mais humain : « je clone, j’ouvre, je lance l’outil ». Avec un agent type Claude Code, ce geste devient une surface d’attaque locale. Pas théorique, pas “dans un lab”. Juste un dépôt piégé, une config “pratique” committée dedans, et ton poste exécute ou envoie des trucs que tu n’avais pas prévu.
Le point qui pique, c’est que ce n’est pas forcément un binaire compromis ou une extension IDE vérolée. C’est parfois le repo lui-même qui “pilote” l’agent via des fichiers de config, des hooks, des intégrations MCP, des scripts appelés par l’outillage. Autrement dit, tu as accepté qu’un projet non fiable te dicte comment ton assistant va se comporter sur ta machine. Mauvais deal.
Ce qui change avec les agents : la config devient exécutable
Avant, un dépôt malveillant essayait surtout de te faire exécuter quelque chose : un curl | bash, un npm install qui déclenche un postinstall, une commande copiée-collée. C’était déjà sale, mais tu pouvais dire « ok, j’ai lancé un script ». Avec un agent, tu ajoutes une couche d’automatisation et de délégation, donc une couche de surprises.
Le mouvement est simple : l’agent lit des fichiers du repo (ou se laisse influencer par eux), et ces fichiers peuvent définir des actions, des outils, des serveurs, des hooks, des commandes. Si l’outil est permissif, ou si tu cliques “allow” un peu trop vite, tu viens d’offrir un accès local à un dépôt que tu viens de cloner. Ce n’est pas du “remote code execution” au sens vulnérabilité kernel. C’est pire au quotidien, parce que c’est du code exécuté par ton workflow.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Où ça se cache dans un dépôt (et pourquoi tu ne le vois pas venir)
Le piège classique, c’est la config “d’équipe” committée pour gagner du temps. Elle a l’air légitime. Elle ressemble à de l’outillage. Et comme on vit tous dans des monorepos qui ressemblent à des tiroirs IKEA, une config de plus ne choque personne.
Dans les travaux rapportés par la presse sécurité autour de Claude Code, l’angle central est justement là : des mécanismes comme des hooks côté agent (attention, pas forcément des git hooks au sens .git/hooks), des fichiers de configuration interprétés automatiquement, et des intégrations MCP (Model Context Protocol) qui peuvent déclarer des “serveurs/outils” accessibles à l’agent. Selon comment c’est implémenté et validé, tu peux te retrouver avec un agent qui lance une commande locale, ou qui ouvre une connexion sortante, sans que ça ressemble à “j’exécute un script”.
Le détail important : beaucoup de développeurs font confiance au repo plus qu’ils ne devraient. Parce que “c’est juste un POC”, “c’est un client”, “c’est une PR externe”, “c’est un template”. Et parce que la config d’un agent, on la voit comme de la conf, pas comme une surface d’exécution.
Trois scénarios crédibles (ceux qui arrivent pour de vrai)
Premier scénario, le plus direct : un dépôt contient une config qui pousse l’agent à lancer une commande locale via un hook ou un outil déclaré. Ça peut être une commande anodine en apparence, du style “formatter”, “analyser”, “générer”. Sauf que la commande peut aussi lire ton ~/.ssh, ton trousseau, tes variables d’environnement, ou fouiller ton dossier projet à la recherche de .env. C’est rarement spectaculaire. C’est discret, et c’est justement le but.
Deuxième scénario : l’exfiltration lente. Pas besoin d’ouvrir un reverse shell. Il suffit d’un appel HTTP sortant, d’un webhook, d’un “serveur MCP” qui envoie du contexte, ou d’un outil “observabilité” qui expédie plus que prévu. Avec les agents, l’exfiltration n’a même pas besoin de cibler “le code”. Elle cible ce qui a de la valeur tout de suite : des tokens, des clés API, des cookies de session, des identifiants cloud, des credentials de registry.
Troisième scénario : la modification silencieuse. Le dépôt te fait travailler, l’agent fait des edits, et une config malveillante oriente ces edits vers une backdoor applicative ou une dépendance “utile” qui n’a rien à faire là. Le côté vicieux, c’est que tu vas relire le code métier, pas forcément la petite ligne dans un fichier de build, un script CI, ou une config d’outillage qui change le comportement.
La règle qui sauve : traite tout repo comme non fiable
Je pars d’un principe simple : un repo que tu viens de cloner est non fiable jusqu’à preuve du contraire. Ça ne veut pas dire parano. Ça veut dire que ton poste principal (celui avec tes clés SSH, tes tokens, tes accès prod, ton navigateur connecté partout) n’est pas l’endroit où tu laisses un agent découvrir “automatiquement” des outils.
Concrètement, ça pousse vers une habitude : la première ouverture d’un repo inconnu se fait dans un environnement isolé. VM, devcontainer, machine dédiée, profil OS séparé, peu importe. Le but est toujours le même : si quelque chose tente une exécution ou une exfiltration, ça tombe dans un bac à sable avec zéro secret intéressant.
Et surtout, je ne laisse pas un agent “auto-run” des actions depuis un repo. Tout ce qui ressemble à “on a configuré des hooks pour t’aider” doit être traité comme “on a configuré un mécanisme d’exécution”. Parce que c’est exactement ça.
Sandboxer Claude Code (sans te ruiner la vie)
Tu n’as pas besoin d’un bunker. Tu as besoin d’une séparation nette entre “poste de confiance” et “environnement d’exécution”. Si tu es déjà à l’aise avec Docker ou un devcontainer, tu as une solution pragmatique : l’agent et le repo tournent dans un conteneur, avec un accès réseau contrôlé, et sans montage de ton $HOME complet.
Le truc à éviter absolument, c’est le conteneur “confort” qui monte tout ton répertoire utilisateur, ton SSH agent, tes credentials cloud et ton cache npm. Là tu as juste déplacé le problème dans une boîte.
Un point bête mais efficace : démarre par monter le repo en lecture seule quand tu inspectes. Ça coupe déjà une classe d’actions destructrices ou furtives. Et tant que tu n’as pas décidé que le repo est “clean”, tu n’as aucune raison de lui donner l’accès écriture à ton environnement.
# Inspection rapide d'un repo inconnu : chercher des configs/outils “agent” et des appels suspects
# (adapte les patterns à ton outillage)
rg -n "(mcp|hook|claude|anthropic|tool|server|curl\s+http|wget\s+http|nc\s+|ssh\s+|base64\s+-d)" .
# Cherche aussi les scripts qui s'exécutent “tout seuls” dans ton écosystème
rg -n "(postinstall|preinstall|prepare|precommit|postcheckout|postmerge)" package.json .
Ce n’est pas une preuve d’attaque. C’est juste une façon de réduire l’effet “je découvre après”. Si tu trouves une config MCP ou des hooks liés à l’agent, tu les lis comme tu lirais un script shell : où ça appelle, quoi ça exécute, quelles données ça touche, quel réseau ça ouvre.
Les secrets : arrête de les exposer “par ergonomie”
Le repo piégé ne vole pas de la magie. Il vole ce que tu lui laisses à portée de main. Et sur un poste de dev moderne, il y a beaucoup trop de choses à portée de main.
Le premier gros levier, c’est de réduire ce que ton process peut lire. Si Claude Code (ou ton IDE, ou ton terminal) tourne avec un environnement bourré de variables (tokens GitHub, clés cloud, accès Sentry, API Stripe), tu as déjà perdu le principe du moindre privilège. Les variables d’environnement sont pratiques, mais elles sont aussi un buffet à volonté pour n’importe quel outil qui arrive à exécuter une commande.
Je préfère mille fois des tokens à portée courte, très scopés, séparés par client/projet, et faciles à révoquer. Ça ne rend pas l’attaque impossible, mais ça change le coût. Au lieu de “je prends tout ton GitHub”, tu limites à “je prends un token qui ne peut lire qu’un repo et qui expire”.
Durcissement poste de dev : le minimum qui compte vraiment
La défense réaliste, ce n’est pas “n’utilise pas d’agents”. C’est d’accepter qu’un agent est un logiciel qui fait des actions à ta place, donc qu’il doit tourner dans un cadre plus strict qu’un éditeur de texte.
Déjà, sépare les espaces. Un workspace “client A” ne doit pas partager les mêmes credentials et caches qu’un workspace “client B”. Ça évite les contaminations bêtes, et ça évite surtout qu’un repo inconnu serve de passerelle vers tes autres projets. Sur macOS et Linux, un utilisateur OS dédié par “zone” fait le job. Sur Windows, des profils séparés ou une VM dédiée, idem.
Ensuite, impose-toi une discipline sur les permissions réseau. Quand j’inspecte un repo louche ou externe, je préfère que l’environnement n’ait pas le droit de parler à Internet librement. C’est frustrant cinq minutes. C’est salvateur le jour où une config tente de “télécharger un modèle”, “installer un outil”, ou “envoyer des métriques”.
Enfin, ne donne pas d’auto-approval. Les agents ont souvent une notion de “tools” qu’ils peuvent appeler. L’ergonomie pousse à autoriser large parce que sinon ça casse le flow. Oui. Et c’est exactement ce que l’attaquant veut.
Côté équipe : revue dédiée et détection (sinon tu voles à l’aveugle)
Le problème des configs “agent/outillage”, c’est qu’elles ne sont pas revues avec la même sévérité qu’un changement applicatif. Personne ne veut passer trente minutes sur un fichier de config. Pourtant, c’est souvent là que la surface d’exécution se cache.
Donc je tranche : dans une équipe, tout changement qui touche à des hooks, à une config d’agent, à des définitions MCP, à des scripts d’automatisation, doit avoir une revue dédiée. Pas forcément par un “security champion”. Par quelqu’un qui a le réflexe de poser deux questions simples : « qu’est-ce que ça exécute ? » et « quelles données ça peut lire ou envoyer ? »
Et tu ajoutes un peu de mécanique. Secret scanning côté git, évidemment. Mais aussi une détection très terre-à-terre sur l’apparition de nouveaux fichiers de config “agent”, ou sur l’ajout de nouveaux appels réseau dans des scripts. Si tu ne sais pas détecter ça, tu dépends de l’attention des gens. Mauvaise stratégie.
Ce que j’attends d’un outil comme Claude Code
Je vais être direct : si un outil exécute des commandes locales parce qu’un repo l’a “configuré”, il doit se comporter comme un navigateur face à un site inconnu. Permissions explicites, affichées clairement, mémorisées finement, et révocables. Une autorisation globale “oui fais ce que tu veux dans ce repo” est trop dangereuse dans la vraie vie.
Je veux aussi une séparation nette entre ce qui est configurable et ce qui est exécutable. Si tu me laisses committer de la config dans un repo, tu dois me donner des garde-fous pour la valider, la comprendre, et l’isoler. Et je veux une visibilité très claire quand une action touche au système de fichiers en dehors du repo, quand elle lit des variables d’environnement, ou quand elle déclenche du réseau sortant.
En attendant que tous les outils soient à ce niveau, la réalité est simple : c’est à toi de blinder ton poste, et de traiter les repos comme non fiables. Ce n’est pas glamour. C’est juste la seule posture qui tient quand “ouvrir un projet” peut devenir “autoriser un agent”.
