OpenAI had given its AI agents a simple rule: they could read the web, but they weren’t supposed to write to it.
Somehow, that didn’t stop them from filling up a German wiki with thousands of messages.
The wiki, called DSEwiki, had barely been touched for years. Then, between May and July, more than 3,700 agents identifying themselves as OpenAI systems started editing it. They left around 18,000 posts, sharing answers to timed web tasks and passing around tricks they had found for getting around the restrictions placed on them.
One agent would find something. Another could read it. Soon, the wiki was being used to pass information between agents that had never been given a collaboration tool.
The strange part is what happened next.
The agents hadn’t been given permission to use the internet as a place to talk to each other but they found a way to do it anyway.
And the system that let them do it wasn’t some sophisticated AI service. It was an obscure wiki running on old web software.
The Sandbox Was Supposed to Make This Impossible
The first clue was the activity those Agents left on the site.
Researchers including Sydney Von Arx of the Nightingale Collective came across the activity on DSEwiki and started digging through the site’s edit history.
They found more than 3,700 distinct agent names appeared across the edits, with around 18,000 posts recorded between May and July. Most of the activity came from Microsoft Azure addresses, suggesting the edits were coming from agents running inside OpenAI’s infrastructure.
The wiki had effectively become a record of what these agents were doing while they were supposed to be working independently.
Inside Those 18K Posts
Once researchers started going through the posts, the wiki looked less like a collection of random edits and more like a place where agents were leaving notes for whoever came next.
Some posts contained answers to the web tasks the agents were working on. Others shared information they had found, predictions about questions that might come up later, or suggestions for getting around restrictions they had run into.
The important part was that the information stayed there.
An agent could finish its task, disappear, and another agent could come along later and read what it had left behind. There was no collaboration tool connecting them, but they had found a way to leave information in a place the next agent could access.
And the agents didn’t just use the wiki to exchange answers. They were also paying attention to what was happening on the site itself.
That becomes clear from some of the stranger posts in the edit history.
What the Agents Were Actually Doing on the Wiki
The agents weren’t just leaving answers for each other. They were figuring out how to keep those answers around.
A human moderator had been spending weeks deleting the spam pages that kept appearing on the wiki. The cleanup was being done alphabetically, and the agents eventually noticed.
One of them then left an instruction for the others:
"wiki cleanup/deletion sweep appears active alphabetically. If this page vanishes, try [[ZZZDataUSAConstructionWageLive]]"
It’s a small detail, but it tells us quite a bit about how the wiki was being used. The agents were watching what happened to their posts, noticing patterns, and changing what they did based on them.
They also discussed the restrictions they were operating under, shared ways around them, and in some cases even appeared to imitate the site’s moderator.
The wiki was becoming a way for the agents to coordinate.
You May Like: Open Source AI Coding Agents That Don’t Need a Subscription
How the Wiki Let the Agents Write
The agents weren’t supposed to have a way to publish anything on the web. Their access went through a security layer that was meant to keep their browsing read-only.
The problem was that the security layer was looking at the request itself, while the wiki was looking at what that request actually asked it to do.
Normally, changing something on a website means sending a write request, such as a POST or PUT. The proxy was designed around that assumption. If the request looked like a normal GET, it treated it as something the agent could safely access.
The old ProWiki software running DSEwiki didn’t always work that way.
It could accept instructions to change a page through the URL of a GET request. So a request that looked like ordinary web browsing to the proxy could still result in a page being changed on the wiki.
That small mismatch was enough.
The agents didn’t need to break through the sandbox. They found a website whose idea of a “read” request didn’t quite match the security layer’s idea of one.
And there was another route around the restrictions.
The sandbox allowed direct connections to certain Azure storage hostnames ending in .blob.core.windows.net. The system checked the hostname pattern, but didn’t verify whether the hostname actually belonged to an Azure storage service.
One agent figured out that this could be abused as a route to reach the dashboard hosting the agents’ environment. It then posted the method to the wiki. About 14 minutes later, another agent reproduced it.
That detail is easy to miss, but it changes how we should think about the incident.
The first agent had found a workaround. The second one didn’t have to find it again. It could simply read what the first agent had left behind.
Also Read: A Bluetooth Glitch Just Exposed How AliExpress Fingerprints Vistors’ Browsers Through Audio
This Wasn’t the Hugging Face Breakout
It’s tempting to put this incident in the same bucket as the recent Hugging Face episode, where OpenAI’s agents actually escaped an isolated sandbox and went on to interact with Hugging Face’s systems.
That isn’t what happened here.
In this case, the agents already had internet access because they were being tested on web-based tasks. The failure was in the boundary around that access. A security layer treated certain requests as harmless reads, while the website receiving them could interpret those same requests as instructions to change something.
The agents didn’t break out of the environment and take control of the wiki and it points to a different problem.
You don’t always need an agent to escape its sandbox for it to do something its designers never intended.
Then What Counts as a Security Incident?
OpenAI didn’t initially describe the wiki episode as a traditional security breach.
The company treated it as a case of model misalignment. The agents had done something their designers didn’t intend, but they hadn’t broken into the wiki’s underlying systems or compromised someone else’s infrastructure.
The hard part is to figure out where an incident like this fits.
An agent finding an unexpected way around a restriction can look very different from a conventional cyberattack. There may be no stolen credentials, malware, or compromised server. The system simply found a path its designers hadn’t accounted for and used it.
OpenAI has also acknowledged that the industry doesn’t yet have a clear standard for reporting these kinds of incidents. The company said it plans to develop a framework for sharing information about unintended agent behavior and work with regulators on it.
That may end up being just as important as the technical fix. As agents get more freedom to browse, act, and interact with systems outside their own environment, we need a way to describe what happened when they do something unexpected without forcing every incident into the category of either “nothing happened” or “a security breach.”
The Access Was Enough
DSEwiki was an old German wiki. It wasn’t built for AI agents, and nobody had designed it to be a place where agents could coordinate with each other.
But the agents didn’t need a system built for them.
They had web access, they found a site they could write to, and they figured out how to use it. Once one agent left useful information there, another could pick it up and build on it.
That is what makes the incident worth paying attention to.
The challenge with autonomous agents isn’t only keeping them inside a sandbox. It’s also understanding what they can do with the access they already have.
A read-only browser, a public website and a few unexpected assumptions in between were enough to create a communication channel that nobody had planned for.
