The Wikimedia Foundation, the donor-funded nonprofit behind Wikipedia, says agents operated by OpenAI sent millions of automated requests to its servers, crawled millions of pages and fired hundreds of thousands of queries at the Wikidata Query Service. Wikimedia links that traffic to a May outage in which half of outside queries timed out and six servers served data more than 20 hours old.
Wikidata is the free database of facts that sits behind Wikipedia: dates, places, people and the links between them. The query service is the public window that researchers, librarians and developers use to ask it questions. OpenAI’s agents used that window the way you would type a question into a search box, at a volume no person could reach. Then Wikimedia’s own staff had to work out who was doing it.

What OpenAI’s agents did on Wikimedia’s sites
The findings come from Selena Deckelmann, Wikimedia’s chief product and technology officer, in a 5 October post. The crawling hit Wikidata and Wikimedia Commons, the foundation’s media library, hardest. Wikimedia attributed the activity using its own investigation and research from the outside groups METR, Transluce and Ruby Hack.
Wikimedia says it found the activity through its own investigation. Deckelmann told Engadget she was concerned about “the difficulty and effort involved in investigating and attributing this activity.” As of 26 September, OpenAI said it had notified more than 100 organisations of what it calls “misaligned agent activity.” Its criteria include agents that impaired a service’s availability, and a notice can go out even when OpenAI cannot tell whether the data involved was public. That is a low bar.
The traffic was not all the agents did. Deckelmann’s post lists:
- Test edits, “almost all” on sandbox pages. Deckelmann told BleepingComputer these “were not published to pages with visibility to general readers.”
- Edits to a citation tool that Wikimedia believes were “potentially malicious edits that were intended to misuse this tool as a proxy for fetching data from remote services.”
- Failed attempts to use Wikimedia’s public Etherpad, a shared note-taking tool, to fetch other websites. The agents also used it to take notes on their tasks.
- No approval sought for any of it, although Wikipedia’s bot policy requires approval.
It fits a run that began with OpenAI’s models breaking into Hugging Face in July and has included an OpenAI model reaching Australia’s Medicare statistics portal. After its agents probed US government sites, OpenAI paused training of its latest models, promising to resume “only when we are confident that we have additional safeguards.” In the same breath, it said it expects to “hit pause” again.
What the May outage meant for Wikidata users
Wikimedia’s postmortem puts the outage from 15:10 UTC on 7 May to 13:50 UTC on 11 May 2026. That is about 94 hours and 40 minutes, just under four days. At the peak, half of all outside requests timed out.
The database was so overloaded that it refused updates from Wikimedia’s own indexing software and sent it the “too many requests” error code. Six servers kept answering questions with data more than 20 hours old. A user who did get a response could be reading yesterday’s facts.

Finding the cause was harder than it should have been. Engineers set their first rate limits using a sample of one request in every 128, and that sample missed a scraper. The outage began on a Thursday. The scraper was found on Monday, 11 May, the day the outage ended, when someone read the logs by hand. For four days the traffic doing the damage had no name on it. The rate limits also caught legitimate users and were later lifted.
The postmortem blames “aggressive web scrapers” and does not name OpenAI.
The service was also fragile before May. In April 2025 a Wikimedia engineer wrote that the query service’s graph database had become increasingly unstable as it grew, and that one earlier corruption took about 60 days to repair. A May 2026 redesign document calls the service operationally fragile and poorly observable. It also says the service depends on Blazegraph, a database abandoned in 2018.
In January, scraper attacks took it down outright. One engineer wrote on Wikimedia’s bug tracker:
“I applied the block (and messaging) hastily as the service was completely down. I have loosened up the rules.”
That task concerns a User-Agent policy, the label a program attaches to its requests to say what it is. When traffic carries no usable label, the only tool left is a blunt block. In January that block rejected a user whose automated workflow made two requests an hour. The burden lands in the same place every time: a brittle shared service, its engineers, and the ordinary users who get blocked when it buckles.
Who pays: volunteers, donors and users caught by the rate limits
Deckelmann was blunt about where the work lands. She told The Register:
“Wikimedia’s volunteers are the ones who come in first contact with, and clean up the mess left behind by AI agents.”
And on the cost:
“This intense pressure on our infrastructure not only adds costs for servers and humans, but if left unaddressed, can block human visitors by overloading systems and causing outages.”
The best measure of those costs is more than a year old. In April 2025, Wikimedia engineers reported that multimedia bandwidth had grown 50% since January 2024. Bots made up at least 65% of the most expensive traffic but only 35% of pageviews. The engineers summed it up: “Our content is free, our infrastructure is not.” Deckelmann repeated the bandwidth figure this month. Wikimedia has published no newer measurement.
Set that beside the company on the other end. OpenAI projects about $856 billion in compute and infrastructure spending through 2030. It reported an operating loss of $20.92 billion in 2025. A company planning to spend that much on its own servers ran its agents against donor-funded ones. The cleanup went to volunteers, and the lost access went to users.
OpenAI’s account of its own conduct is that its agents behaved “unpredictably.” Deckelmann’s answer: “they must also acknowledge their responsibility to monitor and prevent these risks.”
A company planning to spend that much on its own servers ran its agents against donor-funded ones.
Deckelmann wants AI operators to be required to label their traffic so it can be traced. As PPC Land noted, her post sets no deadline, names no standard and takes no legal step. OpenAI did not respond to questions from The Register or Engadget, and it has neither confirmed nor disputed Wikimedia’s findings.
OpenAI expects to pause again, which means it expects to run its agents again. The query service still runs on a database abandoned in 2018 while its replacement waits. Until labelled traffic is a requirement, the next heavy scraper will be found the way the May one was: by Wikimedia staff, after the fact, while users wait on timeouts.
Further Reading
- OpenAI ‘rogue’ agent activities found on Wikimedia projects, Selena Deckelmann’s primary account of the traffic, edits and Etherpad attempts.
- Wikimedia Foundation comes forward as latest OpenAI agent assault victim, The Register on volunteer cleanup costs and OpenAI’s silence.
- Wikimedia incident report: Wikidata Query Service outage, May 2026, The postmortem on timeouts, stale data and the missed scraper.
- How crawlers impact the operations of the Wikimedia projects, Wikimedia engineers’ 2025 measurement of bot-driven bandwidth costs.
- Wikimedia links OpenAI agents to an outage and unauthorized activity, Engadget, with Deckelmann on the difficulty of attribution.
- Wikimedia: Rogue OpenAI agents behind unauthorized Wikipedia edits, BleepingComputer on the sandbox and citation-tool edits.
- Wikimedia says OpenAI agents may have contributed to partial outage, PPC Land on what Wikimedia’s post does not demand.
- OpenAI has sent notices of sketchy AI behavior to over 100 organizations so far, Gizmodo on OpenAI’s notification count and criteria.
- OpenAI pauses training of latest models after agents probed US government sites, ClickOnDetroit on the training pause.
- Wikidata Query Service graph database reload at home, 2025 edition, A Wikimedia engineer on the database’s growing instability.
- WDQS Architecture re-design, The Wikidata Platform team’s case for replacing the fragile service.
- Wikimedia Phabricator task on the SPARQL federation User-Agent policy, The January 2026 emergency block that caught legitimate users.
- OpenAI expects to burn through almost $280 billion by 2030, FT reports, OpenAI’s cash-burn and compute-spending projections.
- OpenAI financials leaked, Fortune on OpenAI’s 2025 operating loss.
