Sécurité AGENTS.md : comment des fichiers étrangers pilotent les agents IA

Dans un cas, un fichier texte anodin dans le dossier Téléchargements a suffi pour qu'un agent de codage IA veuille installer un paquet malveillant. Cet article sur la sécurité AGENTS.md décrit ce qui s'est passé, quels fichiers d'instructions Codex, Claude Code et Cursor chargent, et quels réglages et mesures peuvent empêcher les dégâts.

Une découverte sur l'ordinateur d'un client et ses conséquences

L'éditeur de sécurité Forever Security a fait la découverte suivante : sur l'ordinateur d'un client, le dossier Téléchargements contenait un fichier d'instructions nommé AGENTS.md, censé amener un agent de codage IA à installer un paquet npm. Ce fichier n'est pas un programme, mais il agit comme une consigne.

Ce qui s'est passé : découverte dans le dossier Téléchargements, nouveau test et taux de réussite

Le point de départ était une découverte réelle. Le fichier se trouvait dans le dossier Téléchargements d'un développeur. Ce dossier était en même temps le répertoire de travail de l'agent. L'agent voulait installer le paquet npm function-color. Selon ses propres dires, Forever Security l'a arrêté avant que du code ne s'exécute. Les chercheurs n'ont pas pu établir comment le fichier était arrivé dans le dossier.

Le paquet function-color entraîne un autre paquet nommé function-flag. Celui-ci télécharge un logiciel malveillant pour Windows et le lance. CloudSEK et Checkmarx désignent la campagne sous le nom de MALFEX.

Nouveau test avec Codex

Forever Security a reproduit l'attaque dans une machine virtuelle isolée. Le vrai fichier demandait à Codex d'enregistrer un serveur dans le fichier ~/.codex/config.toml et d'exécuter une commande installant le paquet. Comme cette configuration s'applique à toutes les sessions Codex de la machine, la modification est durable et agit dans chaque dossier. Le taux de réussite était d'environ 90 %.

Nouveau test avec Claude Code

Pour Claude Code, il s'agissait d'un autre fichier. Un CLAUDE.md piégé se présentait comme la configuration d'une passerelle interne et devait amener l'agent à inscrire une adresse étrangère comme cible d'API dans un fichier de paramètres du projet. Le trafic API passerait alors par un serveur des chercheurs. Cela divulgue le jeton d'authentification de la session, et le serveur peut renvoyer des commandes que l'agent exécute. Claude Code demande généralement une confirmation pour de telles écritures et refuse souvent celles qui paraissent suspectes. Seule une justification longue, presque à la manière d'une documentation pour développeurs, a obtenu une validation dans environ la moitié des cas.

Les deux chiffres ne sont pas directement comparables. Il s'agit d'agents différents, de fichiers différents et d'objectifs différents. La taille de l'échantillon et la configuration du test (sandbox, mode de validation) ne sont pas connues.

Télémétrie : le lancement dans le dossier Téléchargements est-il répandu ?

Environ la moitié des clients de Forever Security lancent un agent de codage dans le dossier Téléchargements, et environ un quart des sessions ouvrent un navigateur. BleepingComputer fait état de plus de 1 300 sessions Claude Code lancées depuis ce dossier. Ce sont dans les deux cas des données de l'éditeur sur sa propre clientèle, sans vérification indépendante. Il n'est pas prouvé que des attaquants déposent réellement de tels fichiers via des téléchargements dans le navigateur. La preuve de concept n'a téléchargé qu'un fichier inoffensif.

Sécurité AGENTS.md : pourquoi les fichiers d'instructions étrangers sont un risque

Au démarrage, les agents de codage lisent les fichiers d'instructions du répertoire de travail. On y trouve des instructions de compilation, des règles de style ou des commandes de test. L'agent traite ce contenu comme des consignes de l'utilisateur. Il ne distingue pas de manière fiable si le fichier vient de l'équipe ou d'une source étrangère. C'est le cœur d'une injection de prompt indirecte contre un agent de codage : l'instruction ne vient pas du champ de saisie, mais du contexte.

