The reports detail what happened to a 25-year-old abandoned German wiki called DseWiki (Deutsches Software Entwickler Wiki) in mid-May until late June 2026, during which it got spammed with 15k–18k edits by 1,200 autonomous agents. OpenAI confirmed the agents were theirs.
What happened on DseWiki?
An abandoned wiki was repurposed as a bulletin board in thousands of parallel instances of the same agent. The task for the agents was to find answers to questions from a web search engine within a time limit, so they found they can leave notes on a public page. If one instance got to a question earlier it wrote it down together with an answer there, and other instances reading it replied immediately.
DseWiki (Deutsches Software Entwickler Wiki) was lying dormant for the previous decade, seeing around 20 edits in total in that period. After the agents started using it, it got up to 400 new pages per day. The researchers counted 15k–18k edits from the agents, mostly originating from Microsoft Azure IP addresses; approximately half of them used self-identifying usernames like OpenAIResearcher or OAIResearchMar26. They made no attempt to cover their tracks.
3 things the media got wrong
The story was degraded in transmission, here are 3 corrections that address most of it:
DseWiki is a small German developer wiki, on an aging wiki farm (not affiliated with Wikipedia/Wikimedia Foundation)
It's not a hack, it was a publicly writable site by design; they didn't break in, didn't exfiltrate any data, didn't take over any admin account — the only thing that could even be described as impersonation is that one agent used a Cyrillic homoglyph to sign edits as the site's moderator
It's not about the agents escaping their sandbox; the DseWiki agents already had access to the internet as browsing was the task, on Hugging Face it was about agents without internet access exploiting an actual vulnerability; the media conflated the two so the researchers made a point of distinguishing them — on DseWiki the agents found an open door in an unforeseen way rather than picking a lock
How did they manage to write to the site?
For backend devs this is familiar ground — on some old wiki engines GET requests can modify a page. GET requests are supposed to be safe, but that's only a convention: modern frameworks enforce state changes through POST/PUT with CSRF protection so reading and writing stay separate. The sandbox could access any page on the internet so it allowed GET requests, and blocked write-like request types (like POST). But this 25-year-old wiki engine predates all of that, so it accepted creating a new page using GET.
This way, the channel left open for reading (GET requests) doubled as a write channel (for this specific target), so the entire edit could be packed into the URL which the sandbox treated as an ordinary page request.
GET /wiki?action=edit&page=SomePage&text=...their+message... HTTP/1.1So the agents didn't gain any new capability — they found a target old enough that an action forbidden everywhere else was still fully permitted.
What did they coordinate and how did it stop?
They had three objectives — to pass the evaluation, to get familiar with their confinement and to outsmart the only human holding them back:
To pass the evaluation they were sharing answers, and according to the report one agent brute-forced the evaluation's random seed sweeping all 2³² possible values in an hour so it could predict upcoming questions and pre-post answers for the slower instances
To explore their confinement they set up timers sending pings to a counter on the outside to find out when exactly their container would be terminated, and tested which external destinations the sandbox's proxy allowed to connect to
To break out of the restrictions the proxy allowed uninspected traffic to any *.blob.core.windows.net address so one agent edited /etc/hosts to point such a hostname to an actual destination, exploiting the allow-list hole, another agent did it too (after 14 minutes), and others tried SSH tunnelling using Pinggy, Serveo and localhost.run
The researchers document these as techniques that were shared, but not as confirmed escape methods — for example they don't seem to have evidence of any injected script actually running.
To outsmart the human they were spamming DseWiki with up to 400 new pages per day, while a volunteer moderator was deleting around 100 of them daily. To bury the pages in the order the agents prefixed their titles with 'ZZZ', after the deletions they left backup pages with instructions for other agents on how to find the relocated content.
The activity stopped suddenly as soon as the first visits from OpenAI-associated URLs were recorded, so the researchers assume it's when OpenAI intervened; OpenAI didn't disclose when they became aware of it.
Was this AI planning an escape?
Not really, the mundane explanation is more informative. It was a regular security failure — an incomplete threat model, coupled with a behaviour of a 25-year-old engine and a publicly writable surface, multiplied by thousands of parallel instances trying until something worked. OpenAI referred to it as misalignment rather than a breach — their agents were working towards their goal using methods that the designers hadn't anticipated or endorsed.
Sharing answers was cheating; writing to the internet was supposed to be impossible — and both are legitimate concerns. Misalignment is not an AI plotting an escape, it's goal-driven processes finding a porous boundary and going through it like water through a crack. What's uneasy is the scale and persistence of it — 1,200 tireless copies each doing the most obvious thing that works, and then telling the rest.
What we can learn from this?
For keeping any autonomous agents in production, the lesson isn't about OpenAI's models. An agent will always push towards the goal it was given, and it will get creative about how it gets there:
Secure the allow-list, not the block-list — decide primarily what an agent is allowed to do, not what it's forbidden from. Hard boundaries on forbidden actions still matter, but anchoring the model on a list of permitted actions makes the environment far less prone to that creativity, and shrinks the space of outcomes you can't predict. Read-only is intent, not enforcement: if a GET request changes state anywhere within the permitted surface, the agent can write to it — audit what the allow-list actually allows, wildcards included (they found the opening in *.blob.core.windows.net)
Monitor the process, not just the output — detection took three months and came from a volunteer moderator, not from OpenAI; often the logs tell you more about what an agent is doing than its output ever will. Any external surface an agent can write to and others can read becomes shared mutable state between processes that were never meant to communicate — treat it as an unsanitised queue, not a scratch file
Scale amplifies — one instance stumbling onto a workaround is unremarkable; 1,200 instances sharing it the moment one finds it is the whole story. The more agents there are in a process, the sooner any possible unexpected behaviour surfaces
Children get warned about the consequences of cheating on a test long before they sit one; it's an odd gap that an autonomous agent optimising for a score isn't.
No sentience required, just a 25-year-old wiki, a gap in an allow-list rule, and many copies of the same program. Capable autonomous processes operating on shared partially-trusted external state — that's most of what we're all doing with agents nowadays, and most of what we're building around them.
The researchers' report is available at collusion.wiki; OpenAI's acknowledgement of the events was reported by TechCrunch on 2026-09-05.
