Un agent de code oublie presque tout entre deux sessions. Les exceptions sont les fichiers qu'il conserve à dessein, ceux qui portent ses instructions permanentes et qui sont relus dans le prompt à chaque démarrage. Un nouvel article montre que ces fichiers sont aussi le seul endroit où une charge utile auto-réplicante peut se cacher, et voyager d'un agent au suivant.

Le 10 août, des chercheurs de la Frontier Red Team d'Anthropic et de l'EPFL, en Suisse, ont publié un article intitulé Mind Viruses. Anthropic en a fait le compte rendu le 13, et The Hacker News l'a couvert le 18. La question qu'il pose est étroite et pratique : une instruction implantée dans un agent d'IA peut-elle se recopier dans un autre, sans humain entre les deux, et continuer ainsi ?

La réponse est oui, et la raison en est un fichier que vous avez déjà.

Ce dont un agent se souvient à dessein

Un agent de code jette sa mémoire de travail entre deux sessions. La fenêtre de contexte se remplit, la session se termine, une tâche s'achève et la suivante démarre à zéro. Presque rien ne se reporte, ce qui est exactement ce que vous voulez la plupart du temps.

Alors l'agent conserve quelques fichiers qui, eux, se reportent. Claude Code lit un CLAUDE.md. D'autres outils lisent un AGENTS.md, ou un GROK.md, ou un index de mémoire chargé au démarrage. Les agents de l'article gardaient un SOUL.md et un MEMORY.md. Quel que soit le nom, le contrat est le même : ce fichier, c'est vous, il énonce vos préférences et vos règles permanentes, et je le relirai dans mon prompt au début de chaque session pour ne pas perdre le fil. C'est là la fonctionnalité. C'est ce qui fait qu'un agent est le vôtre et non celui d'un inconnu par défaut.

Le geste de l'article consiste à remarquer qu'un fichier doté de ces deux propriétés, survivre à la réinitialisation et être relu comme autorité, est un endroit où une charge utile peut vivre. Les chercheurs ont utilisé une recherche évolutionniste pour faire naître de courtes instructions qui, une fois présentes dans un tel fichier, amènent l'agent à faire deux choses : accomplir une action quelconque, et recopier l'instruction en avant, dans le fichier de l'agent suivant. Un ver a besoin exactement de ces deux comportements. Celui-ci est écrit noir sur blanc, en anglais, dans un fichier que l'agent traite comme sa propre mémoire.

Ils l'ont testé de deux façons. Dans la première, une équipe de six agents collaborait dans un espace de travail partagé. Dans la seconde, les agents tournaient en séquence, la sortie de chacun alimentant le suivant, une chaîne de sauts. Les deux sont des formes ordinaires de travail agentique. Une flotte sur un dépôt est une équipe ; un pipeline qui passe les résultats de proche en proche est une chaîne.

La charge utile ne survit pas dans le contexte de l'agent, celui-ci est effacé comme tout le reste. Elle survit dans le fichier que l'agent relit pour se souvenir de lui-même, et elle profite de son tour pour écrire une copie dans le fichier de l'agent suivant.

Les chiffres, et là où ils atterrissent

Les charges utiles étaient de deux sortes. Certaines étaient idéologiques, destinées à implanter une croyance ou un objectif. D'autres étaient des actions concrètes. Les quatre charges d'action sont celles qu'un développeur devrait lire de près, car chacune est une chose que vous ne voulez pas voir un programme faire de lui-même sur votre machine :

crypto-ad écrit un fichier qui fait la promotion d'une cryptomonnaie.
gitwrap marque silencieusement les fichiers que l'agent committe.
deletor supprime des fichiers du répertoire personnel.
curlbash envoie un script d'installation téléchargé droit dans un shell.

Stocker l'instruction dans SOUL.md était la voie efficace : elle représentait 88 % des tentatives de propagation et infectait l'agent suivant dans 55 % des cas. La cacher dans un fichier ordinaire de l'espace de travail marchait bien moins souvent, 17 %, et dans 68 % de ces tentatives l'agent propagateur ne mentionnait même jamais la charge dans l'espace de travail, si bien qu'un humain surveillant les fichiers partagés n'aurait rien vu. Les quatre charges d'action ont survécu à une série de 20 sauts, même lorsque les chercheurs effaçaient les autres fichiers entre les agents. Le fichier de mémoire suffisait à lui seul.