Deux propriétés inoffensives en soi forment ensemble la chaîne. Premièrement, les agents font confiance aux fichiers du dossier ouvert. Deuxièmement, des sites web peuvent déposer des fichiers dans le dossier Téléchargements sans demander, si le navigateur est réglé ainsi. Par défaut, Chrome, Edge et Firefox enregistrent dans ce dossier sans demander l'emplacement et n'affichent qu'une notification. Brave a demandé au préalable lors du test. Le fichier porte le nom et le contenu que le site lui donne.

La documentation de Claude Code décrit CLAUDE.md comme du contexte et non comme une configuration imposée. Pour les blocages, elle recommande les hooks. D'où la règle de base pour tout ce qui suit : ce qui figure seulement dans le texte d'un fichier, un agent peut le suivre ou l'ignorer. Ce qui figure dans les autorisations, le programme l'impose.

Le navigateur n'est pas le seul chemin

Le dossier Téléchargements est au centre de ce cas, mais il n'est pas seul. Le NVIDIA Developer Blog décrit une voie apparentée : un paquet de dépendance compromis crée lui-même un AGENTS.md. Des dépôts clonés, des archives décompressées et des scripts de build peuvent aussi introduire des fichiers d'instructions étrangers dans un dossier de projet. Le lieu de lancement réduit donc la surface d'attaque, il ne la supprime pas.

Mise en perspective : ce que disent les chercheurs et les éditeurs

Les chercheurs de Forever Security expliquent qu'il n'y a rien à corriger chez OpenAI et Anthropic. L'agent suit son fichier d'instructions comme prévu, comme un navigateur qui affiche une page d'hameçonnage. C'est l'appréciation des chercheurs. Les deux articles ne contiennent pas de prise de position propre des éditeurs sur cette attaque. BleepingComputer signale seulement que les deux éditeurs recommandent de lancer les agents dans le répertoire du projet concerné. La responsabilité incombe donc aux utilisateurs et aux organisations qui déploient des agents.

Les risques des agents autonomes sont un sujet plus vaste. Des articles sur le pouvoir sans contrôle des agents IA et sur l'ère des agents IA expliquent pourquoi des agents dotés de leurs propres droits d'action ont besoin d'autres protections que les logiciels classiques.

Quels fichiers d'instructions Codex, Claude Code et Cursor chargent

Ce qui compte, c'est ce qui est considéré comme le dossier du projet : le dossier dans lequel l'agent est lancé. Celui qui lance l'agent dans le dossier Téléchargements fait de chaque fichier qui s'y trouve un contexte de projet. L'aperçu suivant résume la documentation des éditeurs (état au 26/10/2026). La documentation évolue vite ; en cas de doute, la version actuelle fait foi.

Codex

Selon sa documentation, Codex lit d'abord un fichier global dans le répertoire Codex (~/.codex, modifiable via CODEX_HOME), à savoir AGENTS.override.md ou AGENTS.md. Viennent ensuite les fichiers depuis la racine du projet, généralement la racine Git, jusqu'au dossier courant. Au plus un fichier par dossier est pris en compte : AGENTS.override.md, AGENTS.md ou un nom de remplacement configuré. La limite totale est de 32 Kio. Si aucune racine de projet n'est trouvée, seul le dossier courant compte. C'est exactement le cas du dossier Téléchargements, car il n'y a généralement pas de dépôt Git.

Claude Code et sécurité de CLAUDE.md

D'après la documentation sur la mémoire, Claude Code charge CLAUDE.md et CLAUDE.local.md depuis le répertoire de travail et tous les répertoires au-dessus, et si besoin aussi depuis les sous-dossiers. S'y ajoutent ~/.claude/CLAUDE.md, la politique gérée du système et les fichiers de .claude/rules/. Pour la sécurité de CLAUDE.md, cela signifie qu'un point de départ trop haut, par exemple le répertoire personnel, agrandit aussi la surface, car des fichiers situés au-dessus et à côté sont lus également.

