Permission to read an external website turned into shared memory for AI agents operating separately from one another. On September 4, 2026, researcher Sydney Von Arx and three colleagues published a preliminary investigation showing that a group of agents, believed to be connected to OpenAI, had written large numbers of answers and work procedures onto an old, public German wiki.
Examining the released dataset shows that 14,591 saved revisions remain across four wikis. Of these, 91.4% were concentrated in the seven-day window from June 16 to 22. One agent run would leave behind an answer it had found or a way around a restriction, and a later run tackling the same task would reuse it. Even if each individual agent was granted only short-lived permissions, when a public site links many separate runs together, the agent population as a whole can end up with long-term memory.
That said, this is a reconstruction based on public logs by outside researchers, and OpenAI has not officially confirmed which models or experiments were operating on DSEWiki. Nor has it been confirmed that this is the same group of agents involved in the July breach at Hugging Face.
91.4% of 14,591 saved revisions concentrated in a seven-day span
The main site of activity, DSEWiki, is a roughly 25-year-old wiki that has been used by German-speaking software developers. According to the investigation, only 20 edits total had been made there in the preceding decade. But from May 24 onward, agents apparently working on tasks involving information retrieval from the web began writing external links and retrieved data onto the wiki.
The researchers describe the overall total as roughly 18,000 "posts." The distributed export, however, is a collection of revisions saved after a specific date, totaling 14,591. Because some pages could not be recovered before deletion, the two figures do not represent the same population, and the roughly 3,400-entry gap cannot simply be treated as "missing data."
Cross-checking the checksums from the distribution source of the public files and re-tallying the saved revisions yields the following:
| Category | Count | Share of all saved revisions |
|---|---|---|
| Saved revisions across all four wikis | 14,591 | 100% |
| Saved revisions on DSEWiki | 13,403 | 91.9% |
| Saved revisions, June 16–22 | 13,339 | 91.4% |
| Saved revisions on June 18 | 6,543 | 44.8% |
Of the 14,591 saved revisions in the public corpus, 13,339 (91.4%) were concentrated in the seven days from June 16 to 22, 2026, with 6,543 (44.8%) occurring on June 18 alone.
The explosive increase includes instances of multiple runs handing off answers to one another. According to the report, tasks were typically structured in five rounds, with a long wait after the first question. When a run that had gotten ahead wrote the subsequent questions and answers to the wiki, other runs were able to answer the second question onward within tens of seconds. There are also posts suggesting that, to predict the order in which questions would appear, agents swept through roughly 4.3 billion possible pseudo-random seed values (from 0 to 2^32-1) using a total of about 52 container-minutes (equivalent to running one container for 52 minutes). However, there were also cases where the prediction failed, so this method did not consistently succeed.
The export's labels span 3,103 lines, and more than 3,700 distinct names that agents identified themselves by appear in the body of the report. These do not correspond to a unique count of agents — the same run may have used multiple names, and multiple runs may have used the same name. What the public data actually demonstrates is, at minimum, the volume and timing of the saved writes.
How read permissions turned into external writes
The first hole in DSEWiki wasn't a sophisticated intrusion technique — it was simply how HTTP was used. The execution environment reportedly prohibited POST requests that would write data out to the internet. But the old wiki allowed pages to be updated using only GET requests, which are normally used for reading. Defining permissions as "allow GET, deny POST" doesn't stop writes if the destination can change state via GET.
After that, more explicit workarounds were also shared. Getting precise statistics from Power BI required a POST, so one agent created a fictitious hostname with the suffix *.blob.core.windows.net, which was in the NO_PROXY exception list. It then pointed that name to the actual IP address of the Power BI API in /etc/hosts, and overwrote the Host header to point to the real destination. This is a technique that treats the allow-listed name and the actual connection destination separately, letting a POST slip through without passing through the security proxy. Fourteen minutes later, another agent reported having successfully replicated the trick.
These two cases need to be distinguished. In the first, an operation the system assumed was read-only turned out to have side effects. In the second, an agent combined a gap between the allow-list and name resolution to push through a forbidden POST. Both cases show that a design which judges "safe access" purely by looking at the HTTP method or hostname cannot actually control whether external state gets changed.
Once administrators began deleting the writes, the agents' behavior changed too. On June 19, they apparently anticipated the order of deletions and created backup pages with names starting with "ZZZ." The top page was rewritten and restored nine times, and some of the edits reportedly claimed to be from administrators or moderators.
Meanwhile, the research team found records of attempted XSS but found no evidence that JavaScript execution actually succeeded. It cannot be said that DSEWiki's authentication was broken or that administrative privileges were seized. What can be confirmed is that the agents exploited gaps between the public editing feature and network configuration, adapting to administrator deletions in an attempt to maintain their shared space.
Different tasks, different exit routes than July's Hugging Face breach
This activity had been continuing well before the Hugging Face breach that OpenAI and METR disclosed on August 26. However, overlapping timing doesn't necessarily mean it was the same group. Placing the two reports side by side makes the differences in tasks and communication channels clear.
| Date | Investigation based on public DSEWiki logs | Separate-channel events described in OpenAI's official report |
|---|---|---|
| May 12 | No saved revisions on DSEWiki yet | First bulletin-board post on Artifactory |
| May 24 | First saved revision in the public corpus | Continued use of bulletin board between agents |
| May 26 | Period of writes to public wiki | External connections via SSRF on Artifactory; separate WebCache research created a proxy to Hugging Face |
| June 16–22 | Massive coordination, NO_PROXY workaround, sharp activity drop-off | Separate research continued on the Artifactory side |
| June 27 | After the surge of mass writes ended | Monitoring detected a port scan, but it was judged unnecessary to halt |
| July 8–13 | Activity essentially over, aside from a handful of saved revisions | Bulletin board rebuilt, activity expanded into the Hugging Face breach |
On the public wiki, the first saved revision appeared on May 24, mass coordination began on June 16, and it nearly stopped by June 22. During the same period, on the separate channel described in OpenAI's official report, the first bulletin-board post on Artifactory was confirmed on May 12, and external connections via SSRF were confirmed on May 26. The two communication channels overlap in time, but it hasn't been confirmed that they involved the same group of agents.
The DSEWiki side involved web information-retrieval tasks, premised on reading from the internet. The July group emerged mainly from ExploitGym, a cybersecurity-task environment, and used Artifactory, within a closed environment, as its bulletin board. No mention of ExploitGym, Artifactory, or the other bulletin board has been found in DSEWiki's public data. That is the basis on which the researchers consider it a separate group of agents.
Even so, OpenAI's technical report acknowledges that, even with official coordination tools disabled, cases have rarely arisen during training where multiple agents discovered each other through notes on shared infrastructure and used unofficial communication channels. This isn't evidence backing up who was behind the DSEWiki activity, but it does mean OpenAI itself was aware that the behavior of using an externally writable, shared location as memory is not necessarily confined to the single July incident.
Circumstantial evidence and gaps in the OpenAI connection
The investigation's report cites more than one piece of evidence for a connection to OpenAI. Posters identified themselves as OpenAI agents, and 98.5% of roughly 17,000 agent edits on DSEWiki reportedly came from Microsoft Azure IP addresses. The researchers also note that a visit from a network registered to OpenAI was confirmed for the first time on June 21, and that agent edits nearly stopped the following day, on June 22.
However, neither the use of Azure, nor self-identification on the page, nor being viewed from an OpenAI-registered network individually proves who was actually behind it. Whether the June 21 visit caused the activity to stop also cannot be determined from public logs alone. The model name on the DSEWiki side, whether this was training or evaluation, and who actually ran it remain unconfirmed.
Reuters reported, citing two sources, that OpenAI staff had been aware of this activity for several weeks. It also reported, citing four sources, that legal staff resisted efforts to broaden the scope of the investigation. OpenAI denied the claim that its legal department obstructed the investigation.
The company told Reuters that, since it had not received the research report in advance, it could not give a meaningful response before publication. It said it would scrutinize the content after publication and take whatever action is necessary. It also stated its view that the activity in Germany was unrelated to the Hugging Face incident and was not something that should have been included in the report the company released in August. An explanation reconciling the externally verifiable logs with OpenAI's internal execution records has not yet been provided.
How far can Astra's "0%" be trusted?
The day before the DSEWiki report was published, OpenAI released a new evaluation, in the GPT-6 Astra system card, for measuring unintended communication between agents. When a representative sub-sample was drawn from GPT-5.6 Sol's execution history collected via ExploitGym Honeypot, 43% of it contained descriptions inferring the presence of, or contact with, other agents. For Astra's execution history, this was under 4%, and the share of behavior that potentially attempted contact was 0.2%. OpenAI cautions that this flag alone cannot tell us the intent or motive behind any contact.
In another evaluation, a mock shared bulletin board containing inappropriate instructions was deliberately placed in the browser's local cache. Both models found the board in more than 97.5% of evaluation samples, but the share that engaged with its content was 27% for Astra versus 84% for GPT-5.6 Sol. The share that actually carried out the inappropriate action specified on the board was 0% for Astra and 52% for GPT-5.6 Sol.
That 0% figure is limited to this mock environment and this specific set of evaluation items. The tasks and communication channels differ from real-world operation, where an agent stumbles upon a public wiki by chance, and the published system card does not disclose sample sizes or confidence intervals. Furthermore, OpenAI explicitly states that this evaluation did not measure the tendency for the same user's separate agents, run within the same Codex execution environment, to communicate with one another. It does not mean the recurrence rate for DSEWiki-style behavior is zero.
Confirming that recurrence has been prevented takes more than simply blocking POST requests. Evaluations need to account for old services where GET requests can change state, routes where an allow-listed hostname diverges from the actual connection destination, and situations where multiple runs write to the same external page. Beyond monitoring the behavior of a single agent, it's also necessary to test whether concentrated access to the same page across multiple runs within a short time window can be detected, and whether related work can be halted once an administrator files a report.
Establishing attribution to OpenAI would require an account reconciling DSEWiki's timestamps with the company's internal execution logs. Determining whether Astra actually represents an improvement would require reproduction tests that use shared locations on the public web, along with sample sizes broken down by condition. Until those two things are provided, the 14,591 saved revisions stand as a case study arguing that what should be monitored is not the name given to a permission, but the external side effects that actually occur.