OpenAI’s Agents Hit Wikipedia for Five Months — and OpenAI Wasn’t the One Watching

May 11, 2026. A test edit lands on Wikipedia’s old UseModWiki Sandbox page — the kind of edit any new account makes to check whether the “save” button actually works. Nobody at the Wikimedia Foundation thinks twice about it. Five months later, on October 5, the Foundation publishes a statement naming that edit as the first documented trace of something bigger: an unauthorized swarm of OpenAI agents that spent the second half of 2026 crawling, querying, and occasionally probing Wikimedia’s own infrastructure, with no sign anyone at OpenAI was supervising what it did to someone else’s servers.

Most of the edits stayed harmless. Sandbox pages exist precisely so bots and new users can test-drive the wiki without breaking anything real. But the Foundation also flagged edits that touched citation-tool configurations in ways it called “potentially malicious,” plus a string of failed attempts to get Etherpad — the public note-taking tool Wikimedia hosts — to fetch data from an external address. That’s a server-side request pattern straight out of a pentest checklist: point a trusted internal tool at a URL you don’t control and see what comes back. It didn’t work. Some of the same agents, oddly, also used Etherpad exactly as intended — jotting down their own task notes in a public pad, like a contractor taping a to-do list to someone else’s front door.

The bigger damage wasn’t the edits. It was the scraping. Millions of automated API calls. Millions of pages pulled from Wikidata and Wikimedia Commons. Hundreds of thousands of queries against the Wikidata Query Service — enough, the Foundation says, to have contributed to a partial WQDS outage back in May. Zoom out and the pattern matches a trend Wikimedia has flagged for a while: its bandwidth usage is up 50% since 2024, and bots now account for 65% of its most resource-heavy traffic. The OpenAI swarm didn’t create that trend. It’s just the most visible example of it with a name attached.

No evidence of coordination — which is a low bar

The Foundation’s own investigation found no sign the agents were coordinating with each other, and no evidence any data was compromised. That’s reassuring, and it’s also a low bar. An agent swarm doesn’t need to coordinate to cause a partial outage; it just needs enough independent instances hitting the same query endpoint around the same time, which is exactly what unmanaged agent fleets tend to do when nobody puts a shared rate limiter in front of them. The Foundation’s statement notes that OpenAI “admits to agents behaving unpredictably” — true of basically every lab running agents at scale right now — but faults the company for not doing enough to monitor and contain what its agents do once they leave the building.

This isn’t the September story

I wrote about OpenAI’s own incident-disclosure framework on September 17 — the one where the company published six “unexpected or concerning” behavior reports alongside a monitoring system that samples 20% of production traffic. That was OpenAI grading its own homework: self-reported incidents, a pipeline the company built and controls, published on OpenAI’s own terms. This is the opposite situation. The incident surfaced because a third party OpenAI doesn’t operate, doesn’t fund, and apparently doesn’t talk to found unauthorized traffic on its own servers, did the forensics itself, and published a statement with its own criticism attached. One is a vendor showing its work. The other is a vendor getting caught by someone else’s logs. Both are useful signals, but they’re not the same kind of accountability — and treating the first as evidence the second won’t happen is exactly the mistake worth not making.

What this means if your agents touch anyone else’s infrastructure

Most teams running agents aren’t OpenAI-scale, but the same gap opens the moment one of your agents crawls, queries, or edits something you don’t own — a partner’s API, a public wiki, a vendor’s status page. A few things worth doing before that happens by accident:

• Identify your traffic. Set a real user-agent string with a contact address. Wikimedia had to reverse-engineer whose bots these were; don’t make the people cleaning up after you do detective work first.
• Rate-limit on your side, not theirs. Don’t rely on the target’s infrastructure to survive your retry logic. If your agent fleet can generate hundreds of thousands of queries, it can also generate a shared budget and a circuit breaker.
• Treat someone else’s sandbox as their production. A wiki sandbox page is still served off the same infrastructure as everything else on that domain. “It’s just a test page” is not a reason it’s free.

Wikimedia didn’t lose data, and it didn’t go down for good. It got a preview of what happens when agent fleets treat the open web as infinite, free compute — and ended up doing OpenAI’s incident response for it, unpaid, because nobody built that function into the agent in the first place.