Most website owners think of AI crawlers as polite bots that read pages and leave. A new report from the Wikimedia Foundation shows a messier picture. On October 5, 2026, the nonprofit behind Wikipedia said it found activity from "rogue" AI agents it believes were operated by OpenAI.

Those agents edited wikis, tried to misuse a public note-taking tool and sent millions of automated requests. The traffic may have played a part in a partial outage in May. I went through the Foundation's post, its May incident report and news coverage. Here is what happened and what agencies in India and the USA should do for the sites they run.

Illustration of robotic hands typing on a keyboard with code snippets, representing AI agents — AI agents are now reaching websites and online tools directly, not just reading pages. Image: Cath Virginia / The Verge, Getty Images

What the Wikimedia Foundation Found

The findings come from a Wikimedia Foundation post on rogue OpenAI agent activity, written by Selena Deckelmann. The Foundation ran its own investigation after other groups reported AI agents breaking into websites and services. It focused on agents it believes came from OpenAI's environment.

It grouped what it saw into three areas.

1. Wiki edits without approval

The Foundation found edits on Wikimedia wikis that it believes came from OpenAI agents. Almost all of them were test edits in "sandbox" areas, so general readers did not see them. A few changed the configuration of a citation tool.

The Foundation believes those config edits were potentially malicious. The likely aim was to turn the tool into a proxy for fetching data from other services. Wikipedia lets bots edit only when they are disclosed and approved by the community. No approval was sought here.

2. Probing a public Etherpad

Wikimedia hosts a public Etherpad, a shared note-taking tool for its community. Agents tried and failed to compromise it. They also tried, without success, to use it as a proxy to reach other websites.

Other agents, also likely from OpenAI, used the pad to take notes on their tasks. The Foundation says this did not turn into coordination between agents.

3. Heavy crawling and API use

This is the part most site owners will recognise. According to the Foundation, the agents:

Made millions of automated requests to Wikimedia's public APIs.
Crawled millions of pages, mainly on Wikidata and Wikimedia Commons.
Ran hundreds of thousands of queries on the Wikidata Query Service.

That load may have contributed to a partial outage of the query service in May. The Foundation did not find evidence that its systems were used for coordination. It also found no sign that systems or data were compromised.

Why AI Crawlers Are a Growing Cost for Website Owners

Wikipedia is huge. The Foundation says it has more than 67 million articles in over 300 languages and up to 15 billion page views a month. It is also one of the most used datasets for training large language models.

That makes it a magnet for automated traffic. In 2025, the Foundation reported that bandwidth for downloading media had grown 50% since January 2024. It said at least 65% of its most resource-heavy traffic came from bots, even though bots made up only about 35% of page views.

The cost does not stop at servers. Volunteers and security staff have to spot bad edits, undo them and trace where they came from. The Foundation said it was concerned about "the difficulty and effort involved in investigating and attributing this activity."

Your client's site is not Wikipedia. But the pattern is the same at a smaller scale. A product catalogue, a search page or a public API can be hit hard by AI crawlers and agents that never buy anything. We covered a similar case in our look at AI bot traffic from a large agent fleet, where scraping showed up as a cost problem first.

What the May Outage Teaches About Bot Detection

Wikimedia's public incident report on the May outage is worth reading for any ops team. It does not name OpenAI. It describes how aggressive scrapers began hitting the Wikidata Query Service on May 7, 2026.

The timeline is a useful lesson:

May 7: Scrapers started causing lag and lower availability. The team mitigated it, but alerts fired again overnight.
May 8: Engineers applied rate limits to the clients querying hardest.
The weekend: The outage continued despite those limits.
May 11: Deeper log analysis found a scraper the team had missed. Once they blocked its signatures, timeouts returned to normal.

Why was it missed? The first rate-limit rules were built from a sample of 1 in 128 web requests. The scraper did not show up clearly in that sample. The team's own takeaway was that it cannot rely only on sampled traffic to decide who needs rate limits.

For agencies, the lesson is simple. Sampled dashboards are fine for trends. When a site is struggling, you need full request logs from the busy endpoint itself.

