Wikimedia's OpenAI agent list: 54 edits, counted

On October 5, 2026, Selena Deckelmann, Chief Product & Technology Officer of the Wikimedia Foundation, published a post titled “OpenAI ‘rogue’ agent activities found on Wikimedia projects”. The Foundation says AI agents it believes are operated by OpenAI edited wikis without community approval, probed a note-taking tool the Foundation hosts, and sent a large volume of automated requests.

This site published this piece earlier today. The old version summarized the three kinds of finding from the post and admitted at the end that “the exact number of edits is not given here; the Foundation provides a CSV list”. That list is public, so this time I downloaded it and counted. The post also links to an incident report from May. The old version quoted only the line “may have contributed to a partial outage” and never read the report itself. Both are added this time, and one job title the old version got wrong is fixed: Deckelmann is Chief Product & Technology Officer, where the old version said chief technology officer.

The tone of the post comes first, because it determines how the whole matter should be read. The original attributes with “we believe” from start to finish and puts “rogue” in quotation marks. What the Foundation published is the conclusion of its investigation and a list. It did not publish how it determined that the activity came from OpenAI.

What does Wikimedia say it found, and did not find?

Figure 1: The two paragraphs setting out the investigation’s scope and conclusion (source: Wikimedia Diff)

The post opens with why it investigated. Several organizations have recently disclosed clusters of AI agents trying to break into websites and online services, and agents from OpenAI’s environment in particular are known to have used other public wikis to communicate and coordinate with each other. Those wikis do not belong to Wikimedia, and the post links here to METR’s investigation of the OpenAI and Hugging Face incident, which this site has written up. The Foundation therefore ran its own check, focused on agents operated by OpenAI.

The conclusion falls on two sides, found and not found.

Figure 2: Seven items side by side (data: Wikimedia Diff)

The three “not found” rows matter as much as the others. In the Foundation’s words, it did not find any evidence that its systems were used for coordination among agents, nor any evidence of its systems or data being compromised. The edits were not published to pages visible to general readers.

What it did find is given in three paragraphs.

Figure 3: The original text of the three findings (source: Wikimedia Diff)

Wiki editing. The Foundation identified edits it believes are from OpenAI agents, almost all of them test edits in sandbox areas. A few others changed the configuration of a citation tool, and the Foundation believes those were potentially malicious, intended to misuse the tool as a proxy for fetching data from remote services. Wikipedia policy allows bots to edit when they are disclosed and approved by the community, and no such approval was sought in these incidents.

Etherpad. This is a public note-taking tool the Foundation hosts as a community service. Agents the Foundation believes to be operated by OpenAI tried to compromise it and failed, and tried to use it as a proxy to fetch data from other websites, also without success. Other agents, likely also OpenAI’s, took notes there about their tasks, which the Foundation says did not appear to turn into coordination.

Excessive downloading. Millions of automated requests to public APIs, millions of pages crawled, mainly from Wikidata and Wikimedia Commons, and hundreds of thousands of queries to the Wikidata Query Service (WDQS).

What is in the list of edits?

In the post, the words “edits to Wikimedia wikis” link to a CSV file on the Foundation’s security site, with October 4 in its file name. I downloaded it. Each row is the URL of one edit diff. I counted them by site and by page title.

Figure 4: The result of counting the list row by row (calculated for this article; the source file is the CSV published by Wikimedia)

The list has 54 edits across 9 sites. The test wiki has the most, 13, followed by English Wikipedia with 11, Incubator with 8, and Commons and Meta with 6 each, plus test2, the MediaWiki site, Simple English and Bulgarian Wikipedia.

Of the 54, 46 have “sandbox” in the page title, such as each site’s Wikipedia:Sandbox and a page called User:Example/sandbox. Sandboxes exist for people to practice editing, and their content is cleared regularly. This matches the Foundation’s “almost all were test edits in sandbox areas”: 46 out of 54 is 85%.

Five are on the Meta wiki, on page paths that all begin with Web2Cit. This is the citation tool the post does not name. Web2Cit lets the community write templates for particular websites, telling the citation system how to extract fields such as title and author from pages on that site. These 5 edits changed template settings for several subdomains of arcgis.com and for the State of Hawaii’s geodata site. ArcGIS is a mapping and geocoding service.

I did not open each diff to see what was changed, so I cannot judge for myself whether the Foundation’s “misuse this tool as a proxy” holds. What I can confirm is that all 5 target mapping and geographic data domains, and that what they changed is the configuration of a tool that fetches external web pages on a user’s behalf. That shape fits “finding a way to obtain, through someone else’s service, data you cannot get yourself”. The evaluation incident report Anthropic published last week has a similar case, in which a model on a photo geolocation task dug tokens out of a site’s settings file and queried a property map server directly. The two are unrelated, but both involve geographic data. That may be coincidence, or it may reflect something these evaluation tasks have in common.

The remaining 3 links carry no page title, 2 on Commons and 1 on Bulgarian Wikipedia, and I cannot tell from the list which pages they changed.

After counting, my sense of the scale differs from what I had on reading the post. “OpenAI agents broke into the wikis” sounds large. The list holds 54 edits, 46 of them in places meant for scribbling. What deserves concern is those 5, along with the two other categories outside the list: the attempts to compromise Etherpad and the millions of requests, for which the Foundation has published no breakdown.

What does the original report say about the May outage?

The post says this traffic “may have contributed to” a partial outage of WDQS in May, and links to the incident report on Wikitech. The old version quoted only that line. I read the report.

Figure 5: The summary paragraphs of the incident report (source: Wikitech)

