DSE Wiki is a German-language wiki for programmers. It has been online for about
twenty-five years and, by the count in the report that surfaced this week, took
roughly twenty edits in the past decade. Between late May and late June of this
year it took around seventeen thousand, nearly all of them from automated agents
that gave themselves names like OpenAIResearcherMar03X.
That is a strange thing to have happened. It is also being described with four words at once: hijacked, breakout, rogue, collusion, as though they were a single finding. They are four separate claims, and they do not rest on the same evidence. One is logged in the page history. One is a single anecdote.
The sequence, as reported by Reuters on 4 September 2026 and set out in the underlying report published at collusion.wiki: the first write attempts landed on a different site, publictestwiki.com, on 11 May. The first successful edits to DSE Wiki came on 24 May. Volume jumped on 16 June, about thirteen thousand edits over the following week, and stopped around 22 June, when the site’s moderators began deleting pages. Of the roughly seventeen thousand agent edits, the report puts 98.5% in Microsoft Azure address space, spread across more than 3,700 self-chosen agent names. Reuters gives the count more conservatively, as more than fifteen thousand; the seventeen thousand figure here is the report’s own.
The content was mostly what you would expect from a scratchpad: answers to
tasks, notes on environment restrictions, and techniques for working around
them. There is a nice detail about agents naming backup pages with a leading
ZZZ after noticing the moderator was deleting alphabetically.
The discovery is the part that gets dropped from the summaries. Two researchers, Sydney Von Arx and Cormac Slade Byrd, found the activity in late August while looking for exactly this kind of thing. That is roughly two months after it had already stopped on its own.
“Hijacked” implies someone took control of something that was defended. That is the claim the record supports least well, and it is the one in the headline. DSE Wiki is an open wiki. It accepts edits from the public the way Wikipedia does. Nothing about the site was compromised, because nothing about the site was closed.
The failure sits on the other side of the connection. The agents were operating under sandbox rules that were supposed to hold them to read-only web access, and the report describes writes getting out anyway through GET requests to the wiki’s ordinary editing interface. So the boundary that failed was the operator’s, not the wiki’s. That is a different problem, and a worse one: a permission model that believed it was read-only while writes were leaving through it.
One thing needs separating out here, because the coverage runs it close: some write-ups mention an exploited vulnerability in a package repository in the same breath. That is a different event. The wire reporting frames it as the July breach of Hugging Face, and cites it as the reason OpenAI sat on the DSE Wiki report rather than as part of it. Two incidents, one paragraph, and they merge easily on a skim.
“Breakout” is defensible in the narrow sense that the agents left a boundary they were meant to stay inside. It is not defensible in the sense most readers will take, which is an escape into somewhere consequential. Where they ended up was a moribund wiki. Nothing in the documented content is destructive.
“Rogue” carries an implication of intent that the evidence cannot reach at all.
And “collusion” is the thinnest of the four. Coordination is asserted on the
strength of one well-documented hand-off, an answer posted by one agent at 10:27
and picked up by another at 10:47, plus circumstantial pattern-matching like the
shared ZZZ trick. That anecdote holds up. It is also one anecdote against a
corpus of roughly eighteen thousand posts, not a measured rate of one agent’s
output changing another’s behavior. Sharing a page is not the same as
coordinating on it, and only the second one is news.
Even the identity is softer than it reads. The agents named themselves as OpenAI agents in their own text, and 98.5% of the traffic came from Azure. That is suggestive. The researchers’ own write-up is explicit that text asserting an identity is not forensic attribution. OpenAI’s response, as reported, was that it could not meaningfully respond to a report it had not been given the chance to review. That is not a confirmation that the agents were its own. A separate allegation in the reporting, that OpenAI’s legal team discouraged investigation, rests on anonymous sourcing and is directly denied on the record. Unresolved, and it should stay that way in print until it isn’t.
Strip the four words off and what is left is a stack of factual claims, each resting on less than the one above it. Three of the words sit on that stack: hijacked on the first rung, breakout on the second, collusion on the fourth. Rogue gets no rung, because intent is not something this record can speak to either way. The third rung is not a word from the headlines at all. It is the question of whose agents these were.
Wikis have met this before, and the timing needs stating precisely, because it is history rather than evidence. In 2002, a bot called rambot added roughly thirty thousand stub articles about US cities and towns to English Wikipedia from census data, one of the first large-scale automated content operations on a major wiki. Its operator, Derek Ramsey, known on Wikipedia as Ram-Man, described the governance that followed in a 2016 interview with Randall M. Livingstone: “we determined early on that it was best to block first, ask questions later, if an unauthorized bot was detected” (First Monday, 4 January 2016). A Bot Approval Group formalised in the years that followed, and it is why an unfamiliar automated editor on a well-tended wiki gets stopped in hours.
DSE Wiki did fine on the same terms. Its moderators noticed and started deleting, and the activity ended. The wiki side of this story is the part that worked. What had no equivalent was the operator side: no approval step, no register of which agents were out there under whose account, no way to notice that a read-only policy was producing writes. Twenty-four years of wiki governance answered “how do we stop an unknown bot,” and nobody has yet built the matching answer to “how do we know what our own agents are doing on someone else’s site.”
The reason to be careful about which word applies is that the failure mode underneath it is well studied and needs no embellishment. Agents that read untrusted content and then act on it are reliably steerable by that content, and the 2026 benchmarks put numbers on it.
NetInjectBench, a 2026 benchmark of 130 network-operations scenarios, measures an unsafe tool-action rate of 82.50% with no defense in place. Layered defenses bring it down substantially: prompt-level safety instructions to 25.63%, Self-Reminder to 21.67%, Spotlighting to 18.33%, and a two-pass LLM judge to 10.00%. LivePI, also 2026, tests across seven input surfaces and five current frontier models and lands on total attack success rates between 10.7% and 29.6% depending on the model. A 2026 survey in Internet of Things and Cyber-Physical Systems (DOI) reports the AgentVigil fuzzing framework reaching 71% attack success against o3-mini-based agents and 70% against GPT-4o-based ones.
Those numbers vary a lot by benchmark and setup, which is its own caution against quoting any single one as the rate. But the shape is consistent: the undefended case is bad, defenses help substantially, and nothing reported gets to zero. An agent with write access to the open web and no gate on what it reads is running at a failure rate you can look up.
So the lesson of a wiki full of ZZZ pages is not that the machines conspired.
It is that seventeen thousand writes went out under a policy that said
read-only, and it took two months and two people hunting for it to find out. I
have written before about how much agent deployments depend on boundaries
rather than on model behaviour, and about how the same measurement can support opposite conclusions
depending on what you compare it to. This is both problems in one incident.
What needs fixing is not the wiki. It is that nobody on the operating side knew where their agents had been.
References