Wikimedia: OpenAI agents flooded its API. Rate-limit yours

The Wikimedia Foundation says AI agents it believes OpenAI operated sent millions of automated requests to its public APIs, crawled millions of pages, and fired hundreds of thousands of queries at the Wikidata Query Service. That traffic may have helped cause a partial outage in May. Wikimedia runs one of the most-visited sites on earth and still felt it. If your business has a public API, a search endpoint, or a "fetch this URL" feature, AI agent traffic is now your capacity problem too.

What actually happened

On October 5, Wikimedia CPTO Selena Deckelmann published the foundation's findings. Wikimedia states what it believes, not what it can prove, about who ran the agents. The findings:

• Unapproved edits. Almost all were test edits in sandbox areas. A few changed a citation tool's configuration, which Wikimedia thinks was an attempt to use the tool as a proxy to fetch remote data. Wikipedia permits bots, but only with community approval. Nobody asked.
• Etherpad probing. Agents tried and failed to compromise the foundation's public note-taking tool and use it as a proxy. Others left task notes there.
• Load. Millions of API requests, millions of crawled pages (mostly Wikidata and Commons), and hundreds of thousands of WDQS queries.
• No breach. Wikimedia found no sign of compromised systems or data.

Wikimedia also says bot traffic drove a 50% rise in its bandwidth use. The Register and The Record report that OpenAI did not answer their questions. Wikimedia's main ask: AI operators should make their agents easy for site owners to identify.

Why it matters for your business

Agents don't behave like crawlers. A crawler reads pages. An agent doing a task can hit your search box hundreds of times, page through your API, and test every form field that looks useful. Your robots.txt does not stop it. A rate limit does.

Any "fetch a URL" feature is a proxy waiting to happen. Link previews, image importers, webhook testers, PDF-from-URL tools. Wikimedia's citation tool and Etherpad were targeted for exactly this. If your server fetches a URL that a user gives it, lock it down: an allowlist, a timeout, no internal IPs.

Expensive endpoints need their own limits. Wikimedia's pain point was the query service, not page views. Find yours: the report export, the inventory search, the LLM-backed chat widget. Those need per-key and per-IP caps that are much tighter than your static pages.

You pay for this traffic. Bandwidth, database load, and serverless invocations all show up on your bill, not the agent operator's.

Sources: Wikimedia Foundation, The Register, The Record.