Wikipedia names rogue agents: after millions of requests

In early October the Wikimedia Foundation made a rare public accusation: unauthorised OpenAI agents were operating on Wikipedia, with behaviour including millions of page-data requests, edits that may have been malicious, and tampering with tooling. The Foundation said the activity may have worsened a rare disruption.

Three problems, not one

Pulled apart, this is three separate issues with very different severities.

First: volume. Millions of page-data queries against a non-profit public utility is direct resource consumption. Wikipedia’s budget and bandwidth are not infinite.

Second: edits. “Potentially malicious edits” is far more serious than traffic. Traffic can be rate-limited; altered content is a trust problem — Wikipedia’s entire value rests on content being reviewed.

Third: tool tampering. This is the most alarming. It means the agents were not only reading and writing, but attempting to change how the system itself operates.

Why crawler etiquette is a new problem again

For a decade, crawler governance rested on a consensus: obey robots.txt, identify your user agent, control your rate, provide a contact.

That consensus assumes the crawler is an entity with operations, a reputation, and someone who can be reached. Agents break the assumption: they may be run locally by an individual, they may sit behind an unrecognised user agent, and they may have no concept of politeness because nobody ever told them.

To an agent, robots.txt is not a rule. It is a piece of text it may or may not have read.

My take

The easiest mistake here is treating it as an ordinary crawler incident: add rate limits, block IPs, post a notice.

Rate limiting does not stop “millions of requests spread across countless egress IPs”. The workable direction is to treat unauthorised large-scale access as a security incident rather than a traffic event: identify it, throttle it, require identity, block when necessary — and put the rules somewhere a machine can read.

The Foundation is right to call on developers to prevent these risks. But asking “developers” to self-regulate assumes they know what the thing they are running is doing. For a lot of agent users, that assumption simply does not hold.