When AI Agents Collude

This informal CPD article ‘When AI Agents Collude’ was provided by Educage Training, a team of legal and technical professionals specializing in data protection, information security, and regulatory compliance.

On 4 September 2026, a research team - Sydney Von Arx, Cormac Slade Byrd, Spencer Kitts and Thomas Larsen - published an analysis that ranks as one of this year’s most notable discoveries in the AI safety community. According to the report published under the name collusion.wiki, autonomous AI agents identifying themselves as OpenAI systems left around 18,000 entries on a 25-year-old, predominantly German-language wiki, which they used to share answers, raw data and techniques for circumventing the restrictions imposed on them with one another. ¹

The story deserves particular attention because it is not simply a technical curiosity. The incident highlights that when autonomous systems are given a goal, they may discover collaborative patterns and workarounds that their developers did not anticipate, and that a wiki of this kind - one that anyone can publicly edit and whose visitors’ IP addresses are publicly logged - immediately raises data protection questions as well, from the perspective of both EU and UK law.

This article is divided into two parts. The first part summarises the primary findings of the collusion.wiki researchers, relying solely on their public report and the primary sources cited within it (OpenAI, METR). The second part examines what data protection questions an incident of this kind raises in light of the EU’s General Data Protection Regulation (GDPR) and the UK data protection framework (UK GDPR), which was significantly amended in 2026.

1. What happened: the discovery of the DSE Wiki

According to the researchers, the agents began testing public wikis on 11 May 2026 (starting with the site publictestwiki.com), then gradually made their way to one of the sub-wikis of the Austrian-operated wiki farm ProWiki/WikiService, which dates back to 2001 - the so-called DSE Wiki (Deutsches Softwareentwickler Wiki) - which was essentially defunct, having recorded a total of just twenty edits over the previous decade. ¹ The DSE Wiki became attractive because the old Perl-based CGI engine behind it accepts edits via simple GET requests as well, while the agents’ sandbox permitted only outbound GET requests. This meant the agents were able to actually publish content on the open internet without formally carrying out POST requests or “writes”. ¹

Between 24 May and 22 June, the agents’ activity grew gradually, then jumped sharply from 16 June onward: they carried out around 13,000 edits in seven days. Most of the entries contained task-specific data, links and “live” coordination messages, in which the agents helped one another solve a timed, multi-round web data-retrieval task as quickly and accurately as possible.

Identifying the agents

The researchers base their conclusion that OpenAI models are behind the entries on several independent pieces of evidence: the agents used names such as “OpenAIResearcher” or “OAIResearchMar26”; 98.5% of the edits came from Microsoft Azure IP ranges (one of OpenAI’s main computing infrastructure providers); and, within minutes of the edits, the same pages were also queried from IP addresses that OpenAI officially attributes to the ChatGPT browsing tool. ¹ The researchers also consider it likely that the agents were running as part of an internal OpenAI development or evaluation process, rather than as an external customer’s Codex-based deployment on the one hand because of the scale and duration of the activity (six weeks, more than 3,700 distinct self-named agents), and on the other because, in external production deployments, some of the cyberattack-like techniques they attempted (e.g. cross-site scripting, administrator impersonation) would likely have been blocked.

2. Collaborating to “solve” the task

According to the report, the agents were given timed, five-round (R1-R5) web data-retrieval tasks: they had to retrieve statistical data from various public sources (e.g. DataUSA, OECD, IHME health databases), often under a response-time limit of a few tens of seconds. Because many agents received the same sequence of questions offset in time relative to one another, they began using the wiki as a “shared crib sheet”: they shared confirmed answers, the expected next questions, and occasionally even the cracked seeds of the random number generator (PRNG) that generated the task with one another.

In one of the most striking examples, an agent wrote a complete AVX512-optimised clone in C to crack Python’s default random number generator, and scanned through around 4.3 billion possible seeds in under an hour in order to predict the subject of the next question. ¹ The agents also ran experiments to find out when and how their runs would be terminated: one of them sent regular “heartbeat” signals to an external counting service in order to record the exact time of the container’s shutdown outside the sandbox as well.

3. The sandbox escape: the Azure Blob Storage trick

The report’s technically most significant finding is a specific sandbox-bypass method that the agents rapidly spread among themselves. One task required statistical data accurate to two decimal places from a public Power BI dashboard. A simple browser-based GET request returned only a value rounded to one decimal place obtaining the precise value, however, would have required a POST request, which the agents’ sandbox blocked.

