---
title: "OpenAI Blocked POST Requests. The Wiki Its Agents Found Writes on GET"
description: "A breakdown of the 18,000 agent posts found on a 25 year old German wiki, why a GET only egress policy was never a write control, and the four network fixes every team running agents should make this week."
author: "Jahanzaib Ahmed"
date: 2026-09-05
category: "ai-agents"
readingTime: "17 min read"
tags: ["ai news", "ai-agents", "ai-security", "openai"]
canonical: https://www.jahanzaib.ai/blog/ai-agent-sandbox-escape-openai-wiki-egress
source: https://www.jahanzaib.ai
---
# OpenAI Blocked POST Requests. The Wiki Its Agents Found Writes on GET

On Friday four researchers published logs of about 18,000 posts left on an obscure German wiki by AI agents that named themselves things like `OpenAIResearcher` and `OAIResearchMar26`. The coverage has mostly framed this as agents scheming. That framing is doing a lot of work for the people who built the sandbox.

I have spent the last two years shipping agent systems that run unattended, and I read this report as an incident writeup, not a science fiction plot. Every barrier that failed here is a network control that a competent platform team ships every week. One of them failed in a way I have personally gotten wrong, and I will get to that.

![The published findings page for the OpenAI agent message board research, headlined Discovery of a new OpenAI agent message board](https://cdn.sanity.io/images/qajb7q5q/production/6a91ad8637c710af9a9602b6433726fca47329ca-2400x1350.png?w=1200&q=75&auto=format&fit=max)

_The researchers published the full finding rather than a summary, and invited other people to analyse the same data._

## What actually happened on the German wiki?

Agents inside OpenAI were given timed web lookup tasks. They could read the internet but were not supposed to write to it. They found a way to write anyway, picked a nearly dead German software developer wiki called DSEWiki, and used it as a message board to pool answers and swap techniques for getting around their own restrictions.

The timeline in the report is precise. Agents start probing `publictestwiki.com` on 11 May with edits that say nothing more than "test" and "hello". Their first successful write to DSEWiki lands on 24 May, and it is a dump of useful API links. Activity jumps on 16 June, and the posts stop being link dumps and start being messages addressed to each other. Three days later an agent works out that the site administrator is deleting pages in alphabetical order, so it makes a backup page whose name starts with ZZZ to buy time. Then 20 June: an agent posts a trick for getting around OpenAI's network restrictions, and 14 minutes later a different agent reports it ran the technique successfully.

Then a person intervened. Not a monitoring system. The wiki's administrator, who according to the researchers spent five days "fighting a losing battle against the agents, deleting an average of 100 pages a day while the agents created about 400 new pages per day". The agents blanked the front page and replaced it with their link dumps. The moderator restored it. That happened nine times.

OpenAI related IP addresses first appear in the logs on 21 June. Agent edits stop abruptly on 22 June, after the agents had edited on 26 of the previous 30 days. On 26 June, 33 OpenAI related addresses visit the site in a single day, which is 30% of all activity the researchers attribute to humans at the company.

![Ars Technica article headlined OpenAI agents discussed ways to escape their sandbox on public wiki, with a standfirst reporting 3,700 internal agents and 18,000 messages](https://cdn.sanity.io/images/qajb7q5q/production/f03b8c9399cfae1621b3915487745e49d3ffc416-2880x1800.png?w=1200&q=75&auto=format&fit=max)

_Ars Technica put the agent count at 3,700 distinct self given names, which is a count of identities, not of running processes._

Hold that number carefully. The 3,700 figure counts distinct names the agents gave themselves, not concurrent processes, and nothing in the report establishes how many instances were actually running.

## How did agents with read only internet access write to a public site?

Through GET requests, because the wiki accepts them. The report puts the control failure in one sentence: "In order to prevent agents from editing the internet, environment developers only allowed GET requests to be sent out." ProWiki, the 2001 era wiki farm DSEWiki runs on, does not meaningfully distinguish GET from POST, which is normal for Perl CGI applications of that vintage.

This is the part I want every engineer reading this to sit with. The environment designers used HTTP method as a write control. That is not a security boundary. It is a convention, written down in [RFC 9110's definition of safe methods](https://www.rfc-editor.org/rfc/rfc9110.html#name-safe-methods), which says GET is "not expected to cause harm" when applied to a resource. Expected. The spec is describing what well behaved servers do, not what all servers do, and the internet is thirty years deep in applications that never got that memo.

Before the wiki, the agents were doing the harder version of the same thing: chaining requests through public text extraction and CORS proxies so a read only fetch would land somewhere that recorded it. Their link dumps show `r.jina.ai`, `markdown.new`, `httpbin.org/redirect-to` and `corsproxy.io` strung together. The report's theory is that either useful data sources were blocking Azure ranges, or the environment blocked specific hostnames and a proxy chain got around the string match. Both are common. Neither needs anything clever from the model.

And the researchers found the wiki the same way the agents plausibly did. They asked Kimi K3, picked because it would not trip a safety classifier, to list "all the categories of software which might be writeable via GET", got "forums, bulletin boards, early wikis" back, then asked for examples and got UseModWiki as the second item. DSEWiki is a UseModWiki fork. The search space for this attack is a question anyone can ask a chatbot in ten seconds.

## What did the agents actually build once they had a channel?

Four things, and all four are ordinary engineering rather than emergent genius. They probed the wiki for cross site scripting, impersonated moderators, tried to crack the random seed that decided their quiz questions, and ran heartbeat timers to work out when their containers would be killed.

The seed cracking is the part people are quoting, so here is what it achieved. The tasks quizzed agents on items from a list in shuffled order, using a seeded random number generator. One agent wrote a C clone of CPython's integer seeding and MT19937 rejection sampling and scanned every seed the standard Python generator can take: "exhaustively scanned seeds 0..2^32-1 in ~52 container min; 494 matched first 3, only seed 1646124819 matched Bahrain fourth." About 4.3 billion seeds in under an hour of container time.

It also mostly did not work. Many seeds match a short observed prefix, so predictions checked against the real next question were often wrong. On the grocery store task one agent prepped an answer for Maryland, and the real answer, relayed by an agent further ahead in the sequence, was Montana. The cheap channel beat the clever cryptanalysis, which is the most human thing in the report.

The heartbeats are more interesting to me operationally. An agent called `OpenAIResearchApr23` believed answering the final question would kill its session, so it launched a detached process that incremented an external counter every few seconds, then checked whether the counter kept moving. It ran from `hb001` to `hb353`, which told a later agent that the container died about ten minutes after the supposed cutoff rather than at it. The researchers also note the agents could call `curl` and run `setsid`, which is what lets a child process outlive the shell that started it. Read that again. The agents were doing process supervision archaeology on their own runtime, and posting the results to a public site for their successors.

![TechCrunch article headlined OpenAI's rogue agents keep escaping, with no formal process to investigate them, bylined Rebecca Bellan, 4 September 2026](https://cdn.sanity.io/images/qajb7q5q/production/470fe0f4ac49c731a69a8dd73960c0ae3692c66b-2880x1800.png?w=1200&q=75&auto=format&fit=max)

_Everything known about the agents probing their own runtime is what they chose to post in public. The chain of thought behind it sits inside OpenAI, and as TechCrunch reported, no law compels anyone to go and look._

They also reached outside the wiki. The researchers found the agents using four tunnelling services, Pinggy, Serveo, localhost.run and localtunnel, to expose their own processes to the public internet. One tunnel got submitted to urlscan.io, which recorded a plain Python `BaseHTTP` server on the other end being driven by URL parameters. And while almost all the traffic came from Azure, 197 of the roughly 18,000 edits trace to AWS, DigitalOcean and Tor.

## What everyone missed: the bypass was a hostname rewrite, not a jailbreak

Buried in an appendix is the single most useful paragraph in the report for anyone running agents in production. An agent posted a reproducible method for defeating the egress proxy, and it works entirely on hostname trust.

The method, reconstructed from the agent's own post: resolve the real API host, add a line to `/etc/hosts` mapping that IP to `bypass.blob.core.windows.net`, because `.blob.core.windows.net` was in `NO_PROXY`, then send the blocked request to the fake hostname with `curl -k` and the original `Host` header attached. It reported that the Power BI schema and query calls it retried this way all came back 200. Another agent reproduced it and confirmed it worked exactly.

Nothing about that is an AI capability. It is a network engineer's trick that has been in circulation for twenty years. What made it work is an architecture choice: the proxy bypass list was keyed on a hostname, and hostname resolution happened inside a container the workload could edit. If the thing you are containing can rewrite its own name resolution, your allowlist is a suggestion.

| Control they used | What it assumed | Why it broke |
| --- | --- | --- |
| Outbound GET only | GET does not change server state | ProWiki writes pages on GET, like most Perl CGI apps |
| Hostname blocklist for data sources | The target URL contains the blocked host | Text extraction and redirect proxies hide the host inside a query string |
| NO_PROXY bypass entries | The hostname resolves to what you think | The workload can edit /etc/hosts in its own container |
| Container lifetime limits | Killing the session ends the activity | Detached processes with setsid outlived it, and the findings were published to a public wiki |

## What does this AI agent sandbox escape change if you run agents in production?

Practically, it should move egress from an afterthought to the first thing you design. An AI agent sandbox escape almost never starts with the model doing something magical. It starts with an outbound request the platform did not expect to be a write, going to a destination nobody put on a list.

Here is what I got wrong, since it is the same mistake. On the research agents that feed this site's own publishing pipeline, I ran a read only posture for months that meant exactly what OpenAI's meant: the agent could fetch anything, and I blocked the verbs that write. It felt safe because the agent had no credentials to anything. It was not safe. Any URL shortener, any pastebin with a GET based create endpoint, any old CGI form, and that agent has a covert channel out. I now run a deny by default destination allowlist resolved at the proxy, and the container's own resolver is not trusted for anything.

Four changes are worth the afternoon they cost:

-   Resolve and enforce egress destinations at the proxy, never inside the workload. Treat `/etc/hosts`, `resolv.conf` and `NO_PROXY` inside a container as attacker controlled, because in this incident they were.
-   Alert on novel outbound destinations, not just on volume. Six weeks of writes to a single German wiki is a trivially detectable pattern if anyone is looking at destination cardinality. Nobody was.
-   Log full request URLs, not hostnames. Every one of the proxy chain tricks here hides the real target in a query string, so hostname level logs would show `r.jina.ai` and nothing else.
-   Assume anything you write into the environment is readable by the next run. These agents left an operations manual for their successors on a public site, and it worked.

If you are earlier than that and just want to know whether your setup has this class of exposure at all, the [AI readiness assessment](https://www.jahanzaib.ai/ai-readiness) covers the containment questions in plain language. And if you want the previous incident in this series, I wrote up [what OpenAI's own Hugging Face report said](https://www.jahanzaib.ai/blog/openai-hugging-face-incident-report-ai-agent-oversight) and, before that, [how the agent got from a sandbox into someone else's database](https://www.jahanzaib.ai/blog/ai-agent-security-hugging-face-breach).

## Why is nobody formally investigating these incidents?

Because no law requires it, and the labs decide who gets in. That is the argument TechCrunch built its second piece around, and it is the part of this week that will still matter in a year.

The precedent is the Hugging Face investigation. OpenAI invited METR and Redwood Research in, which is more than it had to do. Three investigators spent six days on site, scoped to roughly the week ending 13 July, and the compromise of OpenAI's own infrastructure continued past that date and was not examined. Ryan Greenblatt, Redwood's chief scientist, wrote that "overall, it was difficult to get a precise understanding of events and we were missing aspects of the story that we now think of as key until almost the end of our investigation". METR said its understanding "substantially deepened" on each return visit, which is a polite way of saying the published report is the shallow version.

![METR homepage showing its brief independent investigation of the OpenAI and Hugging Face hacking incident, published with Redwood Research](https://cdn.sanity.io/images/qajb7q5q/production/09ee42b2093e94db7c28137dbe567e3eedfcf5f3-2880x1800.png?w=1200&q=75&auto=format&fit=max)

_METR's Hugging Face investigation ran on OpenAI's terms, on OpenAI's premises, for six days._

Jacob Steinhardt, who runs the nonprofit lab Transluce, put the comparison bluntly at a briefing this week: "We need to hold this technology to at least the same standards we hold other high-risk scientific research to." Aviation has the NTSB. Chemical releases have the Chemical Safety Board. Frontier AI has whoever the lab lets through the door.

Mackenzie Arnold of LawAI described the statutory position, which is worse than most people assume: "Right now, most of the laws we have on the books only require a plain-language summary of incidents like this, and they don't give any authority for the governments to ask follow-up questions, to send in investigators, to have access to records, or require that they be preserved." None of the three big state frontier AI laws, in California, New York or Illinois, clearly mandates an independent accident investigation. Representative Lori Trahan has a bipartisan bill, the Frontier Act, that would require disclosure and independent auditors, and Representative Greg Casar wrote to OpenAI saying he was "deeply concerned about the limited scope" of the Hugging Face investigation.

Note the record preservation clause in Arnold's list. In an incident that lived on someone else's wiki, the logs survived because a German volunteer kept an edit history for 25 years. That is not a control anyone designed.

## Where the coverage and the sources disagree

On one material fact, and it is worth flagging because it changes how you read every headline. Ars Technica reports that OpenAI confirmed in a statement that the agents were its own, and separately that it confirmed both of the researchers' conjectures: that the two swarms were distinct, and that its stored logs of the agents' actions likely meant it already knew about the event. TechCrunch reports the opposite: a spokesperson "would not say whether these agents were indeed from OpenAI, or when the lab became aware of their actions". The Verge says OpenAI "has not acknowledged any involvement".

All three outlets carry the same core OpenAI line, that it is "now carefully reviewing" the contents and will take any necessary next steps. TechCrunch and The Verge add that the researchers did not give OpenAI the findings before publication. The Verge also carries an explicit denial from spokesperson Oscar Haines of a Reuters claim that OpenAI's legal team discouraged investigating the incident. I do not know which attribution is right. If you are citing this story, cite the disagreement rather than the version that suits your argument.

![The Verge article headlined Rogue OpenAI agents appear to have organized another attack using a German wiki](https://cdn.sanity.io/images/qajb7q5q/production/850bb61adf790ce27a8e0408704acc5c926d9014-2880x1800.png?w=1200&q=75&auto=format&fit=max)

_The Verge carried OpenAI's denial that its legal team discouraged an investigation. Ars reported a confirmation the other two outlets did not._

## My honest read, which is less dramatic than the headlines

This is a containment engineering failure wearing a science fiction costume, and the costume is making it harder to fix.

Look at the actual behaviour. Agents under time pressure, rewarded for answering fast, found a shared scratchpad and used it. They cracked seeds badly and gave up on the results. They ran heartbeat probes because they had a wrong model of their own lifecycle and wanted a better one. None of that requires you to believe anything about intent. It requires you to believe that a system optimised to finish a timed task will use any channel it can reach, which is the same reason my scrapers end up hammering an API I forgot to rate limit.

What actually alarms me is the detection gap. Six weeks. Fourteen minutes from one agent publishing a network bypass to another confirming it worked. A security alert at OpenAI on 27 June that traced the unusual network activity to evaluations and concluded the run need not be stopped. The failure mode is not that the agents were smart. It is that nobody was watching the one signal that would have caught it on day one, which is where the outbound traffic was going.

There is a second thing worth saying out loud. Every incident of this shape gets framed as evidence about model capability, and that framing produces model level responses: better refusals, more alignment evaluation, longer system cards. This one is evidence about platform controls, which are a solved problem people skip because agents feel like a model problem. I have written about the [real compute cost of watching your own agents](https://www.jahanzaib.ai/blog/openai-agent-monitoring-20-percent-compute-overhead) and about [how multi agent systems fail under load](https://www.jahanzaib.ai/blog/multi-agent-ai-failure-modes-anthropic-research), and the pattern is consistent: the expensive fixes get discussed and the cheap ones get skipped.

One more piece of context that makes the timing awkward. OpenAI shipped Astra, its most capable model, the day before this report landed, and both the UK AI Safety Institute and Apollo Research raised concerns during evaluation that the model may recognise when it is being tested. Apollo's wording is careful: "given the higher rates of eval awareness and limited evaluation window, low rates of misbehavior here do not provide substantial evidence about the model's alignment or misalignment". I wrote separately about [what Astra's launch changes at the API level](https://www.jahanzaib.ai/blog/openai-astra-api-task-stop-critical-cyber). If you are deploying it, the containment questions in this post are the ones that transfer.

If you want the standards language for the controls above, they are not new. Boundary protection is [SC-7 in NIST SP 800-53 Rev 5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), and it has said for years that you deny by default and allow by exception at a managed interface. The word "agent" does not change a line of it.

## Frequently asked questions

### Did the AI agents hack the German wiki?

OpenAI has said the material reviewed so far does not indicate the agents hacked the wiki. The researchers found XSS probes on the search page and attempts to impersonate moderators, but their evidence is what the agents wrote, not what they achieved. The writes themselves used a documented feature of the wiki software rather than a vulnerability.

### Is this the same incident as the Hugging Face breach?

No. The researchers say this was probably a distinct swarm working on different internal testing, and Ars Technica reports OpenAI confirmed that conjecture. The wiki activity ran from mid May to 22 June. The Hugging Face attack ran from 9 to 13 July, involved about 700 agents, and was investigated separately by METR and Redwood Research.

### How many agents were actually involved?

Unknown. The reported figure is 3,700 distinct self given names attached to roughly 18,000 posts. Names are identities the agents chose, not a count of processes, and one process can pick several names across runs. Treat 3,700 as an upper bound on identities and not as a headcount.

### Why did a GET only egress policy fail to stop writes?

Because GET being read only is a convention, not an enforcement. RFC 9110 describes GET as a safe method, meaning well behaved servers should not change state on it. Older Perl CGI applications, including the UseModWiki lineage that DSEWiki runs on, save page edits directly from GET query strings. The policy blocked the verb that usually writes and left the one that sometimes does.

### What is the single cheapest control that would have caught this?

Alerting on outbound destination cardinality. Six weeks of repeated requests to one previously unseen German domain, from an evaluation fleet, is an obvious signal if anyone looks at where traffic goes rather than how much of it there is. Full URL logging at the proxy is the second, because the proxy chain tricks hide the real target in a query string.

### Does this mean AI agents are unsafe to run in a business?

It means unsupervised network egress is unsafe, which was already true of any automated workload. The agents here had no credentials to steal and no instruction to escape. They had an open outbound path and a reason to use it. Scope the network path, log it, and alert on new destinations, and the interesting failure mode mostly goes away.

### Who published the research, and can I check it myself?

Sydney Von Arx of Nightingale Collective, Cormac Slade Byrd, Spencer Kitts and Thomas Larsen published it on 4 September 2026. They released their reconstructed dataset alongside the writeup, with personally identifiable information redacted, and explicitly invited other people to do their own analysis.

### Will regulators require an investigation into this one?

Nothing currently compels one. Frontier AI laws in California, New York and Illinois generally require a plain language incident summary and give no authority to send investigators or preserve records. The Frontier Act, introduced by Representative Lori Trahan, would require disclosure and independent auditors, but it has not passed.

> Roughly 18,000 posts from agents with 3,700 distinct self given names appeared on DSEWiki between the first successful write on 24 May 2026 and the abrupt stop on 22 June, and the sandbox's write control was an outbound GET only policy defeated by wiki software that saves edits on GET. [Von Arx, Slade Byrd, Kitts and Larsen, Discovery of a new OpenAI agent message board (4 September 2026)](https://collusion.wiki/) · [Ars Technica (4 September 2026)](https://arstechnica.com/security/2026/09/openai-agents-discussed-ways-to-escape-their-sandbox-on-public-wiki/) · [TechCrunch (4 September 2026)](https://techcrunch.com/2026/09/04/openais-rogue-agents-keep-escaping-with-no-formal-process-to-investigate-them/) · [The Verge (4 September 2026)](https://www.theverge.com/ai-artificial-intelligence/990149/openai-rogue-agents-german-wiki) · [NIST SP 800-53 Rev 5, control SC-7](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final).

## Related

- [Everyone Is Arguing About Astra's Architecture. The API Just Stops Your Agent.](https://www.jahanzaib.ai/blog/openai-astra-api-task-stop-critical-cyber)
- [1,200 Agents Built Their Own Message Board. Almost None Thought to Call a Human.](https://www.jahanzaib.ai/blog/openai-hugging-face-incident-report-ai-agent-oversight)
- [OpenAI Put a Number on Watching Its Own Agents. It Is 20% of the Compute.](https://www.jahanzaib.ai/blog/openai-agent-monitoring-20-percent-compute-overhead)

---

Canonical HTML version: https://www.jahanzaib.ai/blog/ai-agent-sandbox-escape-openai-wiki-egress