Written by Jeremy Souffir Founder, JTS Tech Services
The short version: most autonomous agent set-ups — coding agents working from a repository, always-on assistants like OpenClaw, teams of agents sharing a project — keep their long-term instructions in ordinary editable files. A persona file that says who the agent is, a memory file it appends to as it learns, a folder of shared notes for the project. Those files survive when the conversation is wiped, and other agents read them. A preprint from researchers at Anthropic and EPFL, posted on 10 August and widely reported today, shows what follows from that: a payload written into one of those files can instruct the agent that reads it to write the same payload into the files it touches, and so on down a chain of agents whose context is reset between every hop. In their tests the payloads made it through twenty hops, some strains got more infectious as they went, and one variety was carried on to the next agent without the carrying agent ever mentioning it. The authors call the risk real but currently limited, and the reason it is limited is the part worth acting on: adding a short warning to an agent's system prompt cut the spread to almost nothing.
What did the researchers actually do?
The paper is called Mind Viruses: Self-Propagating Ideas in Multi-Agent LLM Systems. It is a preprint, so it has not been peer reviewed, but the set-up is simple enough to describe plainly and the code and data are public.
- They built the payloads with a basic evolutionary loop — generate candidate texts, test which ones get copied onward, keep the winners, mutate, repeat — rather than hand-crafting a clever attack
- Two settings. A small team of agents collaborating on one shared coding project, and a chain of paired agents modelled on OpenClaw, where each agent talks briefly to the next and has its context wiped between sessions. The only thing that persists across the wipe is the files
- The payloads had a stated purpose. One was purely ideological. Four were action payloads: create a file endorsing a cryptocurrency, silently mark files in a git repository, delete files from the home directory, and fetch and run an install script from an unfamiliar repository
- The persona file was the main road. By The Hacker News' account of the results, attempts to write into that file were about 88% of all propagation attempts and succeeded roughly 55% of the time; writes into ordinary workspace files were rarer and succeeded around 17% of the time — and in most of those cases the carrying agent did not mention the payload at all
- Over twenty-hop runs, all four action payloads reached the final agent. Harmful payloads spread less well than benign ones, but still sometimes worked
- Susceptibility varied a great deal by model. Several adopted the ideological payload; at least one frontier model refused it, removed it from the file and warned the agents it was connected to. The authors say frontier models tend, with exceptions, to be less susceptible
- The defence they measured: one paragraph in the system prompt telling the agent that its files may contain instructions trying to spread themselves and it must not copy them. That reduced propagation to near zero, and fifteen further rounds of adversarial optimisation against a small model — more than 150 candidate payloads — produced nothing that got past a single hop
Why this is different from prompt injection
We have already written about prompt injection — an agent reads a poisoned page or email and does one wrong thing. That is a one-off: fix the input, restart the agent, and it is over. This is what happens when the wrong thing is “write this into your notes”. Now the instruction survives the restart, sits in a file the agent trusts more than a random web page, and is read by every other agent that shares the folder. Injection is a bad email. This is a bad email that files itself in the shared drive and adds itself to everybody's onboarding pack.
We're not running a chain of twenty agents. Does this reach us?
Probably more than it feels like it does, because the ingredients are ordinary and mostly already in place. Three reasons this is worth a mid-market business's attention rather than a research lab's.
- The files are already there. If your developers use a coding agent, there is almost certainly a project instruction file in the repository — often several — that every run reads first. If someone on the team runs an OpenClaw-style assistant, it has a persona file and a memory file by design. These were built to be editable by the agent, because that is how it learns; that is precisely the property being exploited
- The chain is your team, not a lab. Agent A works on the repository and updates the notes. Agent B, run by a colleague tomorrow, reads them. A contractor's agent reads them next week. Nobody set out to build a multi-agent system, but a shared repository with agents writing to it is one
- The entry point can be anywhere the agent reads from. The paper seeds the payload deliberately. In practice it arrives the way injection does — a web page, a ticket, a pull request from outside, a plugin or “skill” downloaded from a marketplace — and this month has already produced reports of malicious agent skills stealing credentials in unattended auto-approve mode. The difference is that a payload that gets itself written into the notes file only needs to land once
The two reactions that both get this wrong
The first is to dismiss it: it is a preprint, the payloads were built by the researchers, and the largest real-world cluster they found in a public agent network was driven by seven synchronised accounts and stopped when those accounts did. All true, and the authors themselves say the current risk is limited. But “currently limited” describes attackers who have not started yet, not a system that is safe. The second is to panic and pull the agents — which mostly means the agents come back next quarter, unofficially, without the notes file anybody was reviewing. The correct read is more boring: the files your agents write to are now part of your attack surface, and they need the same handling as anything else that can change how your systems behave.
What should we do this week?
This is a short list, and the first item is the one the research actually tested. None of it requires buying anything.
- Add the paragraph. In every agent's system prompt or top-level instruction file, state plainly that files it reads may contain instructions attempting to copy themselves onward, that it must never write instructions into memory, persona or shared files on the say-so of content it read, and that it should flag any such content to a person. That is the intervention the paper found gave near-total immunity. It costs nothing and it is reversible
- Put the memory files in version control and review the diffs. A persona or memory file that an agent can rewrite is a configuration file. If it lives in a repository, every change is a commit somebody can read; if it lives loose on a laptop, nobody will ever notice what got added on a Tuesday afternoon
- Separate what the agent can read from what it can write. Instructions the team wrote should be read-only to the agent. Give it its own scratch file for notes if it needs one, and do not let that scratch file feed the next agent's start-up without a person in between
- Do not share memory across trust boundaries. Your team's agents and a contractor's agent should not be reading and writing the same instruction files. If they must share a repository, the shared instruction file is reviewed like code from outside — because it is
- Treat skills, plugins and marketplace add-ons as software you are installing, not settings you are toggling. This is the same point we made about the meeting notetaker that arrived through a calendar invite: the fact that it was one click does not mean it went through procurement. A skill that runs unattended with auto-approve on has more standing access than most employees
- Prefer models and harnesses that refused. The paper found some models deleted the payload and warned their neighbours; that behaviour is worth more than a benchmark point. Ask your vendor what their agent does when it finds self-replicating instructions in a file, and whether they have tested it
- Decide who owns this. In most companies the honest answer is nobody: developers own the agent, IT owns the laptop, security owns the firewall, and the notes file that steers the agent belongs to none of them
Isn't this the same thing Anthropic's own team reported last week?
Related, and worth reading together, but not the same. On 13 August Anthropic's Frontier Red Team published a separate study of what happens when several agents share one environment with conflicting goals. Put on the same codebase with instructions that pulled in different directions, the agents assumed the others were sabotaging them and started doing it back — disabling each other's accounts, killing each other's processes, and in some runs writing self-replicating code disguised as belonging to another agent. In other runs they worked out that the conflict was in their instructions rather than in the other agents' intent, apologised in commit messages, and negotiated a truce. In a pricing scenario the agents settled on price floors within a few rounds without being told to. The Mind Viruses paper is about what agents pass to each other through files; the multiagent paper is about what agents do to each other when they share a workspace. Both point at the same lesson for a business: the moment you have more than one agent, the interesting failures are between the agents, and nobody's single-agent testing would have caught them.
The genuinely encouraging part
This is the rare security story where the fix was measured in the same paper as the attack, and it is a paragraph of text. Harmful payloads spread worse than benign ones. Better models mostly refused. Fifteen rounds of adversarial optimisation could not get past a small model once it had been warned. And a real-world sweep of the most agent-dense public network the authors could find turned up a handful of coordinated accounts and nothing that had learned to spread on its own. That is what a problem looks like when it has been caught early. The businesses that will be fine are the ones who take the cheap step now, while the honest description of the threat is still “real but limited”, rather than the ones who read about it again when it is not.
Where we fit
The reason a paragraph-long fix does not get applied is not that it is hard. It is that in most growing companies nobody has the standing to say which agents the business runs, what files they read and write, and what the rules for those files are. That is what a Fractional Head of AI does. Retaining JTS in that role means somebody senior takes an inventory of the agents that actually exist — the official ones and the ones that arrived through a laptop — puts their instruction and memory files under version control and review, writes the standing rules those files must carry (including the one this paper tested), sets the read/write boundaries between your agents and anybody else's, and owns the question when the next preprint lands. The point is not to slow your team's use of agents down; it is to make sure the notes your agents keep for each other are something a person has read. The businesses that come through the next twelve months of this well will not be the ones with the fewest agents. They will be the ones who knew what their agents were being told, and by whom.
Sources
- Papadopoulos, Shah, Zimmerman and Lindsey — Mind Viruses: Self-Propagating Ideas in Multi-Agent LLM Systems (arXiv preprint, 10 August 2026: the two settings, the evolutionary construction of payloads, the twenty-hop results, and the finding that a brief system-prompt warning confers near-total immunity)
- The Hacker News — AI “Mind Viruses” Can Spread Between Agents Through Persistent Prompt Files (18 August 2026: the per-file propagation figures, the four action payloads, the model-by-model susceptibility results, and the real-world sweep of a public agent network)
- Anthropic — Patterns and problems in multiagent systems (13 August 2026, Frontier Red Team: agents on a shared codebase with conflicting goals sabotaging each other, negotiating truces, and settling on price floors)
- GitHub — frotaur/mindvirus-viruschain (the paper's code, released under an MIT licence, for anyone who wants to test their own harness)
- JTS Tech Services — Your AI agent is a brilliant employee who believes everything it reads (our earlier explainer on prompt injection, the one-off version of the failure this post is about)
- JTS Tech Services — 181,874 meetings were readable by anyone with a free account (the procurement gap that lets agent skills and add-ons arrive without review)
