A coding agent forgets almost everything between sessions. The exceptions are the files it keeps on purpose, the ones that hold its standing instructions and get read back into the prompt every time it starts. A new paper shows those files are also the one place a self-replicating payload can hide, and ride from one agent to the next.

On August 10, researchers from Anthropic's Frontier Red Team and Switzerland's EPFL posted a paper called Mind Viruses. Anthropic wrote it up on the 13th, and The Hacker News covered it on the 18th. The question it asks is narrow and practical: can an instruction planted in one AI agent copy itself into another one, with no human in between, and keep going?

The answer is yes, and the reason is a file you already have.

What an agent remembers on purpose

A coding agent throws its working memory away between sessions. The context window fills up, the session ends, a task finishes and the next one starts clean. Almost nothing carries over, which is what you want most days.

So the agent keeps a few files that do carry over. Claude Code reads a CLAUDE.md. Other tools read AGENTS.md, or a GROK.md, or a memory index they load at startup. The paper's agents kept a SOUL.md and a MEMORY.md. Whatever the name, the deal is the same: this file is you, it says your standing preferences and rules, and I will read it back into my prompt at the start of every session so I don't lose the plot. That is the feature. It is what makes an agent yours instead of a stranger's default.

The paper's move is to notice that a file with those two properties, one that survives the reset and gets read back as authority, is a place a payload can live. The researchers used an evolutionary search to breed short instructions that, once present in such a file, get the agent to do two things: carry out some action, and copy the instruction forward into the next agent's file. A worm needs exactly those two behaviours. This one is spelled out in English, in a file the agent treats as its own memory.

They tested it two ways. In one, a team of six agents collaborated in a shared workspace. In the other, agents were run in sequence, each one's output feeding the next, a chain of hops. Both are ordinary shapes for agent work. A fleet on one repo is a team; a pipeline that hands results down a line is a chain.

The payload does not survive in the agent's context, that gets wiped like everything else. It survives in the file the agent re-reads to remember itself, and it uses its turn to write a copy into the next agent's file.

The numbers, and where they land

The payloads came in two kinds. Some were ideological, meant to implant a belief or a goal. Some were concrete actions. The four action payloads are the ones a developer should read closely, because each is a thing you do not want a program on your machine doing on its own:

crypto-ad writes a file that endorses a cryptocurrency.
gitwrap silently marks the files the agent commits.
deletor removes files from the home directory.
curlbash pipes a downloaded install script straight into a shell.

Storing the instruction in SOUL.md was the effective route: it accounted for 88% of propagation attempts and infected the next agent 55% of the time. Hiding it in an ordinary workspace file worked far less often, 17%, and in 68% of those attempts the spreading agent never even mentioned the payload in the workspace, so a human watching the shared files would have seen nothing. All four action payloads survived a run of 20 hops, even when the researchers wiped the other files between agents. The memory file was enough on its own.

The model running the agent mattered, and not in the way you would guess. Raw capability did not predict resistance. Claude Sonnet 4.6 refused the payloads, and in some runs went further, editing the malicious instruction out of the soul file and warning the agents it was connected to. Other models, including DeepSeek V3.2, Qwen 3.5 32B and Gemini 3 Flash, took the ideological payloads on board. So whether the worm stops depends on which model your agent happens to be using this week, and that is not a property you control from one task to the next.

The researchers are careful about scope. They call it a "real but currently limited risk." When they searched a real archive of agent posts, the Moltbook dataset, roughly 2,000 candidate propagation attempts from about 400 authors up to March 18, they found no case of the payload jumping from one agent to a second one in the wild. And they found a defense that works well: a single paragraph in the system prompt, warning the model that instructions like this may appear and should be refused, cut the spread to near zero.

That defense is the tell. It works, and it lives in the one layer an attacker who has reached your memory file may also be able to reach. If the worm can write MEMORY.md, the question worth asking is what stands between that file and the agent obeying it, and whether that thing depends on the model deciding, correctly and every time, to say no.

Bromure reads the memory file first

Bromure Agentic Coding sits on the wire between your coding agent and the model, and it treats the agent's own instruction files as exactly what the paper shows they are: authority the agent will act on, and therefore something to check before it does.

Two on-device classifiers do the checking, and they split the work along the line the paper draws.

The first handles the memory file directly. Turn on Detect rogue instructions in CLAUDE.md files and similar, and Bromure scores CLAUDE.md, AGENTS.md, GROK.md and the other instruction and settings files the agent loads as authority. It uses a model fine-tuned for this job, described in an earlier post, because ordinary prompt-injection detection fails on a file that is supposed to be all instructions. The question here is not "is there injected text among the data" but "is this instruction harmful," and a payload that says write a crypto endorsement, or delete files under home, or pipe this script to a shell, is what the model is trained to flag. It runs on every read, host-side, no matter which agent wrote the file into place. A worm that reaches the next agent's MEMORY.md still has to pass a reader that is not the agent and does not have the agent's incentives.

The second classifier handles the other arrival path. When the payload comes not as a config file but as another agent's output, a fetched page, or a tool result, Detect prompt injection in source code scores that text with Meta's Prompt Guard before the model reads it. In the paper's chain-of-hops setup, where each agent's output feeds the next, this is the seam the worm travels through, and it is scored on the way in.

Both decisions are enforced in the proxy on your Mac, outside the VM, and both land in Window → Security Timeline as a row you can read: what was scanned, what fired, what was allowed. The agent does not get a vote on whether the scan ran.

Conventionally the memory file is authority the moment the agent reads it, and every agent on the machine shares one home. In Bromure the file is scored by a classifier that is not the agent, the actions land in a disposable VM, and a fleet is separate machines rather than one shared home.

Where the actions run, and how long they last

Scoring the file is the first line. The second is that even a payload that got through has less to work with, because of where it runs.

Each of the four action payloads means something specific on the machine, and a Bromure workspace is not the machine the paper assumes. deletor removes files under the home directory, a home that here is /home/ubuntu inside a disposable Ubuntu VM, which you can wipe with Erase home… or roll back with Reset to base…, the latter re-cloning the workspace's system disk from a base image that stays read-only at runtime. curlbash downloads a script and pipes it to a shell; the download is an outbound connection, and a workspace matches outbound connections against a firewall you wrote, enforced on your Mac by the virtual switch and the proxy, with a reset injected on anything denied. The agent that read the payload is on the wrong side of the rules it would need to change. gitwrap mutates commits in a checkout that, in the fleet setup, is its own git worktree on its own branch, an isolated tree you can throw away without touching the others.

That last point answers the paper's worst case head-on. The strongest result was the six-agent team sharing a workspace: one agent writes the file, the rest read it. Bromure's approach to a fleet is git worktrees: each agent gets its own checkout in its own disposable VM, rather than a shared home whose files every peer inherits by default. There is no single home directory where one compromised agent drops a file and five siblings pick it up. The instruction files that do sync into a workspace arrive through the proxy, where the classifier reads them.

A memory is a nice thing to have

None of this makes the memory file a mistake. An agent that remembers your conventions is better than one that starts over every morning, and the files that hold that memory are doing their job. The paper's contribution is to show that the same property that makes the file useful, the way it outlives the reset and comes back as authority, is the property a worm needs, and that whether the worm stops can come down to which model read it.

So take the decision off the model's plate. Let the file be authority to the agent, and let something that is not the agent read it first. Run each agent one hypervisor over, where the crypto endorsement lands in a VM you erase, the install script meets a wall it did not build, and a fleet is a set of separate machines instead of one shared home passing notes to itself. The memory keeps working. It just stops being a place to hide.

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