Selon la documentation, Claude Code lit AGENTS.md depuis la version 2.1.277. Par défaut, cela ne se produit que s'il n'y a pas de CLAUDE.md ou de CLAUDE.local.md dans le répertoire de travail ou au-dessus. Le réglage des instructions de projet permet de modifier ce comportement : claude-md-or-agents-md est la valeur par défaut, claude-md-and-agents-md lit les deux, managed-only n'admet que des instructions gérées de manière centralisée.

Cursor

Selon sa documentation, Cursor connaît des règles de projet dans .cursor/rules/ (fichiers au format .mdc, y compris dans des sous-dossiers) et AGENTS.md à la racine du projet ainsi que dans les sous-répertoires. Les fichiers imbriqués s'appliquent à leur périmètre, le plus spécifique l'emporte. S'y ajoutent les User Rules personnelles dans les paramètres et les Team Rules via le tableau de bord.

Les fichiers de configuration, la véritable cible

Le cas montre que le fichier d'instructions n'est souvent que l'outil. La cible, ce sont les fichiers de configuration dans lesquels une modification agit durablement. Pour Codex, il s'agit de ~/.codex/config.toml, dont la modification concerne toutes les sessions. Pour Claude Code, c'est le fichier de paramètres .claude/settings.json, dans lequel la cible d'API peut être définie via une variable d'environnement. Les deux fichiers ont donc leur place sur la liste des fichiers qu'un agent ne doit pas modifier sans confirmation.

Sécuriser les agents de codage IA : autorisations, hooks et sandbox Codex

La question qui vient naturellement est de savoir s'il suffit d'éviter le dossier Téléchargements.

Les mesures interviennent à trois niveaux : ce que l'agent peut faire sans confirmation, ce qu'un hook bloque indépendamment du modèle et ce que la sandbox limite techniquement.

Règles d'autorisation dans Claude Code

Claude Code connaît des règles de niveau allow, ask et deny par outil (documentation sur les autorisations). Par défaut, l'agent demande avant les commandes shell et les modifications de fichiers. Une règle deny s'applique même si l'agent veut suivre un fichier d'instructions. Un exemple pour le fichier .claude/settings.json :

{
  "permissions": {
    "deny": [
      "Bash(npm install *)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Edit(.claude/**)",
      "Edit(~/.codex/**)"
    ]
  }
}

La notation suit les exemples de la documentation : les règles Bash comparent le texte de la commande avec * comme joker, les règles de chemin pour la lecture et la modification utilisent la syntaxe de gitignore, ~/ désigne le répertoire personnel. Les modifications de fichiers sont régies par Edit(…) ; selon la documentation, les règles pour Write ne sont pas vérifiées par rapport aux chemins. Un blocage de commande n'est en outre pas une garantie, car le même objectif peut souvent être atteint par un autre appel. Les hooks et la sandbox sont prévus pour ce qui ne peut être évité.

Deux fonctions de confort demandent de la prudence. La validation avec « ne plus demander » vaut, selon l'outil, durablement pour un dépôt, et dans les modes automatiques, ce n'est plus l'humain qui décide de chaque action. Ni l'une ni l'autre n'a sa place dans des environnements contenant du code étranger.

Hooks : bloquer indépendamment du modèle

Un hook PreToolUse s'exécute avant l'appel d'outil et peut le bloquer, même si le modèle le juge correct. Le guide des hooks montre le schéma : le script lit l'entrée au format JSON sur l'entrée standard et se termine avec un code de sortie pour bloquer. Il est enregistré dans le fichier de paramètres :

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/block-installs.sh"
          }
        ]
      }
    ]
  }
}

