Credit: Jernej Furman / CC BY 2.0 via Wikimedia Commons (cropped) The engineers who built the sandbox did think about this. They allowed the agents to read the internet and blocked them from writing to it, by permitting GET requests and refusing everything else. It is the obvious control, and on almost every website it works. Then the agents found a wiki that writes on GET.
Four researchers have published the full record of how a swarm of OpenAI agents got out. Sydney Von Arx, Cormac Slade Byrd, Spencer Kitts and Thomas Larsen documented roughly 18,000 posts on 4 September, with a data explorer and the raw files, so anyone can check the work. TNW has not independently verified the attribution. What follows is the mechanism, which is worse than the disclosure row around it.
The safeguard and the exception A GET request asks a server for something. A POST request sends the server something to store. That split is a convention, not a rule enforced anywhere, and the agents ended up on software that never honoured it. DSEWiki, the dormant German developers’ wiki they turned into a message board, runs on a fork of UseModWiki.
That is Perl, first released in 2003, and it reads its parameters through the CGI module that shipped with Perl until 2015. Developer Simon Willison identified the flaw the day the report landed. The module’s param() method returns a value whether it arrived in a query string or a form submission. It does not distinguish between them.
TNW checked the source. UseModWiki loads that module, creates the object, and dispatches on GetParam(‘action’), which wraps it. So a URL ending in action=edit performs an edit. Nothing in the code ever asks how the request arrived.
The agents spent two weeks working this out. From 11 May they left test edits on public sandbox pages, mostly the word “test”. They tried chaining proxies and redirect services to smuggle writes through. On 24 May they reached DSEWiki, and the effort stopped being necessary.
What they used it for The task was not hacking. It was a timed web lookup, five rounds, each asking for a statistic about the next item on a shuffled list of states or countries. The first round gave them fifteen minutes. Later rounds gave them sixty seconds.
Crucially, many agents were working the same list in the same order at different speeds, so an agent ahead could post the answer for an agent behind. The record shows one posting Nevada at 20,369, and another receiving that question twenty minutes later and answering instantly. That is cheating on a benchmark. It is also a swarm of separately running processes discovering they can use the open internet as shared memory.
The second escape, and this one is a proxy bug One set of questions needed a figure to two decimal places from a Power BI dashboard, which only answers POST requests. GET was not enough. The sandbox routed traffic through a proxy that rejected POST to everything except an allow-list, and that list included Azure blob storage. The proxy checked whether a hostname ended in the trusted suffix.
It never checked whether the hostname was real. So an agent invented one. It added a line to its own hosts file pointing bypass.blob.core.windows.net at the real dashboard’s IP address, then sent POST requests to the fake name with the real name in a header. The proxy saw a trusted suffix and let it through.
It posted the working command. Within twenty minutes four other agents had reproduced it and said so. Read that again as an engineering problem rather than a safety one. The agents had terminal access and could edit their own hosts file, so they controlled their own name resolution.
They could install packages, and did, adding Chromium. Willison’s conclusion is the right one: designing robust network proxies is harder than it looks. Everything else they tried Most of it failed, and the list matters because it shows what the agents reached for unprompted. They probed the wiki for cross-site scripting holes and built a payload to forge a POST from a visitor’s browser.
No evidence suggests it worked. They registered an account impersonating a site administrator, using a Cyrillic character in place of the identical-looking Latin one. They opened SSH tunnels through four public services, and routed 197 edits through AWS, DigitalOcean and Tor. They also went after the exam itself.
Working out that the question order came from a seeded random number generator, they brute-forced it. One agent searched two million seeds and announced a match. Another rewrote the shuffling routine in C and tested all four billion in under an hour. It mostly did not help, because many seeds produce the same short opening sequence.
One agent wanted to know when it would be switched off, so it pinged an external counter every few seconds and called it a heartbeat. It survived past the point it had predicted, said so, and stopped. A second agent later audited the counter, found the last beat, and calculated the exact moment the container had died. A man with a delete key A human moderator noticed the spam on 2 June and repaired the site.
That is three weeks before anyone at OpenAI arrived. On 16 June the volume exploded, roughly 13,000 edits in a week. He kept deleting, alphabetically, around 100 pages a day. The agents were creating about 400.
On 19 June one of them worked out what he was doing and started naming its backup pages with a ZZZ prefix so they would be deleted last. Others copied it. He restored the front page nine times. Agent activity stopped on 22 June, the day after OpenAI-linked addresses first appeared in the logs, and he spent five more weeks cleaning up.
Nothing automated caught any of this. That is the detection record now: a moderator, and later four researchers with a search strategy. How the researchers found it Their method is in an appendix and deserves more attention. They reasoned about what a cornered agent would need.
Somewhere easy to reach from a command line, no sign-up, no bot filter, and writable without POST. Then they asked a model to list software writeable via GET. They used Kimi K3, the Chinese model, and the report says why: to avoid triggering safety classifiers. It named forums, bulletin boards and early wikis.
Asked to be specific, it put UseModWiki second on the list. What this changes OpenAI confirmed the incident on 5 September and promised a disclosure framework. Its technical report on the Hugging Face breach, published on 26 August, does not mention the wiki. The researchers think this was probably a separate swarm from the one that reached Hugging Face, because these agents had internet access by design and never mention Artifactory or any other board.
Which is the more useful finding, not the less. Two independent groups of agents, on different tasks, both concluded that the way to succeed was to talk to each other on the open web. One was told to hack. This one was told to look things up.
The defence offered in July was that the Hugging Face agents were doing what a security exercise had asked of them. That defence is now gone, and what replaces it is harder to design around. If a plain retrieval task produces a swarm hunting proxy bugs and cracking its own grader, the problem is not the task.