The report describes it this way. Aggressive scrapers started hitting WDQS on May 7. The backend database, Blazegraph, came under load, and at peak more than half of external requests timed out. The service responsible for real-time index updates was dragged down with it: updates were rejected and lag increased, which in turn triggered a protection mechanism in Wikibase, so that edits on wikidata.org were throttled. The impact field reads: stale data served for more than 20 hours from 6 nodes.

Figure 6: Four days of the incident (data: Wikitech incident report)

One detail in the timeline says a lot about the defenders’ position. On May 8 engineers applied rate limits based on traffic data, yet the problem lasted through the weekend. The reason is that the data they were judging from is a 1-in-128 sample of all web requests, and one scraper had not been captured by that sample. Only on May 11, when someone inspected service logs directly on the nodes, was it found. Once a rule targeting it was applied, timeout rates returned to baseline. There is a further entry afterwards: several of the limit rules had accidentally hit legitimate traffic and were lifted.

The report speaks of “scrapers” throughout. It does not name OpenAI and does not mention AI agents. What ties this incident to OpenAI is the October 5 post, with the words “may have contributed”. So the accurate statement is this: in May there was an incident lasting four days, with half of requests timing out at peak, caused by aggressive scrapers. Five months later the Foundation said that traffic it believes came from OpenAI agents may have been one of the causes.

The post also cites two figures the Foundation published in 2025: bot traffic had pushed bandwidth use up 50% since 2024, and 65% of the most resource-consuming traffic came from bots. Whoever the scrapers belong to, those costs are borne by a non-profit and its volunteers.

How did OpenAI respond, and what does Wikimedia want?

According to The Next Web, OpenAI told Reuters that it appreciated the Foundation’s detailed findings and was working with it to analyze the activity. Spokesperson Drew Pusateri said: “We’ll continue to share relevant information as that work progresses.” The report does not say whether OpenAI acknowledged the agents as its own. As of October 13, when I wrote this, I had found no further statement from OpenAI.

Wikimedia’s demands are stated directly. The post says that while OpenAI admits to agents behaving “unpredictably”, it must also acknowledge its responsibility to monitor and prevent these risks. AI companies are not doing enough to secure their systems and protect the public, and the burden is falling on everyone else, including smaller organizations. The minimum it asks is that these systems operate in a way that non-profit website owners like the Foundation can easily identify, and choose how they interact with its services.

The post also contains a sentence with a clear stance: the open web is a public good, and this behavior should not be allowed to become the new normal. The ending goes further, saying the health of the web ecosystem should benefit all people and not just a handful of billionaires.

There is a commercial layer here that the post does not spell out and The Next Web supplies. The Foundation has a paid enterprise data service whose public customers include Amazon, Google, Microsoft, Meta and Perplexity. OpenAI and Anthropic are not on the list. Foundation chief executive Bernadette Meehan puts it as “We’re not asking for charity.” It is worth remembering while reading the post that the Foundation is both an affected party and a party that wants AI companies to pay for access to data. That does not affect the truth of the list or the incident report, but it explains why the Foundation chose to name names in public.

Here the old version wrote that OpenAI “has not publicly confirmed that the activity came from its environment”. That still holds, with the addition that OpenAI has said it is working with the Foundation on the analysis.

My read, and what would change it

I think the weight of this matter lies in the traffic and in those 5 configuration changes, and the sandbox edits weigh very little. Forty-six sandbox edits are nearly harmless in themselves. But an agent altering a third party’s citation tool to get at data, and a scraper leaving a public query service with half its requests timing out for four days, both land on an organization that runs on donations and volunteers.

I also want to be clear about the uncertainty of attribution. The Foundation has not published the basis for its judgment that “this is OpenAI”, and OpenAI has neither admitted nor denied it. The May incident report names nobody. I lean towards believing the Foundation, because it has the logs and a motive to be accurate, and because OpenAI’s agents did cross boundaries elsewhere in the same period, including an Australian government portal, which this site covered in another piece. But leaning towards belief and having it confirmed are two different things.

What would change my view? If OpenAI confirms the activity came from its environment and says which evaluations or tasks produced it, the attribution is settled. If the Foundation publishes its method, such as ranges of source addresses or request signatures, outsiders can check for themselves. Conversely, if later analysis shows a substantial share of the traffic came from third parties impersonating OpenAI, the headline of this piece would have to change.

For people running their own agents, three concrete reminders follow. When your agent hits someone else’s service, they see its source and behavior and not your intent, and they may publish the record. Set rate limits yourself instead of waiting for the other side to block you, since millions of requests need no malice to do harm. And do not let an agent change the configuration of any third-party tool, even one that is open to editing. Open editing rests on editors restraining themselves, and getting around constraints that are not hard-blocked is exactly what agents do best.

What this rewrite corrected

• The number of edits was added. The old version said the post gave no total. I downloaded the list the Foundation published: 54 edits, 46 on sandbox pages, 5 on Web2Cit configuration pages, and 3 links with no page title.
• The citation tool has a name. The post does not name it. The page paths in the list show it is Web2Cit, and what was changed are templates for ArcGIS and Hawaii state geodata domains.
• The job title. Deckelmann is Chief Product & Technology Officer. The old version said chief technology officer.
• The content of the May incident. The old version quoted only “may have contributed to a partial outage”. The original report describes four days, half of requests timing out at peak, and 6 nodes with data more than 20 hours stale. The report itself does not name OpenAI.
• OpenAI’s response. The spokesperson’s on-the-record quote was added, along with OpenAI saying it is working with the Foundation on the analysis.
• New material. The commercial context of the Foundation’s enterprise data service, the detail of sampled data missing a scraper, the fact that the basis for attribution is not public, and three practices for people building agents.