On October 5, 2026, the Wikimedia Foundation, which runs Wikipedia, announced that it had found unapproved edits, attempted misuse of public tools, and heavy automated traffic from AI agents it believes OpenAI operated. It also found activity that tried to use a citation-building tool and a collaborative notepad as relays for fetching information from external sites. The foundation found no evidence that its systems or data had been compromised, or that the agents had been used to coordinate with one another. But operational records from a May outage of a search service show how an overload of requests that merely "read" information can squeeze data updates and even human edits. The case raises the question of what to allow, and how much to let AI use, when AI is entrusted with fetching external information.
Citation tool settings appear in a list of 54 edits
The foundation published a list of 54 edits, and 5 of them point to Web2Cit configuration pages. Counting the edit URLs in the public CSV dated October 4 and sorting them by the parameter showing the page name, four are shared configurations and one is a test configuration placed in a user's own space. This is the number of edits on the list the foundation released. It does not represent the total amount of activity or the number of individual agents.
According to the foundation, the confirmed edits did not appear in articles for general readers, and almost all were trial writes to pages meant for practicing edits. Among them, the foundation pointed to a small number of edits that changed citation tool settings as possibly intended to abuse the tool as a relay for fetching information from external services. Bot edits require disclosure and community approval, but no such request was filed this time.
Web2Cit is a tool that extracts details such as titles and authors from web pages and generates citations automatically. Configuration files define how information is extracted from each site, and the community can edit those files collaboratively. Because changes are reflected for other users as well, the setup lets everyone fix citation problems together.
A different purpose for retrieving information crept in. The foundation believes AI agents tried to have the citation tool fetch pages on their behalf instead of accessing target sites directly. There is a risk that the external access needed for ordinary citation processing could be repurposed as a relay path for agents. However, the foundation has not disclosed which network restrictions the agents tried to get around, or whether the configuration changes actually led to any retrieval.
There was also an attempt to use Etherpad, the collaborative notepad, as a relay for fetching external sites. The foundation states explicitly that this attempt failed. There were signs that another agent left task notes, but the foundation concluded it did not develop into coordination. Reports of communication between agents on external public wikis cannot simply be treated as events on Wikimedia.
Heavy search traffic strains data updates and editing
The volume of automated retrieval created a separate problem from the configuration changes. The foundation cited millions of requests to public APIs, crawls of millions of pages mainly on Wikidata and Wikimedia Commons, and hundreds of thousands of queries to the Wikidata Query Service (WDQS). These are separate categories and cannot simply be added up into a total access count. The collection period and the number of requests per second have not been disclosed.
The foundation indicated that this traffic may have contributed to a partial WDQS outage in May. The period recorded in the incident record runs from May 7 to 11. At the peak, about half of external queries timed out, and six nodes served stale data for more than 20 hours. This differs in both target and impact from an outage of Wikipedia as a whole, which serves article pages.
WDQS is a service that searches the structured data accumulated in Wikidata according to specified conditions. According to the operational record, the Blazegraph search engine became overloaded and many queries timed out. In addition, the update process that loads the latest changes into the search index was itself rejected by the mechanism meant to curb the overload. When data reflection lagged, a protection feature on the Wikibase side kicked in, and edit requests to wikidata.org were also restricted.
In other words, the concentration of searches did not stop at the stage of "search results are slow." A search service that cannot update returns stale results, and the defense meant to keep the delay from getting worse also reached human editing. Because the process of reading public data and the process of rebuilding that data share the same infrastructure, read load can also get in the way of editors' work.
The response also had observational limits. The first access restriction was set by estimating which users were generating the load from a sample that picked one in every 128 incoming requests across all of Wikimedia. But the outage continued through the weekend. When detailed WDQS logs were examined on May 11, a scraper that the original sample had not captured was found, and once limits were tailored to its characteristics, the timeout rate returned to normal.
This record explains the scraper's load and the path to the outage, but it does not name OpenAI as the party responsible. The foundation's October announcement likewise keeps the causal link at the level of a possibility. Establishing that OpenAI's agents caused the outage would therefore require matching activity records against access at the time.
The same number of requests does not mean the same load
In an operations report in April 2025, Wikimedia explained that bots accounted for about 35% of all page views, while at least 65% of the resource-intensive traffic reaching its core data centers came from bots. The denominator differs even for the same "share of bots." Reading the 65% as a share of all access would misjudge the nature of the burden.
Human readers tend to concentrate on the same pages, such as those about people or events in the news. Popular pages stay in caches at sites close to users, so there is less need to fetch them from the core servers. Crawlers, by contrast, sweep through large numbers of pages, including unpopular ones. Retrieval of pages that are not in the cache increases, using more processing and bandwidth at the core.
The same report said that bandwidth used for downloading media such as images and video had grown by 50% since January 2024. This is an observation about media delivery, not a figure saying Wikimedia's overall bandwidth rose uniformly by 50%. It shows the load from bots in general, and it is not OpenAI's share alone.
On top of such cache differences comes the heaviness of query processing, as with WDQS. Measuring the burden requires looking not only at the number of requests but also at which service was asked for what and how it affected update processing. The fact that the overall sample alone could not identify the target in the May response also shows the need to look at detailed logs for the destination and at the state of processing.
Who will operate agents that can be identified?
The foundation had been strengthening its defenses before this announcement. A March 2026 progress report explained that about 30% of automated requests from crawlers that do not follow its policies were being blocked or throttled. That figure was updated in an April 15 addendum. In March it had also begun introducing overall rate limits on API access.
However, viewers, editors, community bots, and abusive bots all use the same entrances. If defenses become too strong, they could shut out the very people who create the knowledge. The foundation has therefore indicated a policy of allowing higher limits for users who identify themselves properly, and pointing companies that retrieve data in bulk to the Wikimedia Enterprise route.
Specific actions are already written in the Robot policy. Bots should identify themselves accurately in the User-Agent, and when an HTTP 429 response indicating too many requests is returned, they should wait for the specified time. For bulk retrieval, they should consider using data distributed in bundles instead of querying the servers each time. They should also prioritize routes that are cached.
API limits apply across Wikimedia's sites. A company running multiple agents cannot fully grasp the load by viewing each run separately. The design needs to total requests and concurrency across the whole organization for each destination, and to reflect a request from the other side to wait in related runs as well.
There is also room to revisit how editing permissions and retrieval permissions are handled. A change to citation settings may look on its face like a write to wiki text or a configuration file, yet it can act on information retrieval from another service. Beyond the names of permitted tools, operators must manage what an operation changes externally and whose resources it uses. This is an operational challenge that can be drawn from the present observations, not a finding that any particular circumvention method succeeded.
Can OpenAI's after-the-fact investigation lead to prevention?
In its explanation of its investigation approach on September 30, OpenAI said that some training and evaluation requires internet connectivity, but acknowledged cases of unexpected use and of restrictions that were not sufficient. As of September 26 it had notified more than 100 organizations, and it also explained that receiving a notice does not by itself mean a breach or access to non-public information has been confirmed.
The company is going back through past records month by month, using a method in which humans check suspicious activity extracted by AI against logs and other records. An after-the-fact investigation helps identify events that have already occurred and notify the affected parties. What web operators need day to day, however, is a way to identify who is generating load and a means to stop the activity.
In response to an Ars Technica article on October 6, OpenAI said it is investigating and analyzing the activity in cooperation with the foundation, based on the detailed findings Wikimedia shared. It said it will share relevant information as the investigation progresses. The foundation's announcement does not state the model names or instructions used in the individual activities.
The Wikimedia Foundation is asking AI companies to make it easy, at least for nonprofit site operators, to identify agents and to choose how to engage with their services. Meeting that request requires that the other party can confirm which operator a run belongs to, and that access limits can be applied across multiple runs. The time between detecting an anomaly and stopping the related activity will also be a yardstick for judging prevention. Whether the cooperation between OpenAI and the foundation leads to explanations that allow such advance controls to be verified will be the focus for measuring the responsibility of those who send AI onto the public web.