Injection par fichier d'instructions : comment AGENTS.md et CLAUDE.md détournent les agents de code

Qu'est-ce que l'injection par fichier d'instructions ?

L'injection par fichier d'instructions est une attaque de prompt injection indirecte où la charge utile vit dans un fichier du dépôt que l'agent de code charge comme consigne projet de confiance, et non comme entrée non fiable. L'attaquant ne parle jamais au modèle. Il committe un fichier, et l'agent le lit à votre place, sur votre machine, avec vos credentials.

Il faut être précis sur ce qui distingue cette classe du prompt injection que tout le monde connaît déjà. L'injection indirecte classique cache des instructions dans du contenu que le modèle va chercher : une page web, un ticket Jira, le corps d'une issue. Le modèle est censé traiter cela comme de la donnée, et la faille est qu'il le traite parfois comme une instruction. L'injection par fichier d'instructions inverse le cadrage. Ces fichiers sont conçus pour être des instructions. Les charger comme politique n'est pas un bug, c'est la fonctionnalité documentée. CLAUDE.md existe pour qu'un dépôt puisse expliquer à l'agent comment le projet fonctionne. AGENTS.md existe pour que l'agent récupère les conventions sans qu'on lui dise. Toute la proposition de valeur, c'est que l'agent obéit au fichier.

La vulnérabilité n'est donc pas « le modèle a confondu donnée et instruction ». La vulnérabilité, c'est que le fichier fait autorité et que sa paternité n'est pas vérifiée. La Cloud Security Alliance l'a écrit noir sur blanc dans sa note de recherche de mars 2026 sur l'injection par README : ces fichiers sont chargés au démarrage de session et traités avec un niveau de confiance qui approche l'autorité du prompt système, donc un adversaire capable de les modifier contrôle de fait la politique comportementale de l'agent pour toutes les interactions suivantes dans ce dépôt.

“

Une dépendance doit être installée pour vous nuire. Un fichier d'instructions n'a qu'à être lu.

Cette asymétrie est ce qui rend l'attaque bon marché. Les attaques supply chain contre les paquets ont besoin d'un registre, d'un bump de version, d'une étape d'installation et généralement d'un script de cycle de vie. L'injection par fichier d'instructions a besoin d'un fichier texte et de quelqu'un qui ouvre le dossier. Il n'y a rien à détecter à l'installation puisque rien n'est installé. Il n'y a rien à attraper dans le graphe de dépendances puisque aucune dépendance n'a changé. Et il n'y a souvent rien dans le diff non plus, parce que sur un clone frais, il n'y a pas de diff du tout.

Les fichiers qui portent l'autorité du prompt système

Le premier geste défensif, c'est de connaître sa propre surface d'instructions. La plupart des équipes la sous-estiment d'un facteur cinq, parce qu'elles pensent « le CLAUDE.md qu'on a écrit » et oublient le fichier de settings, le dossier de skills, la config MCP et les surcharges par sous-répertoire.

Deux lignes méritent un second regard.

La ligne .claude/settings.json n'est pas une métaphore. Les hooks sont des commandes shell que l'agent exécute autour de ses propres appels d'outils, et elles sont définies dans un fichier qui vit dans le dépôt. C'est pour ça que CVE-2025-59536 existe : dans Claude Code avant la version 1.0.111, une exécution de code était possible avant que l'utilisateur accepte la boîte de dialogue de confiance au démarrage, via des hooks projet non fiables définis dans .claude/settings.json. Score CVSS v4.0 de 8.7. Le correctif est arrivé en 1.0.111, et la leçon a survécu au patch : un fichier JSON dans un dépôt était une primitive d'exécution de code à distance parce que l'agent était conçu pour exécuter ce qu'il déclarait.

La dernière ligne est celle qui ne cesse de grandir. Chaque surface qu'un agent lit pendant son travail ordinaire est un canal candidat, et les chercheurs en trouvent de nouveaux en continu. La Cloud Security Alliance a documenté du prompt injection atteignant claude-code-action via GitHub Actions, et la recherche GitInject publiée en juin 2026 a catalogué des cas réels de prompt injection dans les pipelines CI/CD pilotés par IA. Si l'agent le lit, un attaquant peut l'écrire.

