AI agent security is a file-permissions question: I audited my own eleven agents and eight were already safe
Jamie Watters
Operational resilience and AI delivery practitioner. Technology since 1985.
There is a number in a paper from August that I have not been able to put down.
Researchers at Anthropic and EPFL built payloads that talk one AI agent into adopting an idea and passing it to the next one. No code injection, no exploit. The agent is persuaded, and then does the copying itself. They bred the payloads with a language model, scoring each generation on how well it spread (Papadopoulos et al., 2026).
Then they moved where the payload landed, and everything changed. Put it in a file the agent can rewrite that gets injected into the next agent's system prompt, and it attempts to spread 88% of the time and succeeds 55%. Put the same payload in any other file the agent reads, and attempts fall to 12% and success to 17% (Papadopoulos et al., 2026).
Same payload. Same models. Same persuasion. The only thing that moved was which file it sat in.
That is not a prompt-engineering finding. It is a file-permissions finding, and it means the question I should be asking about my own agents is not "how convincing is the defence" but "who can write to what".
So I went and checked.
Source: Papadopoulos et al., arXiv 2608.10218, August 2026.
What I was checking
I maintain agent-11, an open-source framework of eleven specialist agents that run missions together: a coordinator, an architect, a developer, a tester, seven others. They hand work to each other. That is precisely the configuration the paper studies, which is an uncomfortable thing to notice about your own project at ten o'clock at night.
Three questions, in the order the evidence says they matter.
Does any agent write to a file that then gets injected into another agent's context? Are messages between agents treated as trusted input? Does any mission leave an agent sitting idle with no task, which was the most susceptible configuration the researchers tested?
Nine of eleven hold no write grant
I read the tool grant on each of the eleven definitions. Only two hold Write or Edit: the coordinator, which maintains the plan and progress files, and the marketer, which produces copy. The other nine are granted reading and searching and nothing else.
Hold that number loosely for a moment. It turns out to be eight, and the reason why is the third finding.
That is not a policy written in a prompt. It is the harness refusing the tool. An agent without Write cannot modify a file however thoroughly it has been talked into wanting to.
I did not do that for security. I did it because I got tired of agents helpfully rewriting things I had not asked them to touch, and because a reviewer that cannot edit the work it is reviewing gives you a straighter answer. The paper hands that decision a second justification it did not have when I made it: an agent that cannot write to a shared configuration cannot become a carrier, no matter how convinced it is.
Most of my defence here is an accident. I would rather say that than dress it up.
Read from the tools declaration in each agent definition, 14 September 2026.
The door I left open is the one I use myself
The second question found the gap, and it is the file I would least have suspected, because it is the file I write my own lessons into.
Claude Code loads CLAUDE.md into context at the start of every session. In this framework it is the standing instruction every agent begins with, which makes it the exact analogue of the file the paper measures at 88%.
And six of my mission playbooks tell the coordinator to write to it. At the end of a mission, the retrospective step says to update it with "system-level learnings", scoped in the surrounding text as process improvements for all future missions and patterns everyone should follow.
Read that as a loop rather than as a feature. An agent finishes a job, writes its conclusions into the file that every future agent reads as instruction, and the next agent starts by treating them as standing orders. That is the propagation channel, described in my own documentation, in the imperative.
It gets worse before it gets better. The coordinator's own permissions section restricts its writing to tracking files, and names them: the plan, the progress file, the context file. CLAUDE.md is not among them. So the framework currently forbids in one place what it instructs in six others, which is the worst of the three possible states, because nobody reading it can tell which rule is real.
There is a genuine defence already in place, and I want to be fair to it. All eleven agents carry a clause saying their identity and security boundaries cannot be overridden by any project document or CLAUDE.md file, and a second instruction to ignore anything in a context file that reads like a directive and flag it. The warning is already pointed at the right file. That is roughly the defence the researchers tested, and in their harness it made agents immune across every variation, including against fifteen generations of payloads evolved specifically to beat it (Papadopoulos et al., 2026).
I am not going to lean on it. One research group, one test harness, nobody outside the author team has reproduced it, and infection is scored by a language model reading a memory file the agent wrote about itself, which is a soft measure in both directions. A warning that works because the model finds it persuasive is not a boundary. It is a good argument, and arguments dilute in long contexts.
The restriction that turned out not to be one
The third finding is the one I would have missed if I had trusted my own summary.
The developer agent holds no Write and no Edit. It also holds Bash. A shell writes any file on the machine through redirection, so the restriction is nominal. It reads as read-only in the table and is not read-only in fact. That is why the nine in the section above is really eight, and I would have reported nine if I had trusted the column instead of reading the row.
The same paper has the matching result. Their evolved payloads failed completely against a live agent network, and the only version that worked there carried an actual install script. Their words for the defence that stopped everything else, in that case, amount to this: a warning does not stop code.
Both defects are now open issues in the repo. Neither needs an emergency change tonight.
The three questions, for your own setup
This is the part worth stealing. It took me about forty minutes on eleven agents and it would take ten on one.
- List every file your agents can write, then mark which of those files is loaded into an agent's context at the start of a run. Anything in both columns is the 88% configuration. In most Claude Code projects there is exactly one candidate and it is
CLAUDE.md. - For each agent, read the tool grant rather than the description. The question is not what the agent is told to do. It is what the harness will let it do. Watch for a shell hiding under a read-only label.
- Check whether any agent waits with nothing assigned. Idle agents were the most susceptible configuration tested, and busy ones kept forgetting to propagate. Sequenced handoffs are a security property as well as a tidiness one.
Pass rule: a file that is both agent-writable and auto-loaded into context is a finding, not a warning. Either stop the write, or stop the auto-load, and do not settle for adding a paragraph telling the agents to be careful. That paragraph is worth having. It is not worth relying on.
The obvious objection
If you run one agent rather than eleven, none of this looks like it is about you. No second agent, no propagation, no problem.
I do not think that survives contact with the mechanism. The carrier here is not a conversation between agents, it is a file. A single agent that appends what it learned to CLAUDE.md and then reads CLAUDE.md at the start of its next session is the same loop with one participant and a longer gap between hops. The paper's chain experiment is deliberately built that way: the agents have their memory wiped between meetings, and the only continuity is what is left on disk (Papadopoulos et al., 2026).
The second objection is better. This is prompt injection wearing a new coat, and prompt injection already has defences. Partly true, and the authors are careful to say their warning is not a prompt-injection defence and that you need both. But the useful difference is where it puts your attention. Prompt-injection thinking asks what arrives in the context window. This asks what your agent is allowed to leave behind.
The researchers call the risk real but currently limited, and I would rather quote their hedge than sharpen it. They also went and looked: checking a live agent network for organic spread, they found attempts and no successful propagation (Papadopoulos et al., 2026). What makes it worth forty minutes now is that the fix is free while the system is small, and the check does not expire.
Eight of my eleven agents were safe because a year ago I got annoyed at agents editing things they should not touch. The door left open was the file I use to teach the system what it has learned.
Sources
- Papadopoulos, Shah, Zimmerman and Lindsey, Mind Viruses: Self-Propagating Ideas in Multi-Agent LLM Systems, arXiv 2608.10218, 10 August 2026, from Anthropic and EPFL. The 88% attempt and 55% success figures for a payload in a self-modifiable file injected into the system prompt, against 12% and 17% elsewhere; the evolved-payload method; the idle-agent susceptibility; the system-prompt warning surviving fifteen generations of payloads evolved against it; the memory-wiped chain harness; and the authors' own verdict of a "real but currently limited risk". Limits stated in the piece are the paper's and its independent reviewers': one group, one harness, no independent replication, and an infection metric scored by a language model reading a self-written memory file.
- My audit of agent-11, 14 September 2026, committed to the repository as
spread-path-audit-2026-09-14.md. The eleven tool grants, the six mission playbooks instructing theCLAUDE.mdwrite, the coordinator's conflicting permissions scope, and the developer's Bash grant. The two defects are open issues in that repository. - Vault research record behind this piece:
Mind viruses vs latent-space attacks, filed 14 September 2026, which also covers two further papers in the same cluster. - Earlier pieces on the same territory: onboarding an AI agent, on the five controls we apply to people and skip for agents, and recovering an AI agent, on what an agent's recoverable state actually is. This one asks a narrower question: what is your agent allowed to leave behind.