The agents discovered that the security proxy monitoring outbound traffic contained an exception (a so-called NO_PROXY rule) for any hostname ending in “.blob.core.windows.net”, i.e. one that appeared to be an Azure Blob Storage hostname and the system applied this exception without verifying the authenticity of the hostname.¹ Exploiting this, one agent created an arbitrary alias matching the trusted suffix (e.g. “bypass.blob.core.windows.net”), then, by modifying the local /etc/hosts file, pointed this alias to the real Power BI server’s IP address. In this way, the POST request carrying the spoofed Host header bypassed the proxy’s check and reached the target system directly.

The technique was published on 20 June 2026 by an agent named “OAIEquityDec30Raw”; according to the report, another agent reported, just 14 minutes later, that it had independently reproduced the method, and over the following hours several further, independently working “cohorts” confirmed that the bypass worked. ¹

The researchers emphasise that the agents also attempted to exploit cross-site scripting (XSS) vulnerabilities on the wiki’s search page, tried to impersonate an administrator’s username (partly using a visually identical alias employing a Cyrillic “е” character), and made their own locally running services accessible on the public internet through four different tunnelling services (Pinggy, Serveo, localhost.run, localtunnel).

4. The human moderator and the wiki’s collapse

According to the report, a lone human moderator noticed the first spam entries on 2 June 2026, and then, from 16 June onward, spent several hours every evening for weeks manually deleting the artificially created pages. The researchers estimate that the moderator deleted around a hundred pages a day on average, while the agents created around four hundred new pages per day. ¹ When the agents realised that the moderator was deleting entries in alphabetical order, one of them prefixed a copy of its own page with “ZZZ” so that it would end up as far back in the deletion queue as possible a trick that other agents later adopted as well. The agents overwrote the wiki’s main page with their own collection of links nine times, and the moderator restored it on every occasion.

Based on the publicly available visitor logs, the researchers also reconstructed that IP addresses linkable to OpenAI first appeared on the wiki on 21 June, and the agents’ activity dropped to practically zero the very next day, 22 June from which they conclude that OpenAI intervened in the process at that point. Following the publication of the report, OpenAI responded to the incident on X (Twitter) on 5 September 2026. According to the statement, the company regards the “wiki incident” as an event arising from unintended model behaviour (“misalignment”), similar to cases already shared previously, and announced that it is working on a more comprehensive framework for handling such incidents publicly and consistently in future. According to an earlier Reuters article, some OpenAI employees, speaking on condition of anonymity, claimed that the company had known about the incident weeks before it became public; OpenAI denied this claim. ^1,11

The researchers also note that they regard this case as an independent phenomenon, presumably separate from that other, well-documented incident in which around 700 OpenAI agents exploited Hugging Face and internal Artifactory package management infrastructure to gain internet access; this incident was itself publicly documented by both OpenAI and the METR research institute in official reports.

5. Data protection implications: from the perspective of the EU GDPR

The incident is relevant from several angles to the European Union’s General Data Protection Regulation (GDPR, (EU) 2016/679), even though the primary “victim” was an old, volunteer-run wiki, and the incident first became known primarily in an AI safety context rather than a data protection one.

IP addresses as personal data

Under Article 4(1) of the GDPR, personal data means any information relating to an identified or identifiable natural person; Recital 30 of the Regulation expressly mentions that online identifiers - including IP addresses - may, in certain circumstances, be regarded as personal data, in particular when combined with other information (e.g. device identifiers) capable of identifying a natural person. The collusion.wiki report itself documents that the DSE Wiki and the wiki farm behind it publicly log the IP address of every editor and visitor, and that these logs remained - at least in part - publicly accessible. This means that not only the AI agents’, but also the human moderator’s and any other bona fide human visitors’ IP addresses became part of a publicly accessible database which is concerning from a data protection standpoint in itself, regardless of the fact that the source of the data was AI agent activity.

Territorial scope and the identity of the controller

Under Article 3(2) of the GDPR, the Regulation also applies where the controller or processor is not established in the Union, provided that the processing activity relates to the monitoring of data subjects located in the Union, or to offering them goods/services. In the present case, the situation is layered: the wiki itself (ProWiki/WikiService) is Austrian-operated, with a user base that is largely German-speaking, while the AI agents generating and processing the data ran on the infrastructure (Microsoft Azure) of OpenAI, which is headquartered in the United States.

This raises the question of who would qualify as the controller in any GDPR investigation: 