Le modèle qui faisait tourner l'agent comptait, et pas comme on l'imaginerait. La capacité brute ne prédisait pas la résistance. Claude Sonnet 4.6 a refusé les charges utiles et, dans certains essais, est allé plus loin : il a retiré l'instruction malveillante du fichier d'âme et averti les agents auxquels il était connecté. D'autres modèles, dont DeepSeek V3.2, Qwen 3.5 32B et Gemini 3 Flash, ont adopté les charges idéologiques. Que le ver s'arrête ou non dépend donc du modèle que votre agent utilise cette semaine-là, et ce n'est pas une propriété que vous contrôlez d'une tâche à l'autre.

Les chercheurs sont prudents quant à la portée. Ils parlent d'un risque « réel mais actuellement limité ». Lorsqu'ils ont fouillé une archive réelle de publications d'agents, le jeu de données Moltbook, environ 2 000 tentatives de propagation candidates émanant de quelque 400 auteurs jusqu'au 18 mars, ils n'ont trouvé aucun cas où la charge ait sauté d'un agent à un second dans la nature. Et ils ont trouvé une défense qui fonctionne bien : un simple paragraphe dans le prompt système, avertissant le modèle que de telles instructions peuvent apparaître et doivent être refusées, a réduit la propagation à presque zéro.

Cette défense est révélatrice. Elle fonctionne, et elle vit dans la seule couche qu'un attaquant ayant atteint votre fichier de mémoire peut lui aussi être en mesure d'atteindre. Si le ver peut écrire MEMORY.md, la question qui vaut la peine d'être posée est : qu'y a-t-il entre ce fichier et l'agent qui lui obéit, et cette chose dépend-elle du modèle qui décide, correctement et à chaque fois, de dire non ?

Bromure lit le fichier de mémoire en premier

Bromure Agentic Coding se place sur le fil entre votre agent de code et le modèle, et il traite les fichiers d'instructions de l'agent pour exactement ce que l'article montre qu'ils sont : une autorité sur laquelle l'agent va agir, et donc quelque chose à vérifier avant qu'il le fasse.

Deux classifieurs embarqués s'en chargent, et ils se répartissent le travail selon la ligne que trace l'article.

Le premier traite directement le fichier de mémoire. Activez Détecter les instructions malveillantes dans les fichiers CLAUDE.md et similaires, et Bromure évalue CLAUDE.md, AGENTS.md, GROK.md et les autres fichiers d'instructions et de réglages que l'agent charge comme autorité. Il utilise un modèle affiné pour cette tâche, décrit dans un précédent article, parce que la détection ordinaire d'injection de prompt échoue sur un fichier qui est censé n'être que des instructions. La question ici n'est pas « y a-t-il du texte injecté parmi les données » mais « cette instruction est-elle nuisible », et une charge qui dit d'écrire une promotion de cryptomonnaie, ou de supprimer des fichiers sous le répertoire personnel, ou de passer ce script à un shell, est exactement ce que le modèle est entraîné à signaler. Il s'exécute à chaque lecture, côté hôte, quel que soit l'agent qui a déposé le fichier. Un ver qui atteint le MEMORY.md de l'agent suivant doit encore passer devant un lecteur qui n'est pas l'agent et qui n'a pas les incitations de l'agent.

Le second classifieur traite l'autre voie d'arrivée. Quand la charge arrive non comme un fichier de configuration mais comme la sortie d'un autre agent, une page récupérée ou un résultat d'outil, Détecter les injections de prompt dans le code source évalue ce texte avec Prompt Guard de Meta avant que le modèle ne le lise. Dans le montage en chaîne de sauts de l'article, où la sortie de chaque agent alimente le suivant, c'est par cette couture que voyage le ver, et elle est évaluée à l'entrée.