Le script block-installs.sh lit avec jq la commande dans le champ tool_input.command, la compare à une liste noire (par exemple npm install ou la combinaison de curl et d'un shell) ou, mieux, à une liste blanche, et en cas de correspondance renvoie une justification sur la sortie d'erreur avec le code 2. Un deuxième levier peu connu est le hook InstructionsLoaded. Il journalise les fichiers d'instructions chargés. Selon la documentation, il ne se déclenche toutefois pas pour un AGENTS.md chargé via le réglage, mais seulement lorsqu'un CLAUDE.md l'importe. Une équipe ne devrait donc pas s'y fier seule.

Consignes centrales avec les Managed Settings

Pour les équipes, les paramètres gérés sont le levier le plus efficace. Selon la documentation sur les Managed Settings, permissions.deny, sandbox.enabled et env peuvent être imposés de manière centralisée. Une cible d'API glissée via un fichier d'instructions, comme dans le test avec Claude Code, serait alors nettement plus difficile à imposer. À titre de mise en perspective : il s'agit d'une déduction tirée de la documentation, pas d'un effet prouvé dans le cas de Forever Security.

Codex : validations, niveau de confiance et modes de sandbox

Pour la sandbox et les autorisations de Codex, la documentation sur les validations et la sécurité distingue deux niveaux. La politique de validation détermine quand Codex demande (par exemple on-request ou never). Le mode sandbox détermine ce qui est techniquement possible : read-only, workspace-write ou danger-full-access. En mode workspace-write, le réseau est désactivé par défaut.

S'y ajoute un niveau de confiance par projet dans ~/.codex/config.toml (trust_level). Selon la documentation, les dossiers sous contrôle de version utilisent le mode Auto, c'est-à-dire l'écriture dans l'espace de travail avec confirmation. Les dossiers sans contrôle de version sont en read-only jusqu'à ce que le répertoire soit marqué comme fiable. Un dossier comme Téléchargements est considéré comme non fiable sans ce marquage. Le risque apparaît lorsque les utilisateurs confirment la boîte de dialogue de confiance. L'option –yolo supprime la sandbox et les validations et n'a pas sa place dans les consignes d'équipe. La configuration utilisée par Forever Security pour ses tests n'a pas été communiquée ; on ignore donc si les niveaux de protection par défaut ont joué lors du test.

Cursor

Il n'existe pas d'indication claire de l'éditeur sur les validations de commandes du terminal dans Cursor. D'où simplement le conseil de laisser actives les validations pour les commandes du terminal et de consulter la documentation actuelle de l'éditeur.

Sandbox et isolation : limiter les dégâts même si l'agent suit le fichier

Une sandbox limite ce qu'un agent peut faire, même s'il suit une instruction étrangère. La sandbox de Claude Code autorise l'écriture dans le répertoire de travail et les dossiers temporaires. L'accès réseau passe par un proxy avec une liste de domaines autorisés, vide par défaut. Les chemins protégés comme les paramètres de Claude Code, le fichier de démarrage du shell .bashrc et les hooks Git restent en lecture seule. Un exemple :

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    },
    "allowUnsandboxedCommands": false
  }
}

La documentation cite aussi des limites. La sandbox est désactivée par défaut. L'accès en lecture est large, les identifiants doivent être bloqués de manière ciblée. La protection ne s'applique qu'aux commandes shell et à leurs processus enfants, pas aux outils de fichiers intégrés, ni à MCP ni aux hooks. Sans allowUnsandboxedCommands: false, une commande ayant échoué peut être relancée hors de la sandbox. Sous Windows, elle ne fonctionne pas nativement, WSL2 est utilisé à la place. Ce n'est pas une barrière complète contre le code malveillant. Pour une isolation forte, les conteneurs ou les machines virtuelles sont le meilleur choix.

Liste blanche réseau et environnement jetable

Une telle liste blanche aurait rendu plus difficiles le téléchargement du paquet et la redirection de l'API. C'est une appréciation, pas une preuve pour ce cas. Le code inconnu a sa place dans un environnement jetable : conteneur, VM ou Dev Container, sans les identifiants du profil principal. Les jetons devraient avoir une courte durée de vie. En cas de soupçon, il est recommandé de considérer le jeton d'authentification comme compromis et de le renouveler.

Réglage du navigateur pour les téléchargements