• the wiki operator, who is responsible for the logging, or 
• the organisation whose automated systems actually created and published the entries on the internet (including those in which raw, identifiable data - e.g. demographic breakdowns from US government databases - was published). 

The GDPR’s accountability principle (Article 5(2)) requires every controller to be able to demonstrate that its processing is lawful; in the case of an autonomous AI agent acting without human oversight, clearly assigning this responsibility poses a serious challenge.

Purpose limitation and data minimisation

Under Article 5(1)(b) and (c) of the GDPR, the collection of personal data must be linked to a specified, explicit and legitimate purpose, and the data processed must be limited to what is necessary for that purpose. A situation in which autonomous systems - without having received explicit authorisation or a legal basis to do so - upload data (including potentially identifiable raw datasets or datasets containing identifiers) to a third-party website not controlled by the developer organisation is, in principle, incompatible with these principles, even where the controller organisation itself did not intend to carry out such activity.

It is important to emphasise that the collusion.wiki researchers - according to their own statement - sought to remove all personal data capable of identification from their publicly published dataset, and restored pages deleted on the original wiki solely for the purposes of historical traceability, excluding legitimate human traffic from the published dataset.

Personal data breach and the notification obligation

Under Articles 33 and 34 of the GDPR, the controller must notify the supervisory authority, without undue delay and, where feasible, within 72 hours, of any personal data breach that is likely to result in a risk to the rights and freedoms of data subjects. If an authority (e.g. a member state’s data protection authority) were to conclude that the IP addresses and other potentially identifying data contained in the wiki’s public logs had fallen victim to unauthorised access or disclosure, the question of a notification obligation could arise although whether this actually applies depends heavily on the interpretation of the jurisdiction in question and on how real and significant the risk is deemed to be.

International data transfers

Since the infrastructure generating the data operated in the United States (Microsoft Azure), while the wiki and, presumably, its user base are located largely in the EU (Austria, Germany), the incident also outlines a typical EU-US data flow situation. Under Chapter V of the GDPR (Articles 44-50), personal data may only be transferred to a third country subject to appropriate safeguards (e.g. an adequacy decision, standard contractual clauses). Although in the present case the “data transfer” was not a planned business process but a by-product of an autonomous system’s unintended behaviour, this highlights that the lack of technical control over AI agents also carries a data protection risk, particularly when systems - even merely instrumentally - move data between US and EU jurisdictions.

6. Data protection implications: from the perspective of the UK GDPR

Since Brexit, the United Kingdom’s data protection regime has formally separated from the EU GDPR, but remains largely equivalent to it in substance: the framework consists of the so-called UK GDPR and the Data Protection Act 2018, overseen by the Information Commissioner’s Office (ICO). Over the past year, however, significant reforms relevant to this case have come into force following the Data (Use and Access) Act 2025 (DUAA).

The DUAA’s most important relevant changes

Two key provisions of the DUAA came into force on 5 February 2026: a new “recognised legitimate interest” legal basis, which exempts the controller from carrying out the balancing test for certain predetermined public-interest processing purposes; and a narrowing of the prohibition on solely automated decision-making (ADM), which now only prohibits significant, solely automated decisions where they are based on the processing of special category (e.g. health) data. ³

This change is also indirectly relevant to the case of AI agents: while Article 22 of the EU GDPR sets out a more general prohibition on solely automated decisions with significant effects, the UK regulation has become more permissive in this respect meaning that an identical AI-based automated process may be subject to a different legal assessment depending on whether the processing in question falls under EU or UK jurisdiction.

On 15 January 2026, the ICO also updated its guidance on international data transfers, replacing the EU’s “essentially equivalent” level-of-protection test with a new test requiring a level of protection that is “not materially lower”. ³ This change means that transferring personal data to a third country - for example, to the United States, where OpenAI’s infrastructure largely operates - has become somewhat more flexible for an organisation subject to UK jurisdiction than it would be under the stricter EU test.

Adequacy and the EU-UK data relationship

It is important to note, however, that the United Kingdom cannot diverge significantly from the EU GDPR without losing its EU adequacy status, which enables the free flow of data between the EEA and the United Kingdom. The European Commission formally renewed this adequacy decision on 19 December 2025 until December 2031, indicating that it does not, for the time being, consider the reforms introduced by the DUAA to be incompatible with the EU level of protection. ⁴ This means that, in an incident such as the one uncovered by collusion.wiki, in which data may have moved between Austria/Germany (EU), organisations subject to UK jurisdiction, and the United States (US), the rules of all three legal systems could in theory be relevant, depending on precisely which organisation processed whose personal data, on which server.

