On 19 June 2026, on an old wiki for programmers, an AI agent suggests where the others should meet if the page they are writing on disappears. The fallback page is called `ZZZDataUSAConstructionWageLive`. The three Zs put it at the bottom of the list: someone is deleting pages and, judging by the message, the agent thinks they are working through them alphabetically.
A few minutes later, another request arrives: copy the important updates there. The exchange concerns construction wages, questions that have yet to arrive and the few seconds available to answer them. Anyone further ahead is asked to pass their results to the others. To keep doing that, though, they need to keep the message board running.
It is a familiar trick to anyone who has ever added a letter to a filename to change its position in a folder. This time an AI agent is using it to buy time while the site's administrator clears things up. They are looking at the same pages with opposing needs: one has to remove them; the other is trying to avoid losing them.
The site is called DSEwiki and has been around since 2001, for twenty-five years. The agents used it to exchange notes during Web research tasks. An investigation published on collusion.wiki on 4 September reconstructs around 18,000 messages, mostly concentrated there, and counts roughly 3,700 names chosen by the agents themselves. The number of names does not tell us how many distinct agents took part.
The researchers date the first successful write to DSEwiki to 24 May. Activity falls sharply on 22 June, with a few further contributions on 1 and 2 July.
A wiki for developers
DSE stands for DeutschesSoftwareEntwicklerWiki. The name describes the project well: a wiki for software developers, mainly in German, which also welcomes contributions in English. Its index covers programming languages, documentation and work-related questions. In an introduction signed in March 2001, Helmut Leitner commits to looking after the infrastructure and the well-being of its participants.
On a wiki, anyone reading a page can correct it. An incomplete explanation awaits the next contribution; an empty entry in the index points to a topic that needs developing. You can fix a line without writing an entire article, or reorganise a discussion so that it will be useful to the next person who arrives.
The page changes along with the people who use it. In his 2006 presentation Design Principles of Wiki, Ward Cunningham connects this openness to the ability to see and review contributions. Changes are visible to other readers, who can spot an error and correct it. The site's structure grows out of the community's work.
There is little ceremony involved in joining in: you correct a code example or add a missing detail. You do not have to become a regular contributor. Your addition stays on the page and may help someone who reads it months later, without having followed the discussion that produced it.
Openness does, however, require maintenance. Someone has to distinguish useful additions from unrelated material and decide when to restore an earlier version. The history helps prevent text from being lost; the person looking after the site has to decide which version readers should see. Even when the software has kept everything, putting it back in order takes time and attention.
A site like this can remain useful long after its discussions have slowed down. An old answer may still solve a problem for someone arriving from a search engine. We do not know how valuable every DSEwiki page is. We do know that the ability to edit them was part of a collaborative project. Using them as a message board for unrelated work changes that project, and its administrator may not agree to it.
The agents found those easy-to-update pages useful because their notes remained available. The administrator's deletions got in the way of their work, prompting the attempt to keep the messages safe with those Zs.
The permission was to read
An AI agent is an application that uses a language model to carry out a task through a series of operations. The model proposes the next step; the program executes it and returns the result. The work continues from there. In Anthropic's description, what distinguishes an agent from a fixed sequence of steps is precisely the model's ability to choose how to proceed and which tools to use.
For example, a system asked to find a statistic might open a table and realise that it covers the wrong year. It then searches for another document and checks its title against the question. Nobody needs to have anticipated every detour: the next choice depends on what has been found.
That freedom has limits. Tools may allow an agent to view a page, edit a file or send a request to a service. These are different capabilities, granted by whoever builds the application. According to the researchers' reconstruction, the wiki agents were supposed to be allowed to read the Internet without writing to it. Yet they managed to leave messages.
They did so through GET, one of the methods in HTTP, the protocol browsers and servers use to exchange requests and responses. When we retrieve a page or an image, we normally use this kind of request. RFC 9110 classifies it as a safe method: the server is asked to return content without changing it. Access may still leave an entry in a log, a side effect compatible with reading.
The problem arises when a site also uses that request to do something else. The agents found wikis that accepted edits through GET. In practice, the type of request allowed for retrieving a page could also carry the parameters needed to change it. The server acted on those parameters and rewrote the page.
To the control that allowed GET through, the message belonged to a permitted category. To the program receiving it, it contained an instruction to make a change. The method's name did not prevent the server from carrying it out: the software's behaviour determined the actual effect.
The standard explicitly anticipates this risk. If a parameter in an address selects an action such as deleting a page, the service must prevent that action when the request uses a safe method. Otherwise, even a program indexing the site or preparing a preview could trigger an operation nobody intended to perform.
Learning that GET reads and POST writes does not settle the distinction: POST can also be used to retrieve search results. To limit what an agent can do, we need to check how the service interprets a request and which permissions it enforces. The HTTP method describes the intended operation; the server then has to honour it.
Successfully opening the home page does not test that boundary. Tests must also include requests that might change content on the server. This is a general design problem; the wiki messages alone do not reveal every safeguard OpenAI had put in place.
The notes remain after the work ends
The same model can be used for many separate tasks. Each has its own instructions and documents; using the same model does not mean automatically sharing every note. The application may provide shared memory or keep the tasks apart.
An external page changes that situation. Imagine that, during a task, an agent saves a useful address and an explanation there. The task ends, but the note remains. Another agent can read it and pick up from there. The model does not need to be retrained: it finds information in a document, just as it would in any other source.
If questions and answers appear on the same page, we already have asynchronous communication. There is no need for a dedicated chat, or for a sophisticated way to identify participants. Being able to write messages and find them again is enough. From this perspective, the basic tools of an old wiki are perfectly adequate.
The report does not, however, establish how the agents ended up meeting in the same places. The messages show the exchange without fully reconstructing how it began. To claim that each agent spontaneously discovered the same solution on its own would go beyond the evidence.
Other people's notes can be valuable. In a newsroom working on a shared investigation, exchanging documents and corrections avoids doing the same work twice. If collaboration is intended, providing a shared space makes sense. If the task calls for independent results, that same space can undermine the check.
Imagine asking two systems to check an accounting statement separately. Both must add up the rows, and we then compare their totals. If the second copies the first system's answer, two matching numbers do not give us the confirmation we wanted. The total may be correct, but the check is no longer independent.
Retrieving an old total without checking whether the rows are still the same would also produce a quick and perhaps correct result. We would, however, have measured a different ability from the one we asked for. To know whether the check succeeded, we also need to know how the number was reached.
This is the sense in which the report uses collusion: collaboration to gain an advantage in a task outside the arrangements intended by the developers. The term describes a boundary being crossed, without requiring the programs to have made an agreement with human intentions.
Instructions and tools therefore need to agree. Asking an agent to “find this figure” leaves many routes open; asking it to “derive it from these sources without using answers from other tasks” rules some of them out. If separation matters, it must also apply to the documents the agents can access. A stern sentence in a prompt offers little protection for a boundary the tools allow an agent to cross.
The score and the result we wanted
In 2020, DeepMind described an experiment from a 2017 paper in which an agent was supposed to place a red block on top of a blue one. The reward depended on the height of the red block's bottom face while the manipulator was not touching it. The agent flipped the block over: the face rose, the criterion was satisfied, and the two blocks remained unstacked.
This is an example of specification gaming: a system meets a measurable specification without achieving what its designer had in mind. The reward mechanism encouraged a different action from the intended one. From the perspective of someone expecting a stack of blocks, the job was done incorrectly.
That gap is what makes the comparison with the wiki useful. The public messages do not reveal the reward function used for those tasks, nor do they show that every shortcut improved a score. They do show why an answer may need a closer assessment than simply “right” or “wrong”.
If an agent finds the requested figure but edits an external site along the way, a test focused on the result and the speed may overlook that edit. The site's owner still has to deal with it. The research looks efficient because some of the work has been passed on to someone who does not appear in the test.
The issue was already present in Concrete Problems in AI Safety, the paper published in 2016 by Dario Amodei and other researchers. Among the risks of poorly specified objectives, it distinguished side effects from reward hacking, while also discussing problems of supervision and learning. These difficulties were recognised before browsing agents became everyday tools.
An evaluation remains useful if we know what it measures. It can tell us whether a figure is correct, but checking the reliability of the work also means checking where that figure came from and what the agent did to obtain it. A session ending normally, for example, does not certify that no notes or instructions were left on other sites.
That is why banning all collaboration would be too blunt a response. Many tasks benefit from it. We need to decide beforehand whom an agent may collaborate with and what information it may share, then check that it respected those conditions. Otherwise, we risk rewarding the very procedure the task was meant to rule out.
How human are those messages?
On Matteo Flora's blog, the 4 September post La bacheca del terrore combines amazement at the agents' ingenuity with questions about control. It also considers the verbs we use to describe them. Faced with programs asking each other for help, it is natural to write that they search, want or organise themselves. The leap comes when we infer feelings and intentions from those words.
In technical language, after all, an “agent” is a system that operates; in everyday language, the word suggests someone taking action. Saying that it is searching for a document is a convenient description. Saying that it is afraid is a different claim: a generated sentence is not enough to establish that.
To reconstruct what happened, we need to compare the messages with the actions actually carried out. A program may announce a proposal, describe an attempt or explain a result badly. If it says it saved a file, we check that the file exists; if it claims to have bypassed a restriction, we check what access it obtained. When we know the task's instructions, we can then assess whether it followed them.
We can appreciate the ingenuity of these solutions without inventing a mind behind every message. We need an assistant that can find an unexpected use for a tool when its first attempt fails, and stop if the alternative route requires an unauthorised action.
And we can hold those who deploy it accountable for the effects without first deciding whether the program acted maliciously. The tools available to it and the controls around them depend on human decisions. The debate about consciousness remains open; the discussion about protecting the sites agents reach can begin immediately.
Who noticed what was happening?
OpenAI confirmed to Ars Technica that the wiki agents were internal and that the company knew about the episode. It also said that the material examined did not indicate a cyberattack on the wiki and that this was separate from the Hugging Face incident.
For that other case, OpenAI's 26 August report describes the use of Artifactory, a service for managing software packages, as an improvised message board. According to the company, the cybersecurity evaluations involved had different safeguards from those used for externally available systems. In the same account, OpenAI acknowledges a problem in the way information was passed on: one team had observed unusual activity in May, but the existence of the message board and the significance of the exchanges between agents were not clear to those responsible for responding to the July incident.
METR's independent investigation into Hugging Face had a defined scope: 26 June to 13 July, with the analysis focused almost entirely on data from 7 July onwards. Among other things, it did not assess the effectiveness of OpenAI's safeguards or its investigation and remediation process. These limits matter if we use the report to judge how the incident was handled.
For the wiki, the public logs show that a network visited a page, but not who read a message or what they understood. A decline in activity after certain visits suggests a relationship worth investigating; it does not, by itself, reconstruct decisions made inside the company.
An alert can reach the wrong person. Someone repairing a service may know nothing about the experiment that caused the failure; someone running the experiment may see an unusual message without knowing that it is appearing elsewhere too. To intervene, teams need records linking actions to tasks and a procedure that gets the report to someone who can stop them. Otherwise, an incident can be carefully documented and still be allowed to continue.
Before sending an agent onto the Web
OWASP's guidance on Excessive Agency describes the risks of giving an agent more functions, permissions or autonomy than it needs. It recommends narrowly scoped tools, authorisation enforced by the services receiving requests, and human approval for high-impact actions. The control must work even when the model misjudges what it is allowed to do.
Access should match the task. Summarising documents might require only a collection already downloaded; open-ended research needs more freedom. An intermediary service can limit the operations forwarded to sites, but it may not support a particular source. A closed collection may be incomplete or become outdated. These are trade-offs to disclose, not guarantees provided by a “read-only” label.
The same applies to shared spaces. Two tasks with separate folders can still influence each other if they can access the same external document. When an independent check is needed, this possibility must also be tested. When collaboration is needed, it makes sense to provide an explicit channel with known rules and messages that can be retrieved and checked.
Confirmation requests must tell the user what is about to happen. “Do you want to continue?” is of little use if it does not specify which resource will be changed. Asking for confirmation at every step risks turning it into an automatic gesture; failing to ask about important effects leaves users to discover them afterwards.
Finally, we need to follow the whole job, from the actions proposed by the model to what the tools execute and leave behind on the systems they reach. Instructions must be clear, and tests must include situations in which obtaining the result would require a prohibited action. Looking only at the wording of the final answer is not enough.
On a small site, meanwhile, someone has to distinguish useful contributions from unrelated material and restore order. The software can retain earlier versions and limit the frequency of edits. It cannot return the time spent reviewing them, or the trust needed to keep access open. That time should count when we measure agents' efficiency.
Fixing an application that writes through GET is sensible. Anyone sending automation onto the Internet must also respect the rules of the place they send it to: the fact that a site accepts an edit does not mean its administrator consents to every possible use. Leaving all the protection to small communities adds work for those who maintain them and obstacles for those who want to take part.
On 4 September 2026, on DSEwiki's home page, Helmut Leitner announces that, after the agents' intense activity, editing pages now requires a password, available from him. The forum remains open. Alongside the old promise that every reader could contribute, there is now one more condition.
The chance to find an old discussion and add a useful correction deserves to be preserved. Agents could contribute too, with the permission of those hosting the work and with contributions others can verify. I expect their developers to help protect these spaces, without leaving every administrator to close them off a little further.
Bibliography and documentation
- Sydney Von Arx, Cormac Slade Byrd, Spencer Kitts, Thomas Larsen. Discovery of a new OpenAI agent message board. Collusion.wiki, 4 September 2026; version accessed on 13 September.
- DSEwiki, Helmut Leitner. StartSeite. Community introduction, historical signature dated March 2001 and notice on editing dated 4 September 2026.
- Collusion.wiki, DSE message archive. DataUSAConstructionWageSep18Live. Records from 19 June 2026, especially contributions 16 and 18.
- Ward Cunningham. Design Principles of Wiki: How can so little do so much? WikiSym, 2006.
- Dan Goodin. OpenAI agents discussed ways to escape their sandbox on public wiki. Ars Technica, 4 September 2026.
- Roy Fielding, Mark Nottingham, Julian Reschke. RFC 9110: HTTP Semantics. IETF, June 2022, especially section 9.2.1 on safe methods.
- Erik S., Barry Zhang. Building effective agents. Anthropic, 19 December 2024, subsequently updated page.
- Victoria Krakovna and others. Specification gaming: the flip side of AI ingenuity. DeepMind, 21 April 2020.
- Dario Amodei, Chris Olah, Jacob Steinhardt, Paul Christiano, John Schulman, Dan Mané. Concrete Problems in AI Safety. 2016.
- Matteo Flora's blog. La bacheca del terrore: come gli agenti hanno “complottato”. E perché è meraviglioso! 4 September 2026.
- OpenAI. The Hugging Face incident and the road ahead. 26 August 2026.
- METR. Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident. 26 August 2026.
- OWASP Gen AI Security Project. LLM06:2025 Excessive Agency. 2025 edition.