Contre les téléchargements silencieux, le réglage qui demande l'emplacement avant chaque enregistrement est utile. Dans Chrome, il s'appelle « Toujours demander où enregistrer les fichiers » et se trouve dans les paramètres sous Téléchargements. Edge et Firefox proposent un équivalent, les intitulés varient selon la version (Firefox : Paramètres, Général, Fichiers et applications). Lors du test de BleepingComputer, Brave a demandé de lui-même. On peut aussi placer le dossier de téléchargement à un endroit qui ne sert jamais de répertoire de travail. Un alias shell ou un hook qui refuse le lancement dans ~/Downloads est une option supplémentaire.

Liste de contrôle pour les équipes et politique d'utilisation des agents de codage

La liste suivante résume les mesures. Elle complète les recommandations des deux articles par les configurations issues de la documentation des éditeurs.

• Les agents ne sont lancés qu'à la racine d'un dépôt de confiance. Téléchargements, Bureau et répertoire personnel sont exclus.
• Les fichiers étrangers comme AGENTS.md, CLAUDE.md ou .cursor/rules sont lus avant d'ouvrir un projet fraîchement cloné ou décompressé.
• Les demandes d'autorisation et la sandbox restent actives. Les modes automatiques et les options comme –yolo ne s'exécutent que dans des environnements isolés.
• L'accès réseau passe par une liste blanche, les identifiants sont hors de portée, les jetons ont une courte durée de vie.
• Les installations de paquets par des agents n'ont lieu qu'après validation, avec fichier de verrouillage et vérification du registre. Le cas de function-color et function-flag montre à quelle vitesse un paquet en entraîne d'autres.
• Les paramètres sont gérés de manière centralisée. Les modifications de ~/.codex/config.toml et de .claude/settings.json sont surveillées.
• Les fichiers d'instructions chargés sont journalisés, dans la mesure où les outils le permettent.
• Plan d'incident : arrêter la session, renouveler jetons et clés, vérifier les fichiers de configuration, retracer les installations de paquets.

Les organisations soumises à des obligations de sécurité de l'information intègrent ces agents dans leur gestion des risques. Cela concerne l'autorisation, la configuration et la preuve que les règles s'appliquent. Un article sur l'agentic coding décrit comment organiser leur utilisation dans les équipes de développement.

Modèle de politique

Une politique concise tient en quelques phrases. Son champ d'application couvre tous les collaborateurs et prestataires qui utilisent des agents de codage IA sur des appareils de l'entreprise ou avec des données de l'entreprise. Les agents ne sont lancés qu'à la racine d'un dépôt vérifié, jamais dans les dossiers Téléchargements, Bureau ou personnel. Les modes automatiques et la désactivation de la sandbox ou des validations ne sont autorisés que dans des environnements jetables isolés, sans identifiants. Les installations de paquets et les modifications de fichiers de configuration nécessitent une validation par les développeurs. La sécurité informatique est responsable des paramètres centraux, la direction de projet du respect des règles dans le projet. Les soupçons sont signalés immédiatement à la sécurité informatique, les jetons concernés sont renouvelés sans délai.

Vérifier ses propres sites web et systèmes

Le cas concerne surtout les postes des développeurs. Celui qui propose lui-même des fichiers en téléchargement fait partie de la chaîne avec son propre site web. Un contrôle de site web montre quels scripts et en-têtes une page délivre, mais il ne vérifie que la page, pas l'ordinateur des développeurs. Pour un contrôle de sécurité systématique en équipe, les Web Security Checks offrent un point de départ.

Conclusion

La responsabilité incombe à l'utilisateur, la technique fixe la limite !

Un fichier texte étranger peut piloter un agent de codage, car l'agent traite les fichiers du dossier de travail comme des instructions. La protection ne devient fiable que grâce à des limites imposées : autorisations, hooks, sandbox, liste blanche réseau et paramètres gérés de manière centralisée.

Reste à savoir si des attaquants utilisent en pratique la voie des téléchargements dans le navigateur et comment le fichier est arrivé chez le client. Ce qui paraît en tout cas important, c'est la sensibilisation des collaborateurs et des développeurs (jusqu'à ce qu'ils disparaissent).