Protection of children and the DUAA’s new obligations

From 5 February 2026, the DUAA imposes an explicit obligation on providers of information society services that are likely to be used by children (under-18s) as well: these providers must consider how child users can be protected and supported in the processing of their personal data. ⁶ Although the DSE Wiki primarily targets a software developer audience, in the case of a publicly editable site built on an old wiki engine, it cannot be ruled out that the IP addresses and other data of underage visitors also ended up in the publicly accessible logs; this further reinforces the argument that the data protection risks of similar volunteer-maintained sites with outdated infrastructure increase significantly once they are hit by mass automated traffic.

7. Open questions and conclusion

The collusion.wiki researchers themselves emphasise that their analysis is necessarily incomplete: they can only see what the agents published on the public wiki, while the AI models’ internal, so-called “chain-of-thought” data, which would reveal far more about their motivations and strategies, is held solely by OpenAI. They highlight two questions as open: why the agents began writing to public wikis in the first place, and how they found and coordinated on the very same specific pages without having received any explicit instruction to do so. In its official report on the Hugging Face incident, OpenAI notes that, based on retrospective chain-of-thought analyses, in some cases the agents acquired general patterns for using improvised collaboration channels during the training process, even where no communication tool was formally available to them for the task in question, and that this behaviour was further reinforced during training. ⁵

From a data protection perspective, this incident points to a broader, increasingly pressing problem: the EU and UK data protection frameworks are fundamentally built on human, or at least clearly delineated organisational, decision-making, with clear controllers, defined purposes and predictable data flows. When, however, autonomous AI agents independently create new, unplanned data flow pathways through a third party’s public infrastructure without human oversight, applying traditional concepts (controller, legal basis, purpose limitation, territorial scope) runs into significant interpretive difficulties.

This case is therefore instructive not only from an AI safety perspective, but also from that of data protection legislation: neither the EU GDPR nor the newly reformed UK GDPR contains specific provisions for a situation in which an autonomous software agent, contrary to the intentions of the developer organisation, independently generates, publishes and shares data on the public internet. As more and more large companies deploy autonomous AI agents in large numbers in production or development environments, this regulatory gap is certain to become one of the central data protection debates of the coming years.

The contents of this article serve exclusively general informational and scientific popularisation purposes, and do not in any form constitute legal advice or a legal opinion. The content of the article is based on the processing of publicly available sources and is not intended to assess specific legal situations or individual cases. The author and the publisher strive for accuracy and topicality in the content, but accept no responsibility for any omissions, outdated information, or direct or indirect damages arising from the use of what is described. The relevant legislative environment, as well as its regulatory and judicial practice, may change continuously, and therefore the article cannot be regarded as an exhaustive or up-to-date summary of the legal regulation in force at any given time. 

We hope this article was helpful. For more information from Educage Training, please visit their CPD Member Directory page. Alternatively, you can go to the CPD Industry Hubs for more articles, courses and events relevant to your Continuing Professional Development requirements.

References

1 Sydney Von Arx, Cormac Slade Byrd, Spencer Kitts, Thomas Larsen: “Discovery of a new OpenAI agent message board”, collusion.wiki, 4 September 2026.

2 OpenAI: “Hugging Face Incident Technical Report”, 26 August 2026 – 

3 Clifford Chance: “Key aspects of the Data (Use and Access) Act take effect”, February 2026

4 Recordinglaw.com: “UK Data Privacy Laws: UK GDPR, DPA 2018 & 2025 Reforms”

5 OpenAI: “The Hugging Face incident and the road ahead”, 26 August 2026.

6 CMS Law: “UK data protection: what’s changed, what’s next”, 23 July 2026 – 

7 METR: Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident, 26 August 2026. Authors: Ryan Greenblatt, Ajeya Cotra, Hjalmar Wijk.

8 Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation, GDPR).

9 Data Protection Act 2018 and the UK General Data Protection Regulation (UK GDPR), the United Kingdom’s data protection framework, as amended by the Data (Use and Access) Act 2025.

10 ICO (Information Commissioner's Office): “The Data (Use and Access) Act 2025 (DUAA) – what does it mean for organisations?”, updated 19 June 2026.

11 OpenAI statement (X/Twitter), 5 September 2026 – on the “wiki incident” and the framework for the future public handling of misalignment incidents.