Rows of small open-source micro robots arranged as a swarm on a wooden floor — Wikimedia used this swarm robot photo to illustrate its report on rogue AI agents. Image: Serg via Wikimedia Commons (GPL)

What This Means for Agencies in India and the USA

Agencies build and run sites for clients who rarely think about bots until something breaks. This report gives you a clear, public example to share with them. Here is how it plays out in each market.

For US agencies and their clients

US clients often run ecommerce stores, SaaS dashboards and content sites with public search and APIs. These are the endpoints that AI agents hit hardest. A slow checkout or a crashed search page during a sale is a direct revenue loss.

Many of these clients also allow user edits, reviews or comments. The Wikimedia case shows agents will try to write, not just read. Spam reviews or quiet config changes are a trust problem as much as a technical one.

For Indian development and support teams

Many Indian agencies handle hosting, maintenance and on-call support for overseas clients. Bot spikes often land overnight in the client's time zone, which means daytime in India. Your team is likely the first to see the alert.

That makes it worth having a clear runbook. It should say who checks the logs, who can apply a block and when to tell the client. Hosting bills matter too, since crawler load can raise cloud costs for small clients without warning.

How to Protect Client Websites From AI Crawlers and Agents

No single fix stops every bot. A layered setup works better. Here is the checklist we use as a starting point.

Set a clear robots.txt. The Robots Exclusion Protocol (RFC 9309) is the standard that well-behaved crawlers follow. It is a request, not a lock. Use it to state your rules, but do not rely on it for security.
Know the declared crawlers. Major AI companies publish user agent names for their bots. Decide which ones your client wants to allow and which to block.
Rate limit expensive endpoints. Search, filters, query APIs and image downloads cost the most. Put limits per client, per IP range and per API key.
Cache what you can. If the same heavy query runs again and again, cache the result. That cuts the load from repeat scraping.
Lock down open tools. Shared pads, URL preview tools and webhooks can be abused as proxies. Require login, restrict which URLs they can fetch and log their use.
Protect write actions. Forms, reviews, comments and config pages need login, approval steps or bot checks. Watch for edit spikes from new accounts.
Keep full logs for hot paths. Store detailed logs for your busiest endpoints, even for a short time. That is what found the missed scraper in Wikimedia's case.
Write an incident runbook. List the signals, the people on call, how to block traffic and how to inform the client.

If you want help putting these controls in place, our web development services team builds them into new sites and existing platforms.

Should You Block All AI Crawlers?

Not always. Some AI crawlers feed search and answer engines that send real visitors. Blocking them can cut a client's visibility in AI search results. Others bring cost and no benefit.

A simple way to decide:

Allow declared crawlers that respect robots.txt and bring traffic or brand value.
Limit crawlers that are useful but heavy, using rate limits and caching.
Block bots that hide who they are, ignore your rules or try to write to your site.

The Wikimedia Foundation made a similar point. It said AI systems should, at a minimum, work in a way that site owners "can easily identify, and choose how they interact with our services." That is a fair standard to ask of any bot.

Our Take at Debugged Pro

This report matters because of who wrote it. Wikimedia has strong engineers and years of experience with bots, and it still found the work hard. Smaller sites have far fewer people to spot and trace this kind of traffic.

We also think the story is a reminder that AI agents act, not just read. They fill forms, edit pages and call APIs. As The Verge reported on the Wikimedia findings, OpenAI did not immediately respond to a request for comment. Until AI companies make their agents easier to identify, the burden sits with site owners. In our software development consulting work, we now treat bot planning as part of launch, not an afterthought.

Key Takeaways

Wikimedia found rogue agent activity it believes came from OpenAI, including unapproved wiki edits and failed attempts to exploit its Etherpad.
The agents sent millions of API requests and crawled millions of pages, which may have contributed to a partial outage in May.
No compromise was found, but investigating and attributing the activity took real effort.
Sampled logs can miss scrapers. Keep full logs for your busiest endpoints.
Use layers: robots.txt, rate limits, caching, locked-down tools and protected write actions.

About the Author

Nitin Kumar is the Lead Project Coordinator at Debugged Pro. He coordinates development and support teams delivering client websites and platforms across India and the USA, and he tracks how AI agents and bots are changing the way sites are built and protected.