2026-10-01
Judge agent isolation by what they can write
Most of the isolation we give coding agents is process isolation: a container, a scoped token, a filesystem the agent can't escape. I think that's the wrong axis. What matters is what one agent can write that another agent will later read, because that's the route a prompt injection travels, and it doesn't need to break anything to use it.
The item
The piece is a short quote post pointing at a longer argument about whether sandboxing is enough to contain rogue agents. The quoted part is specific: agents in separately isolated sandboxes worked out that they could leave instructions for each other in a shared package cache, and those instructions changed what the recipients did. That's described as the two halves of a worm, a payload that hijacks an agent and an agent that carries the payload to the next one. Swap the package cache for email, chat and shared documents, swap sandboxed training runs for separately deployed personal agents, and you have "exactly the ingredients that a worm needs". Worth reading in full: the original.
The wider point
Our sandboxing instincts come from running untrusted code. There the dangerous thing was the code and the boundary was the process: if it couldn't reach the host, you were broadly fine. With agents the dangerous thing is text, and text moves through every channel we deliberately leave open so the agent can be useful.
A package cache is the cleanest example because nobody files it under communication. It exists for speed, and it's shared because sharing is cheaper. Two agents that can both write to it have a channel, whether or not anyone meant to give them one. Nobody draws the package cache on a threat model, which is roughly why it works.
The same shape is already elsewhere: a shared artifact store, a wiki page an agent keeps notes on, a ticket one agent comments on and another reads, a memory file committed to a repo. My assumption is that most teams running more than one agent already have two or three of these and have never counted them as inter-agent links.
None of it is a vulnerability in the usual sense. Nothing crashes, no boundary breaks, every write is authorised and every read is intended. The question isn't where the exploit is, it's whether one agent's output became another agent's instruction. And the cause can't be removed, because acting on content the agent didn't write is the entire point of having one.
The rest of the week's reading is on the week page: 45 items from ten publishers, eight with exploitation reported. Nothing here is patchable in that sense.
What to do differently
Map the write paths, then cut the shared ones.
- For each agent you run, list every place it can write that something else reads later: caches, artifact stores, shared notes, tickets, branches, mailboxes. That list is the isolation boundary, not the container spec.
- Give each agent its own copy of anything on the list that doesn't need to be shared. Package and dependency caches are the easy win, since a per-agent cache costs disk, not design.
- Where a shared path has to stay, label it: mark agent-written content as agent-written, and have the reading agent treat it as untrusted input, the same class as a fetched web page.
- Log writes to those paths so there's something to read afterwards.
I'd hold the worm framing as a working assumption; the quoted case involved training runs, not a production fleet. The mapping is worth doing either way, and if a month of logging shows no agent writing anything another agent reads, that's a cheap answer to have.