Wikimedia reports unapproved activity by suspected OpenAI agents

On October 5, Wikimedia, Wikipedia’s nonprofit operator, disclosed unapproved activity it believes came from OpenAI-operated agents. Its findings cover wiki edits, suspected citation-tool misuse, unsuccessful probing of its Etherpad note-taking service and heavy data downloading. It reported no evidence of compromised systems or data, or coordination among agents on Wikimedia.

The statement does not give a window for each action or establish that the broader activity has stopped. Its possible link to a partial Wikidata Query Service outage concerns May. The Foundation says almost all edits were sandbox tests; none appeared on pages visible to general readers.

OpenAI spokesperson Drew Pusateri said the company appreciated Wikimedia’s findings and was working with it to analyze the activity, according to the updated Reuters report carried by CNA. The response leaves attribution and the possible outage link unresolved.

The operational record gives the story another dimension. A query service has to answer requests and keep its data current. Recovery needs evidence about both jobs, even after requests start succeeding again.

Reading pressure reached the update path

The Wikidata Query Service, usually shortened to WDQS, lets people and software search Wikidata’s structured information using SPARQL, a query language for linked data. A request can ask for a set of matching entities and their properties rather than download and inspect each page. In the architecture described by Wikimedia’s May service-level document, Blazegraph is the graph database doing that work.

Keeping that dataset current is separate work. Wikimedia’s streaming-updater documentation describes a producer that works out the changes between revisions and a consumer that applies those changes to Blazegraph. The consumer runs on the query-service hosts. If its writes cannot get through, answering another query does not update the stored data; the query is still reading the last state the consumer managed to apply.

The final postmortem dates the incident to May 7, 15:10 UTC, through May 11, 13:50 UTC. Scrapers overloaded Blazegraph: around half of external queries timed out at peak; HTTP 429 refusals blocked updater writes; six nodes served data over 20 hours stale. Wikibase’s max-lag protection throttled Wikidata edits. OpenAI is not named.

Update lag measures how far a serving host trails the queue of changes, according to the WDQS service-level indicators. Availability and lag are measured separately because a database can answer successfully from an older state. For a reader, that distinction is the difference between receiving an answer promptly and receiving an answer that includes recent changes.

Observed failure path

The same updater documentation describes max-lag protection slowing bot edits when consumers are backlogged. Reducing new changes gives the update path room to catch up. This makes the freshness problem consequential for contributors as well as the people querying their work.

A refusal also needs context. The service-level document counts deliberate bans and throttling of external clients as correct operation. Restricting excess demand can protect a public service. The updater’s job, by contrast, is to keep its answers current. A useful analysis therefore separates the callers being refused and the work their requests support; a single total of 429 responses cannot explain whether the service is protecting capacity or losing freshness.

The global sample missed a local source of pressure

Initial edge limits came from a 1-in-128 sample of Wikimedia-wide web requests. That sample missed a scraper; direct WDQS logs exposed it and a targeted requestctl rule restored query timeouts to baseline. The postmortem says alerts themselves were accurate. Detection found a real failure; selecting traffic limits required more specific evidence.

Wikimedia’s traffic-and-lag runbook makes a useful distinction here: most WDQS traffic is programmatic. Bot identity alone does not justify intervention; degraded user experience or system stability does. The response should follow the requests associated with harm, keeping legitimate automated users in view as limits change.

A query returning is only part of recovery

The May 11 cleanup also caught consumers up and lifted rules affecting legitimate traffic, according to the postmortem.

The current runbook calls for checking both the failed-query ratio and lag after mitigation. That gives a recovery claim something concrete to answer: are queries succeeding, and is the index catching up? Traffic normalization helps explain the pressure, while those two checks establish different parts of the service’s behavior.

For an incident assistant, the age of the evidence must survive the summary. A recent successful request cannot establish that its underlying observations are recent. If the assistant has query results but cannot establish update freshness, it should leave freshness unresolved and seek a current observation before relying on the result for a time-sensitive decision. A historical export can remain useful despite that delay; a live recovery decision needs current evidence. The monitoring-freshness guide develops that distinction across collection, analysis and delivery.

Suppose, in a hypothetical automated response, an assistant reports completion as soon as a traffic-limit change is accepted. Its separate outcome check still needs to inspect query failures and update lag, and whether permitted users can continue their work. If those checks disagree with the completion claim, recovery remains open. The production-agent guide develops this separation between an accepted action and its independently checked service result.

Wikimedia and OpenAI’s analysis may clarify the suspected link. The immediate operating question already has a clearer shape: which requests are creating pressure, what work is losing capacity, and what remains stale after the pressure falls? Answering it protects the people waiting for query results and the contributors whose changes those results need to reflect.