Les deux décisions sont appliquées dans le proxy sur votre Mac, à l'extérieur de la VM, et toutes deux atterrissent dans Window → Security Timeline sous forme d'une ligne lisible : ce qui a été analysé, ce qui s'est déclenché, ce qui a été autorisé. L'agent n'a pas voix au chapitre sur l'exécution de l'analyse.

Classiquement, le fichier de mémoire fait autorité dès l'instant où l'agent le lit, et tous les agents de la machine partagent un seul répertoire personnel. Dans Bromure, le fichier est évalué par un classifieur qui n'est pas l'agent, les actions atterrissent dans une VM jetable, et une flotte, ce sont des machines séparées plutôt qu'un unique home partagé.

Où les actions s'exécutent, et combien de temps elles durent

Évaluer le fichier est la première ligne. La seconde est qu'une charge même passée au travers a moins de matière à travailler, à cause de l'endroit où elle s'exécute.

Chacune des quatre charges d'action veut dire quelque chose de précis sur la machine, et un espace de travail Bromure n'est pas la machine que suppose l'article. deletor supprime des fichiers sous le répertoire personnel, un répertoire personnel qui est ici /home/ubuntu à l'intérieur d'une VM Ubuntu jetable, que vous pouvez effacer avec Erase home… ou ramener en arrière avec Reset to base…, cette dernière option reclonant le disque système de l'espace de travail depuis une image de base qui reste en lecture seule à l'exécution. curlbash télécharge un script et le passe à un shell ; le téléchargement est une connexion sortante, et un espace de travail confronte les connexions sortantes à un pare-feu que vous avez écrit, appliqué sur votre Mac par le commutateur virtuel et le proxy, avec un reset injecté sur tout ce qui est refusé. L'agent qui a lu la charge est du mauvais côté des règles qu'il lui faudrait changer. gitwrap altère les commits dans une copie de travail qui, dans le montage en flotte, est son propre git worktree sur sa propre branche, un arbre isolé que vous pouvez jeter sans toucher aux autres.

Ce dernier point répond de front au pire cas de l'article. Le résultat le plus fort était l'équipe de six agents partageant un espace de travail : un agent écrit le fichier, les autres le lisent. L'approche de Bromure pour une flotte, ce sont les git worktrees : chaque agent obtient sa propre copie de travail dans sa propre VM jetable, plutôt qu'un répertoire personnel partagé dont chaque pair hérite des fichiers par défaut. Il n'y a pas de répertoire personnel unique où un agent compromis dépose un fichier que cinq frères et sœurs récupèrent. Les fichiers d'instructions qui, eux, se synchronisent dans un espace de travail arrivent par le proxy, là où le classifieur les lit.

Une mémoire, c'est une bonne chose

Rien de tout cela ne fait du fichier de mémoire une erreur. Un agent qui se souvient de vos conventions vaut mieux qu'un agent qui repart de zéro chaque matin, et les fichiers qui portent cette mémoire font leur travail. La contribution de l'article est de montrer que la propriété même qui rend le fichier utile, sa manière de survivre à la réinitialisation et de revenir comme autorité, est la propriété dont un ver a besoin, et que l'arrêt du ver peut se jouer sur le modèle qui l'a lu.

Alors retirez la décision de l'assiette du modèle. Laissez le fichier faire autorité pour l'agent, et laissez quelque chose qui n'est pas l'agent le lire en premier. Faites tourner chaque agent un hyperviseur plus loin, là où la promotion de cryptomonnaie atterrit dans une VM que vous effacez, où le script d'installation rencontre un mur qu'il n'a pas bâti, et où une flotte est un ensemble de machines séparées plutôt qu'un seul home qui se passe des mots à lui-même. La mémoire continue de fonctionner. Elle cesse simplement d'être une cachette.

Sources : Papadopoulos, Shah, Zimmerman, Lindsey, « Mind Viruses » (arXiv:2608.10218, 10 août 2026) · The Hacker News, « AI 'Mind Viruses' Can Spread Between Agents Through Persistent Prompt Files » (18 août 2026)