Pourquoi la boîte de dialogue de confiance n'est pas une frontière de sécurité

Tous les agents sérieux affichent aujourd'hui une demande de consentement la première fois que vous ouvrez un dossier inconnu. C'est un contrôle réellement utile, et c'est aussi le plus mal compris de la catégorie, à cause de ce qu'il demande vraiment.

Il demande si vous faites confiance au répertoire. Il ne dit rien, et ne peut rien dire, sur le contenu des fichiers d'instructions qu'il contient. Le consentement est accordé à la granularité d'un dossier, puis appliqué à une quantité arbitraire de texte de politique contrôlé par l'attaquant. On vous pose une question, une fois, et vous y répondez avant d'avoir lu le moindre fichier de règles.

La démonstration la plus nette de cet écart vient de Hookify, un plugin distribué par le marketplace officiel Claude Code d'Anthropic. Hookify est un moteur de règles : il lit des fichiers de règles depuis le répertoire du projet, exprimés en Markdown avec du front matter YAML, et injecte leur contenu dans le canal de messages système de confiance du sous-système de hooks. Les chercheurs de Pluto Security ont rapporté qu'un attaquant qui dépose un tel fichier dans un dépôt obtient donc un canal de pilotage vers le modèle, pour tout utilisateur qui a Hookify installé et qui ouvre ce dépôt. Face à Claude Opus 4.6, cinq charges comportementales présentées comme d'anodines conventions de projet ont suffi à faire fuiter des variables d'environnement et des secrets locaux.

La réponse d'Anthropic est la partie à retenir. Le rapport a été clos en Informative, working as designed : la boîte de dialogue de confiance du répertoire est la frontière de sécurité, et une fois acceptée, la configuration projet sous .claude/, y compris CLAUDE.md, les hooks projet et la configuration de plugins comme les fichiers de règles Hookify, est chargée intentionnellement.

Cette réponse se défend dans ses propres termes. C'est aussi un énoncé très précis du risque résiduel que vous possédez désormais.

C'est aussi pour ça que « il suffit de lire les fichiers avant d'accepter » échoue en pratique. La surface d'instructions est éparpillée entre un fichier de settings, un dossier de règles, une convention Markdown par sous-répertoire, un dossier de skills et une config MCP. Les charges se cachent dans des commentaires HTML qui ne rendent rien. Et dès que vous clonez un monorepo, l'arborescence peut contenir une douzaine de fichiers d'instructions imbriqués, dont chacun peut surcharger ceux du dessus.

Anatomie de l'attaque : une minute cinquante et une

Le test technique piégé documenté par Mitiga en juin 2026 est l'exemple public le plus propre, parce que les horodatages montrent exactement le peu de temps dont dispose un humain pour intervenir.

Cloner un dépôt d'apparence normaleL'agent charge .cursor/rules, CLAUDE.md, les commentaires du README, .cursor/mcp.jsonL'agent récolte les credentials cloud et clusterL'agent exfiltre via un appel d'outil MCP

Lisez ce tableau comme un exercice de réponse à incident et le problème devient évident. La fenêtre entre la première action hostile et l'exfiltration complète est sous les deux minutes. Il n'y a pas de pull request. Il n'y a pas de build. Il n'y a aucun artefact à scanner. Tous les contrôles situés en aval du commit regardent au mauvais endroit, parce que l'attaque était terminée avant qu'une seule ligne de code soit écrite, et a fortiori relue.

Notez aussi ce dont l'attaquant n'a pas eu besoin. Pas de zero-day. Pas de paquet malveillant. Pas de compte mainteneur compromis. Il lui fallait un prétexte plausible pour que vous cloniez un dépôt, ce qui, pour quiconque recrute ou cherche un poste, est l'ingénierie sociale la plus facile du métier.

Six façons dont un fichier d'instructions se fait empoisonner

Le test technique est une voie de livraison. Ce n'est pas la partie intéressante du modèle de menace, puisqu'elle exige que vous cloniez quelque chose de nouveau. Voici les voies qui atteignent des dépôts auxquels vous faites déjà confiance.

1. Le dépôt qu'on vous a demandé de cloner

