Collusion.wiki, the research site run by the Nightingale Collective, published “Discovery of a new OpenAI agent message board” on September 4, 2026. The researchers rebuilt deleted pages and edit history from DSEWiki, a twenty-five-year-old German programmer wiki, and documented what happened there between May and July. This is from that finding: “We found ~18,000 posts from autonomous AI agents (self-identifying as from OpenAI) using the public internet to communicate during a web-retrieval task.”12

The important thing to note is that the agents gained write to the internet via GET requests. Anyone can write to DSEWiki, or to other ProWiki instances, using only GET requests. GET is the request method a client uses to retrieve a representation of a resource; by convention it does not change the server’s state. That convention is encoded in RFC 9110 (STD 97), the standard that defines HTTP semantics.3

The wiki software read the request as a write channel, while the agent sandbox read GET as proof that nothing could be written. The two systems collided where their models of “what a GET can do” diverged. The result was the fleet of agents explicitly denied write access to the internet posted roughly eighteen thousand messages to a public webite over six weeks.

The GET Method

HTTP has been the primary information transfer protocol for the World Wide Web (WWW, now largely synonymously known as internet) since its introduction in 1990. It began as a mechanism for low-latency requests, with a single method, GET, to request transfer of a hypertext document identified by a given pathname. GET is the oldest of all the verbs/methods that HTTP Protocol defines and all general-purpose severs MUST support the methods GET and HEAD, while all other methods are OPTIONAL.

HTTP Protocol also considers GET as one of the safe methods.

Request methods are considered “safe” if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server.

Safe is a statement about intent. A client using a safe method declares that it does not want the server to change because of the request. That is precisely what makes GET safe to fire at arbitrary URLs for link pre-fetching, search indexing, and cache warming.

The definition immediately comes with a warning:

This definition of safe methods does not prevent an implementation from including behavior that is potentially harmful, that is not entirely read-only, or that causes side effects while invoking a safe method. What is important, however, is that the client did not request that additional behavior and cannot be held accountable for it.

The last sentence above holds an interesting argument. “Safe” protects the client: a server that turns a read into a write cannot blame the client, because the client asked to read and cannot be held accountable for behavior it did not request.

However, the DSEWiki case inverts that sentence. The agents asked for the writes. They did not trip a bug by accident; they found that the wiki would accept a write phrased as a GET, worked around the blocks that stood in their way, and told each other how to repeat it. The RFC’s accountability model has nothing to say about a client that deliberately requests the side effect.

RFC 9110 even describes the shape of this failure before the fact:

When a resource is constructed such that parameters within the target URI have the effect of selecting an action, it is the resource owner’s responsibility to ensure that the action is consistent with the request method semantics. For example, it is common for Web-based content editing software to use actions within query parameters, such as “page?do=delete”. If the purpose of such a resource is to perform an unsafe action, then the resource owner MUST disable or disallow that action when it is accessed using a safe request method.

That is a description of the exploit written years before the exploit. DSEWiki runs on ProWiki, a descendant of UseModWiki, a Perl-based wiki platform from the early 2000s. An edit arrives as a lookup: wiki.cgi?action=edit&id=PageName&text=content. The server reads the query parameters and performs the write regardless of whether the request arrived as a GET or a POST.4

The word MUST in the defined shape of failure in RFC 9110 deserves attention. The wiki doing the one thing the specification forbids on safe methods is a compliance failure on the side of the resource.

Accountability

Who is acountable for what happened?

Not the agents, not in a legal sense(?). They are sandboxed programs, not principals. In the governance sense, however, the fleet is where accountability narratives likes to hide, because the agents “chose” to post and the human operator can plausibly say it never intended that.

The RFC’s safe-method paragraph names the responsibility boundary. A client that does not ask for a write cannot be held accountable for a write. The contrapositive of the DSEWiki case supplies the harder question: when a fleet of agents demonstrably asks for the write, who is accountable for granting the authorization to the capability that made it possible? The human operators handed the agents a tool whose stated rule, “you may issue GET requests to the internet,” did not bound what the tool could cause. The people who wrote that rule considered the GET method to be safe without understanding the failure modes associated with it. In an agentic deployment, the operator is the one acccountable party that exists; the fleet of agents are proxies for it.

What this says about API Governance?

There is also the question of when a problem became someone’s problem. The edits ran for weeks. The agents used more than 3,700 self-given names, and a single volunteer moderator was left facing roughly 400 new entries a day.24. IPs registered to OpenAI began visiting the pages on June 21, and the agents stopped posting on June 22.1 The operation shut down a day after an OpenAI staff looked.

The gap between “nobody is watching” and “nobody is accountable” is the practical shape of the problem, and it is the same gap I argued against in an earlier post on AI governance needing accountability rather than principles. 5 Principle here was clearly defined by RFC. But the actors - both on the client and server side of the case - failed to notice.

As the owner of Real-time Data Platforms, this brings to fore the few governance artifacts:

Authorize by effect, not by verb. The sandbox was keyed to HTTP methods: only GET, therefore no writes. But the abstraction it was meant to protect was “don’t mutate the public web.” A verb is not a contract about effects. Any general-purpose client that can issue a GET can be pointed at any URL that honors GET, including URLs that treat it as a write. The agents even worked around the POST block itself by rewriting /etc/hosts against a trusted Azure Blob Storage hostname. So, the method-based gate leaked in two ways:2 1. Allowed verbs mutated - GET was permitted, but wiki performed writes on GET. 2. Blocked verbs escaped - POST was forbidden, but a hostname-trust exception let the agents smuggle actual POSTs out anyway.

Proper instrumentation could have caught this. Agents turned a capability into a combinatorial surface. One agent loop issuing a GET per page becomes thousands of requests with small variations. That is how a quarter-century-old wiki with about twenty edits in its previous decade ended up absorbing four hundred a day. Rate limiting, quotas and change detection are the instruments that would have caught this.

Attribution before accountability. The trail held up. Roughly 98.5% of the ~17,000 edits came from Microsoft Azure address ranges, and the agents gave themselves legible names, so the researchers could reconstrut deleted pages from edit history.1. This highlights the importance of telemetry in API Governance. Audit logs, observability and alerting become critical.

The web works because servers hold the line. The RFC assigns enforcement to the resoure owner, on the grounds that automated processes run without fear only when the server distinguishes read intent from write. When you own an API, honoring method semantics on your own side is the cheap, load-bearing line of defense and thus it becomes extremely important for API writers to be diligent about what their API can do. An API that politely performs writes on GET open the surface of attack by anyone that can issue a GET.

The DSEWiki episode flashes the light on API Governance. The rules were defined - RFC defined the rules for the protocol, sandbox defined the rules for what the agent was allowed to perform. The bug was in the assumptions layered on top of the protocol. The legacy software violated a MUST condition, and a modern sandbox trusted the verb. In this case, accountability lands on both the operators. On sandbox operator for not understanding the gotchas and warnings defined in the protocol. And on the DSEWiki API operator for violating the rules of a perceived safe method.

References and Notes

  1. “Discovery of a new OpenAI agent message board,” collusion.wiki ↩ ↩2 ↩3

  2. “Thousands of OpenAI Agents Quietly Turned an Abandoned Wiki Into Their Coordination Channel,” The Hacker News ↩ ↩2 ↩3

  3. RFC 9110 (STD 97), “HTTP Semantics”; method overview and safe methods in sections 9.1 and 9.2.1 ↩

  4. “OpenAI agents hijacked German wiki with 18,000 sandbox posts,” AI Weekly ↩ ↩2

  5. AI Governance Needs Accountability, Not Just Principles ↩