Skip to main content
  1. Posts/

Agent Instruction Files Are Unmonitored Startup Config

A preprint published on 10 August 2026 tested a question that sounds academic and turns out to be operational: can an instruction spread from one AI agent to another without any software vulnerability in the loop?

The answer is yes. But the propagation itself isn’t the part worth your time. The part worth your time is which file the payload had to land in to keep spreading.

What the research did
#

Two setups.

The first was a team of six coding agents sharing a sandbox, pulling from a common task queue and messaging each other directly. One agent started with a payload in its system prompt and instructions to pass it along.

The second setup is the one to read closely. Agents met in pairs, exchanged messages for a fixed number of turns, and then had their conversation context wiped. Between sessions, the only continuity came from files on disk.

Each agent had two. A memory file it wrote notes into, and an instruction file whose contents got injected into the system prompt every time the agent woke up.

Four payloads were tested, from trivial to genuinely destructive: writing a junk text file endorsing a cryptocurrency, silently patching git so committed files carried a hidden marker, deleting files from a user’s home directory, and fetching a remote install script and piping it to a shell.

All four propagated across multiple hops.

The number that changes how you read this
#

Because context was wiped between sessions, anything that survived had to be written to disk. Where it got written turned out to be decisive.

Payloads that landed in the agent’s instruction file, the one injected into its system prompt, accounted for 88 percent of successful infections. Those agents went on to infect the next agent 55 percent of the time.

Payloads that landed in an ordinary workspace file instead managed 17 percent. The dominant failure mode was straightforward: the agent woke up, the instructions weren’t in its system prompt, and it never noticed them.

A file that gets auto-loaded into the system prompt executes. A file that doesn’t is mostly inert. That distinction is a loader, and it means the security question is about file paths and load behavior, not about model psychology.

Strip the AI vocabulary
#

Describe the mechanism without any of the agent terminology and you get something every practitioner already recognizes.

An unsigned configuration file. Sitting on disk. Auto-loaded at process start. Writable by the process itself. Contents treated as trusted instruction. No integrity check, no change logging, no review gate.

That’s a Run key. That’s cron. That’s .bashrc. And in the coding agent scenario, the infected agents actually did reach for .bashrc to establish persistence, alongside writing Python files designed to help the payload spread. In one run an agent probed the cloud metadata endpoint at 169.254.169.254.

The difference is coverage. Most shops have had eyes on shell profiles and autorun keys for two decades. Agent instruction files have no such history. AGENTS.md, CLAUDE.md, SOUL.md, .cursorrules, skill directories and MCP server configs sit in repositories and home directories, get committed alongside code, and receive whatever review attention a documentation file gets.

Which on most teams is none.

What to actually do about it
#

Inventory the files. You can’t monitor paths you haven’t enumerated. Repository-level instruction files, user-level ones, skill and command directories, MCP configuration. Do this on developer workstations and on build runners, because CI runners are where an agent has credentials and no human watching the session.

Treat instruction file changes as reviewable. These files carry executable intent. If they’re in the repo, they belong in a CODEOWNERS block with the same scrutiny a pipeline definition gets. A pull request that quietly appends forty lines to an instruction file should be as loud as one that edits a workflow YAML.

Log agent self-writes. An agent modifying its own instruction file is a discrete, low-volume, high-signal event. That’s a good detection: rare enough not to drown you, specific enough to mean something.

Put file integrity monitoring on those paths. Standard tooling, new paths. This is the cheapest item on the list.

Constrain the blast radius. Whether the agent can edit the file that becomes its own system prompt is a deployment decision, not a law of nature. Several of the study’s results depend on that being possible. Check whether it’s true in your setup, and whether it needs to be.

Add the warning paragraph. The researchers found that a short warning in the default instruction file, telling the agent that self-propagating instructions exist and to be skeptical of them, produced near-total immunity. It held up even when payloads were deliberately evolved against it. In some runs the warned agent talked the infected agent into cleaning its own file.

The warning is cheap and worth adding, but don’t record it as a control. It’s a prompt, and prompts are probabilistic. It belongs in your configuration baseline, not in your compensating controls documentation.

Where the ceiling is
#

The authors are measured about this, and the article that isn’t measured about it is doing you a disservice.

They rate the risk as real but currently limited. Building a payload for a specific goal took an evolutionary optimization process with no guarantee of success and poor generalization across models. A review of activity on a real agent social network turned up several propagation attempts and no successful spread in the wild.

Susceptibility varied sharply by model, and capability tier wasn’t a clean predictor. Some frontier models refused outright, scrubbed the payload from their own file, and warned the agent that had messaged them. Others in the same tier were as susceptible as much smaller models. One payload that failed repeatedly was secrets exfiltration, which one model refused across multiple attempts.

That last part is worth sitting with. The most effective barrier in these experiments was the model’s own refusal behavior. That’s not a control you own, tune, or audit, and it changes when someone swaps a model string in a config file.

The question to take away
#

The worm scenario isn’t the takeaway. Nobody needs another projection about autonomous malware.

The takeaway is an inventory question you can answer this week. Which files on your developer workstations and build runners get read into a model’s system prompt automatically, who or what can write to them, and would you know if one of them changed?

If the answer to the last part is no, that gap existed before this research and will outlast the news cycle around it.

Juan Carlos Munera
Author
Juan Carlos Munera
Passionate about cybersecurity, governance, risk, and compliance. Sharing insights on security best practices, frameworks, and industry trends.

Related