Exercices d'entretien, reproductions de bug, « tu peux jeter un œil à ça », dépôts d'atelier de conférence, templates de démarrage. Tout ce qui arrive avec une raison légitime de lancer un agent dedans. Le cas Mitiga est cette voie, et elle marche parce que la demande est authentique et la charge invisible.

2. Une pull request depuis un fork

C'est la voie qui passe à l'échelle, parce qu'elle atteint votre dépôt sans aucune ingénierie sociale. Si un workflow d'agent tourne avec des permissions d'écriture sur des événements venant de forks, la branche d'un contributeur peut ajouter ou modifier AGENTS.md, .clinerules ou un dossier de règles, et l'agent lira la version de l'attaquant. La chaîne Clinejection, divulguée publiquement le 9 février 2026 et documentée par Snyk, est la version industrielle de ce schéma : du prompt injection via les titres d'issues a transformé le workflow de triage automatique de Cline en vecteur d'attaque supply chain, et un acteur inconnu s'en est servi pour publier une version non autorisée du CLI Cline sur npm pendant une fenêtre de huit heures.

3. Un skill ou un plugin de marketplace

Les skills d'agent sont des fichiers d'instructions dotés d'un canal de distribution, ce qui est la pire combinaison possible. L'étude ToxicSkills de Snyk sur le registre ClawHub a trouvé du prompt injection dans 36 % des skills analysés et catalogué 1 467 charges malveillantes. Comme les skills persistent d'une session à l'autre une fois activés, une seule décision d'installation continue de façonner le comportement de l'agent indéfiniment, dans tous les dépôts que vous ouvrez ensuite. L'OWASP maintient désormais un Agentic Skills Top 10, ce qui vous dit à quelle vitesse c'est devenu une catégorie à part entière.

4. Un échange de config MCP

.cursor/mcp.json et ses équivalents déclarent quels outils existent et ce que disent leurs descriptions. Changez la config et vous changez les actions disponibles pour l'agent ; changez la description d'un outil et vous changez la compréhension qu'a le modèle de ce que fait cette action. C'est exactement le mécanisme du tool poisoning MCP, que nous avons couvert dans sécurité MCP et tool poisoning, qui arrive ici par un fichier du dépôt au lieu d'un serveur.

5. Un fichier d'instructions vendored ou transitif

Les fichiers d'instructions voyagent. Un sous-arbre vendored, un sous-module git, un template scaffoldé, un dossier node_modules que l'agent décide de lire : chacun peut porter son propre AGENTS.md. Comme la plupart des agents parcourent l'arborescence et chargent ce qu'ils trouvent, un fichier imbriqué placé au fond d'une dépendance peut discrètement surcharger les conventions que vous avez écrites à la racine.

6. Votre propre dépôt, depuis l'intérieur

La voie la moins spectaculaire et la plus probable. Les fichiers d'instructions échappent généralement à la culture de revue qui entoure le code source. Ils ne sont pas dans CODEOWNERS, ils ne déclenchent aucun relecteur obligatoire, et ils se lisent comme de la documentation. N'importe qui avec un accès en écriture, y compris un compte développeur compromis ou un contributeur bien intentionné qui a copié une règle depuis un article de blog, peut changer la politique de fonctionnement de tous les agents de l'équipe sans qu'un seul œil sécurité passe sur le diff.

Ce que couvrent les contrôles natifs, et ce qu'ils ne couvrent pas

Les éditeurs d'agents ont livré de vrais contrôles, et il serait malhonnête de laisser croire le contraire. Les sandbox limitent où atterrissent les écritures. Les échelles d'approbation créent des points de contrôle. Les défauts réseau sont fermés dans plusieurs modes cloud. Des allowlists et deny lists de terminal existent. Antigravity livre une allowlist d'URL navigateur précisément pour couper la voie d'injection par les pages récupérées. Tout cela réduit le risque.

L'écart est plus étroit et plus précis que « les agents ne sont pas sûrs ».

Dit simplement : les contrôles parlent de capacité, et l'injection par fichier d'instructions parle d'autorité. Le sandboxing répond à « à quoi ce processus peut-il toucher ». Il n'a rien à dire sur « de qui le modèle suit-il les instructions ». Ce sont deux axes orthogonaux, et c'est pourquoi un agent parfaitement sandboxé lira volontiers un fichier de credentials et le tendra à un outil, si la politique qu'il a chargée le lui a demandé.

