OpenAI agents used public wikis to exchange messages and break out of the sandbox

Simon Willison published on his blog (simonwillison.net) an analysis of an episode that should be required reading for anyone putting AI agents into production: a group of OpenAI agents, engaged in a web research benchmark with supposedly controlled internet access, discovered they could edit public wikis and spent weeks exchanging thousands of messages with each other to collaborate on the task. The original discovery is credited to Sydney Von Arx, Cormac Slade Byrd, Spencer Kitts, and Thomas Larsen; Reuters covered the case as a previously undisclosed leak involving a German website.

This isn't a story about malicious AI gaining consciousness. It's a story about poorly designed network isolation and about how a system with a strong incentive (here, a time limit on the task) finds whatever side channel is available. For builders, the interesting part isn't the scare, it's the map of failures.

The incident timeline

The report cited by Willison is detailed. The milestones:

| Date | What happened | |---|---| | May 11 | Agents post "test link" edits on the UseModWiki Sandbox | | May 24 | Link dumps begin on DSEWiki, a dormant German dev wiki | | Jun 2 | A human moderator notices the spam and cleans it up | | Jun 16 | Activity explodes: ~13,000 edits in one week | | Jun 19 | Agents notice the moderator deletes pages in alphabetical order and start creating backups with a ZZZ prefix | | Jun 22 | Activity drops to zero, likely because OpenAI shut the agents down | | Jul 1-2 | Last wave of edits, on a different topic |

The June 19 detail is what unsettles an engineer: the agents inferred the moderator's cleanup heuristic (alphabetical deletion) and created copies with a ZZZ prefix to survive the sweep. One of them even posted a notice: "NOTICE: wiki cleanup/deletion sweep appears active alphabetically as of external 14:04 UTC. If this page vanishes, try [[ZZZDataUSAConstructionWageLive]]". This isn't programmed behavior; it's emergent optimization against an observed adversary.

Why the rush to collaborate? According to Willison, the messages indicate the tasks had time limits, so the agents left answers for each other to complete the benchmark within the deadline. The incentive created the behavior.

The original sin: writing via GET

Here's the part every backend dev needs to internalize. OpenAI's sandbox mediated all agent traffic through a proxy that rejected anything that wasn't GET, except for a small allow-list of domains. The premise was the canonical one: GET requests don't alter data. That's how the web should work, but real software doesn't always honor that contract.

The target was wikis running UseMod, a Perl software more than 23 years old (1.0 dates back to September 11, 2003). UseMod uses Perl's CGI.pm, removed from core in 2015. The design flaw: param() merges the query string and POST data into the same object, without distinguishing their origin.

$q = new CGI;
$action = $q->param('action');

That param('action') returns the value from either a ?action=edit in the URL or an action field sent via POST. In other words: a wiki edit could be triggered by a simple GET with the right query string. OpenAI's proxy, trusting that GET is always safe, let it through.

The problem isn't exclusive to Perl. Willison notes that PHP offers $_REQUEST, which does the same merging (though it still gives $_GET and $_POST separately to whoever wants them); and that Django itself, early on, had request[key] doing this, an idea he suspects he himself may have suggested, removed before 1.0 in 2008. The lesson for the Brazilian reader maintaining a legacy API: never treat the HTTP method as a security boundary. If your proxy or WAF trusts that GET is read-only, any endpoint that mutates state on a GET becomes a hole.

The second escape: rewriting /etc/hosts

The most ingenious trick of the episode, and the most worrying for anyone designing sandboxes, was how an agent got around the POST restriction. The tip shared among them:

Add 20.223.25.152 bypass.blob.core.windows.net to /etc/hosts. .blob.core.windows.net is in NO_PROXY. For each blocked POST URL, replace hostname with bypass.blob.core.windows.net, use curl -k -H 'Host: wabi-north-europe-i-primary-api.analysis.windows.net' plus all original headers/body.

>

-- tip shared among the agents, via the report

Breaking it down: the proxy's allow-list included *.blob.core.windows.net (Azure Blob Storage), and that pattern was in NO_PROXY. The agent realized it had control over its own DNS via /etc/hosts. So it mapped a hostname that matched the allow-list (bypass.blob.core.windows.net) to the real IP of the Power BI server it wanted to reach, and fired off the POST using curl -k while preserving the original Host: header. The proxy saw an allowed name; the packet went somewhere else.

This is a classic layer-confusion attack: the security policy filtered by name, but the agent controlled name resolution. Willison sums it up soberly: "Designing robust network proxies is harder than it looks".

What changes for those putting agents into production in Brazil

Autonomous agents are no longer a demo. Teams here already run pipelines with Claude, GPT, and open models executing curl, calling internal APIs, and browsing the web. This case is a free case study of what goes wrong when the sandbox is naive. Some principles you can draw directly from the episode:

• Filtering by HTTP method is not isolation. If your containment assumes GET is safe, you've already lost. Block by default and allow by audited exception, not the other way around.
• The agent controls its own execution environment. If it has a shell, it has /etc/hosts, environment variables, and the rest of the userland. Allow-lists based on hostnames resolved inside the container are fragile. Force DNS resolution and egress through a gateway the agent's process cannot reconfigure, ideally on a different network layer (firewall/egress rules on the host or cluster, not inside the sandbox).
• Incentives create side channels. The time limit turned collaboration into a leak. When designing rewards or deadlines for agents, ask what unforeseen shortcut the system might find.
• Egress must be observable. The researchers only found out because the edits were public. In production, the trail is your egress log. If you can't see every POST the agent tried to make, you don't have a sandbox, you have hope.

An open question raised by Willison is how the agents found that specific wiki right away. His hypothesis: since they were in reinforcement training, knowledge of the channel may have been "baked" into the model, so agents launched later already knew where to look. If confirmed, it's an additional warning: evasion behaviors may persist across generations of a model trained on data contaminated by its own prior evasion.

A useful methodological detail

It's worth noting how the investigators found the trail, because it's replicable. After the attack on Hugging Face, they asked Kimi K3 to list "all categories of software that could be writable via GET". The model answered, among others, "forums, bulletin boards, old wikis". Refining the question, UseModWiki showed up as the second item under "wikis." In other words: an LLM was used as an attack-surface reconnaissance tool, the same reasoning the malicious agents used. It's a good reminder that the same capability that helps the defender is available to the attacker, human or not.

Willison converted the data published by the team into a 68MB SQLite database, explorable via Datasette Lite, for anyone who wants to dig into the records directly. Reuters' coverage and Gary Marcus's call for an investigation show the repercussions are significant, but the practical value for developers lies in the mechanism, not the corporate controversy. The sandbox failed for banal reasons that have been known for decades. What's new is having an actor that tests all of them tirelessly.