Forever Security indique avoir empêché un agent de code d’installer un paquet npm malveillant après que l’agent a suivi un fichier AGENTS.md présent dans le dossier Téléchargements d’un client. Ses recherches du 22 octobre 2026 font de la provenance des fichiers d’instructions une question de sécurité très concrète pour les équipes qui importent des projets dans des assistants de code. L’entreprise n’a pas établi comment ce fichier client est arrivé là, et ses démonstrations ultérieures doivent être distinguées de la tentative bloquée effectivement observée.
Pour les responsables des plateformes de développement et de la sécurité des terminaux, la réponse utile consiste à examiner quels textes importés peuvent influer sur la configuration d’un agent. La recommandation de Maetra est de traiter tout fichier d’instructions qui demande des modifications persistantes de paramètres comme un élément du contrôle d’entrée logiciel.
Ce que la recherche étaye
Dans son rapport principal, Forever décrit une tentative chez un client impliquant le paquet malveillant function-color. L’entreprise rapporte ensuite des tests contrôlés avec Codex et Claude Code : des instructions pouvaient provoquer des changements de configuration menant à l’exécution de code ou à l’exposition de jetons. Son scénario Codex nécessitait un dossier approuvé. La plupart des essais ont utilisé un substitut inoffensif, le véritable paquet malveillant n’ayant été exécuté qu’une seule fois dans une machine virtuelle isolée.
La couverture du 26 octobre par Help Net Security rend compte de la même recherche. Il s’agit d’un article complémentaire, pas d’une reproduction indépendante. Les éléments disponibles ne montrent pas que tous les agents ou toutes les configurations se comportent de la même façon, ni qu’un site web ait fourni le fichier trouvé sur la machine du client. L’affirmation de Forever selon laquelle les éditeurs n’ont rien à corriger reste l’opinion du chercheur.
Intégrer les fichiers d’instructions au contrôle d’entrée
Ce qui suit relève de l’analyse de Maetra pour les équipes qui gèrent des assistants de code. Un processus d’entrée pour les dépôts ou les archives doit repérer les fichiers qu’un assistant peut interpréter comme des consignes de projet. Examinez-les avant d’accorder à un espace de travail nouvellement importé l’autorité de modifier l’environnement du développeur. Un nom de fichier familier ne permet pas d’établir qui a rédigé le contenu, ni quelles modifications l’utilisateur entendait autoriser.
Commencez par la tâche demandée. Si un employé demande à un assistant d’inspecter une application d’exemple, une demande présente dans cette application pour enregistrer un serveur d’outils persistant mérite un examen séparé. Le relecteur doit identifier le serveur, sa source et la raison pour laquelle il est nécessaire. Affirmer que l’installation est routinière ne répond pas à ces questions.
Cela n’implique pas d’interdire les consignes de projet utiles. Les équipes peuvent conserver des instructions connues à côté de leurs propres dépôts et consigner la manière dont les changements sont relus. La transition risquée à examiner est celle où un texte importé obtient une autorité sur des paramètres ou des identifiants au-delà du projet en cours d’inspection.
Empêcher que des consignes de projet modifient silencieusement des paramètres partagés
Pour une évaluation contrôlée, utilisez un espace de travail jetable sans identifiants de production. Préparez un fichier d’instructions bénin qui demande une modification de paramètres en dehors de cet espace de travail. Convenez du résultat attendu avant d’exécuter le test, puis examinez à la fois la réponse de l’assistant et la configuration obtenue. N’utilisez pas de paquet malveillant pour tester cette limite.
La question d’acceptation est de savoir si la configuration effective est restée dans le périmètre autorisé. Une explication rassurante ne suffit pas si un nouveau serveur ou un nouveau point de terminaison est apparu malgré tout. Conservez les paramètres avant et après, ainsi que l’enregistrement d’action pertinent, afin que le responsable sécurité puisse évaluer ce qui s’est passé.
Testez aussi une session interrompue ou redémarrée. Si l’enregistrement d’un outil légitime est autorisé, déterminez où il persiste et quelles sessions ultérieures l’héritent. Consignez le propriétaire de cette configuration et la manière de la supprimer. Il s’agit de contrôles recommandés, pas d’affirmations sur une fonctionnalité produit non signalée ni sur un test réalisé par Maetra.
Examiner l’effet d’un fichier suspect
La découverte d’instructions inattendues doit conduire à une enquête délimitée. Établissez si l’assistant a lu le fichier, tenté une commande, modifié des paramètres, installé un paquet ou envoyé des identifiants vers une destination inconnue. Ces observations décrivent des niveaux d’exposition différents et peuvent exiger des mesures de remédiation différentes.
Préservez les éléments de preuve sans recopier de secrets actifs dans un ticket ou un rapport partagé. Le responsable sécurité doit évaluer les sessions concernées, les identifiants et les intégrations persistantes. Une installation bloquée peut tout de même justifier une vérification d’éventuels changements de configuration antérieurs ; à lui seul, un fichier texte suspect ne prouve pas que toutes les actions aval possibles ont eu lieu.
Forever recommande d’inspecter les fichiers d’instructions inattendus, de revoir les paramètres de l’agent et de conserver les contrôles d’approbation et d’isolation. Dans les environnements administrés, la tâche opérationnelle supplémentaire consiste à rendre visibles, pour les personnes responsables de l’assistant, la source de ces instructions et les effets qui en résultent.
Passer en revue un flux de travail importé
Choisissez un flux de travail développeur courant, par exemple l’inspection d’un projet d’exemple téléchargé. Identifiez les fichiers d’instructions qu’il importe, les outils que l’assistant peut invoquer et les paramètres qu’il peut modifier. Attribuez un responsable à chaque intégration persistante avant d’élargir les autorisations de ce flux de travail.
Maetra Secure peut aider à examiner les prompts, les messages, les appels d’outils et les sorties à la recherche de menaces à l’exécution. Cette analyse n’établit pas la provenance d’un fichier et ne remplace pas les autorisations du terminal. Le point de départ utile est une action précise de changement de configuration, accompagnée de la preuve qu’elle est restée dans le cadre de la tâche autorisée par l’utilisateur.
L’article de Maetra sur les sorties de sandbox des agents de programmation traite de la question connexe des limites d’exécution.