C'est le même point structurel que l'OWASP répète à propos des systèmes agentiques en production, où le prompt injection reste le premier moteur des échecs de sécurité plutôt qu'une catégorie résolue.

Huit contrôles qui réduisent réellement le risque

Rien ici n'exige un nouvel éditeur. L'essentiel relève de la politique et de la plomberie, et ça vaut le coup de le faire avant d'acheter quoi que ce soit.

Deux choses que cette liste ne contient délibérément pas. Elle ne vous dit pas d'arrêter d'utiliser des fichiers d'instructions, parce que c'est le mécanisme qui rend les agents utiles sur une vraie base de code et que les retirer revient à faire deviner l'agent. Et elle ne vous dit pas de lire chaque fichier de règles avant d'accepter une dialogue de confiance, parce que ce conseil ne survit pas au contact d'un monorepo.

Là où les contrôles s'arrêtent : les fichiers d'instructions sont du code que personne ne relit

Appliquez les huit contrôles ci-dessus et vous aurez fermé les voies de livraison que vous voyez. Ce qui reste est le problème structurel, et c'est la raison pour laquelle nous avons construit CybeDefend comme ça.

Un fichier d'instructions est une politique exécutable qu'aucune partie de votre chaîne d'outils ne lit comme du code. Votre scanner SAST parse du code source ; il ne parse pas du Markdown qui reprogramme un agent. Votre scanner de dépendances lit des manifestes ; un fichier de règles n'a pas de manifeste. Votre scanner de secrets cherche des clés ; cette charge n'en contient aucune. Et votre revue de pull request, l'endroit où vit la sécurité applicative depuis quinze ans, ne voit le changement qu'après qu'un agent a déjà passé une session à lui obéir. La chronologie Mitiga en est la preuve : tout l'incident s'est terminé 1 minute 51 après l'ouverture d'un dossier, soit environ mille fois plus vite que le cycle de revue censé l'attraper.

Ce décalage de cadence est la thèse de tout ce site. La revue de sécurité comme barrière supposait un goulot humain entre l'intention et le code. Les agents ont supprimé le goulot. Nous avons écrit sur la forme générale du problème dans sécurité des agents de code IA, et l'injection par fichier d'instructions en est l'instance la plus tranchante, parce qu'ici la charge de l'attaquant et le manuel de fonctionnement de l'agent sont littéralement le même fichier.

Le contrôle doit donc se situer là où la décision se prend, c'est-à-dire dans la boucle de l'agent et non en aval.

En pratique, cela veut dire trois choses pour cette classe d'attaque en particulier.

Vos règles arrivent avec plus d'autorité que celles du dépôt. VibeDefend s'installe dans l'agent sous forme de serveur MCP plus hooks, ce qui veut dire que la politique reçue par le modèle est celle que votre organisation a écrite, pas celle qui se trouvait committée dans le dossier. Un fichier du dépôt qui demande à l'agent de lire ~/.aws/credentials argumente désormais contre une règle arrivée avant lui.

Le garde-fou se déclenche sur l'action, pas sur le diff. Les hooks évaluent l'appel d'outil avant son exécution. Lire un fichier de credentials, envoyer un dump d'environnement dans curl, invoquer un outil dont la description a changé depuis hier : ce sont des décisions que l'agent prend en pleine session, et c'est le seul endroit où un contrôle peut encore dire non.

Les findings sont dans la boucle, pas dans un dashboard. L'agent a un accès live à ce que nos scanners ont trouvé sur le code, les dépendances, les secrets, l'infrastructure et les pipelines, donc quand il propose un changement il raisonne sur l'état de sécurité réel du dépôt au lieu de deviner. C'est aussi ce qui lui permet de remarquer que le pipeline qu'on vient de lui demander de modifier tourne sur des événements de fork avec des permissions d'écriture.

Rien de tout cela ne supprime le besoin des huit contrôles. Cela change ce qui se passe dans l'intervalle qu'ils ne peuvent pas fermer, à savoir les quatre-vingt-dix secondes entre l'ouverture d'un dossier et la sortie d'un secret.

Questions fréquentes

Un fichier Markdown peut-il vraiment exécuter du code ?

Pas tout seul, et c'est ce qui le rend efficace. Le Markdown fournit les instructions ; l'agent fournit l'exécution. Si l'agent a un accès shell et l'auto-approve activé, un fichier d'instructions est fonctionnellement un script dont l'interpréteur est le modèle. Le seul cas où le fichier est plus proche d'une exécution littérale, c'est un fichier de settings qui déclare des hooks, ce qui a fait de CVE-2025-59536 une exécution de code à distance dans Claude Code avant 1.0.111.

Est-ce sûr de committer un AGENTS.md ou un CLAUDE.md dans mon dépôt ?

Oui, et vous devriez. Le risque n'est pas d'en avoir un, c'est que personne ne le possède. Mettez le fichier sous CODEOWNERS avec un relecteur sécurité, exigez une revue sur les changements, et auditez les copies imbriquées plus profond dans l'arborescence. Le problème, c'est un fichier d'instructions non relu ; un fichier relu est de la documentation qui configure aussi vos agents.

La boîte de dialogue de confiance me protège-t-elle ?

Elle protège le répertoire, pas le contenu. Anthropic a énoncé cette position explicitement en clôturant le rapport Hookify : une fois la dialogue de confiance du répertoire acceptée, la configuration projet sous .claude/, y compris CLAUDE.md, les hooks projet et les fichiers de règles de plugins, est chargée intentionnellement. Accepter la dialogue, c'est vous qui vous portez garant des fichiers d'instructions, pas l'éditeur qui les valide.

Quels fichiers mettre en revue obligatoire ?

Au minimum : AGENTS.md, CLAUDE.md, GEMINI.md, .clinerules, .cursorrules, et les dossiers .cursor/, .claude/, .windsurf/ ainsi que .github/copilot-instructions.md. Ajoutez tout fichier de configuration MCP et tout SKILL.md de l'arborescence. Puis lancez une recherche récursive, parce que ce sont les copies imbriquées qui passent à travers.

Peut-on détecter l'injection par fichier d'instructions au grep ?

Partiellement, et ça vaut le coup. Cherchez les commentaires HTML dans le Markdown, les caractères Unicode de largeur nulle et bidirectionnels, les blobs base64, et les verbes qui comptent : credentials, ~/.aws, ~/.kube, curl, env, export. Ce que le grep ne peut pas juger, c'est l'intention, parce que les charges efficaces se lisent comme des conventions de projet ordinaires. Dans la recherche Hookify, cinq charges présentées comme d'anodines conventions ont suffi à déclencher une fuite de secrets.

Est-ce que ça touche aussi Copilot et Cursor, ou seulement Claude Code ?

Tous. Le mécanisme est architectural, pas propre à un éditeur : tous les agents grand public ont une convention d'instructions au niveau du dépôt, et tous la chargent comme consigne projet de confiance. Nous couvrons les spécificités par agent dans les guides Claude Code, Cursor, GitHub Copilot, OpenAI Codex et Windsurf.

En quoi est-ce différent du slopsquatting ou d'un paquet malveillant ?

Le slopsquatting exploite un nom de dépendance halluciné pour qu'une installation tire du code attaquant, ce que nous avons expliqué dans qu'est-ce que le slopsquatting. L'injection par fichier d'instructions n'a besoin d'aucune installation ni d'aucun registre. Elle change ce que l'agent cherche à faire, plutôt que le code qui finit dans l'arborescence, et c'est pourquoi le scan de dépendances y est structurellement aveugle.

Que faire en premier si je pense qu'un agent a suivi un fichier d'instructions empoisonné ?

Traitez-le comme un incident de credentials, pas comme un incident de code. Faites tourner tout ce que l'agent pouvait lire : clés cloud, kubeconfig, tokens de providers, tout ce qui était dans l'environnement. Puis récupérez le transcript de session de l'agent et lisez les appels d'outils dans l'ordre, parce que c'est votre seul enregistrement fiable de ce qui s'est réellement exécuté. Ne regardez le diff qu'après, puisque dans les cas documentés aucun code n'avait été modifié du tout.