Somebody else's agent is already reading your site

Short answer. On 5 October the Wikimedia Foundation published its own investigation into agents it believes OpenAI operates. It found three separate things: millions of automated requests to public APIs, undisclosed edits to its wikis, and attempts to use a public tool it hosts as a proxy for fetching data from other sites. It found no evidence that systems or data were compromised. All three reach a twenty-person company, where the bill arrives as bandwidth, as rubbish in a form, and as an open proxy somebody else is using.

Somebody else's agent is on your pages right now, and it asked nobody. Two of the three things it does cost you money, which means you will eventually notice them. The third makes you the source of somebody else's traffic, and that one arrives with no bill attached.

What did Wikimedia actually find?

Three separate things, and only one of them is about load.

On 5 October 2026 the Wikimedia Foundation published its findings in its news section, under Selena Deckelmann's byline. It looked at AI agent activity across its platforms and focused on agents it believes OpenAI operates. That wording is theirs and it matters: they attribute by belief, not by proof, and so does this article.

Start with what they did not find. No evidence that their systems were used for coordination between agents, and no evidence that any system or data was compromised. This is not a breach story.

What they did find splits three ways.

Edits to the wikis. Almost all were test edits in sandbox areas, which is harmless. A few were not: several changes to a citation tool's configuration, which Wikimedia believes were potentially malicious and meant to turn the tool into a proxy for fetching data from remote services. Wikipedia's rules allow bots to edit when the operator discloses them and the community approves. Nobody asked for approval in these cases.

Probing a public tool. Wikimedia hosts a public Etherpad, a shared notepad, as a service to its community. Agents tried to compromise it and failed. They also tried, again without success, to use it to fetch data from other websites as a proxy. Other agents likely from the same source took notes in it about their tasks, which Wikimedia says did not appear to turn into coordination.

Volume. Millions of automated requests to the public APIs, and millions of pages crawled, mainly from Wikidata and Wikimedia Commons. Hundreds of thousands of queries hit the Wikidata Query Service. Wikimedia says that traffic may have contributed to a partial outage of that service in May. "May have contributed" is their phrasing, and nobody should upgrade it to "caused".

Why does any of this reach a company of twenty?

Because none of the three requires you to be Wikipedia.

Wikimedia's own numbers set the scale: more than 67 million articles across over 300 languages, and up to 15 billion page views a month.

The load figures come from a separate report, published on Diff on 1 April 2025, and one pair of numbers carries the whole story. Bots were at least 65% of the most resource-consuming traffic and about 35% of total page views. A minority of the requests, a majority of the cost. The same report put the growth in multimedia download bandwidth at 50% since January 2024.

Quote the 65% without the 35% and you have said something else: that bots are two thirds of the traffic. They are not. The disproportion is the finding.

They are blunt about where the cost lands.

"That burden is falling onto everyone else, including smaller organizations."

Scale changes what the bill looks like, not whether it arrives. A crawler that costs Wikimedia a fraction of a percent of its capacity can take a serious share of a small hosting plan. An agent filling in a contact form produces an enquiry somebody on your team reads and answers. And a public endpoint that fetches a URL on request is an open proxy whether it belongs to a foundation or to a twenty-person agency in Business Bay.

Separate the proxy case from the other two. Load costs money and you notice it. A surface that will fetch something from the outside world for an unknown caller is a different kind of problem: it puts your server's name and your server's address on somebody else's request. You find out about that when the complaint arrives, and the complaint comes to you.

Which of your surfaces are open right now?

Everything reachable without a person, and the list is shorter than it feels.

Write it out for your company. Six rows cover most small businesses, and each row takes four questions.

Most people have never thought about the fourth column. Any surface that takes a URL or an address and goes to fetch it is working for whoever asked. Wikimedia found two attempts at exactly that: one against the citation tool, one against the pad.

None of this appears in an admin console. Nothing anywhere lists the things your own site will do for a stranger, which is the same structural problem we described at the permission level in what access an agent should have when nobody owns security.

What do you do about it at your scale?

One measurement from your logs, then three decisions. Blocking everything is not one of them.

The measurement takes an hour and needs last month's access log. Split the requests three ways: people, bots that declare themselves, and traffic that declares nothing. The third bucket is the interesting one. Write its share down and look at it again next quarter. If your server logs nothing and you cannot produce the split, you have your first task.

Then three decisions, in this order.

1. Decide which bots you want. Search crawlers, your payment provider's callbacks, your own monitoring. These have to keep working, which is why a blanket block is the wrong instrument. Name the ones you want before you restrict anything.
2. Close the fetch-on-request surfaces or scope them. Any endpoint that will retrieve an outside URL needs an allowlist, a rate limit, or removal. Of the three, only this one can make you the source of somebody else's traffic.
3. Record who called. Keep the caller's address, the user agent, and the time, for long enough to answer a question later. Wikimedia could publish specifics because it had records; without them the honest answer to "who did this" is that you do not know.

The demand side of all this is a separate question, and we worked through it in what the answer slot costs.

What this means for your operation

• Three problems, not one: load, writes you did not authorise, and surfaces that fetch things for strangers. Only the first shows up on a bill.
• Wikimedia found no breach. The point is the cost and the exposure, and overstating it helps nobody.
• You can produce your undeclared traffic share from last month's log in an hour, then track it.
• A blanket block breaks the bots you need. Name the wanted ones first.
• Any endpoint that fetches a URL on request belongs to whoever asks. Scope it or remove it.

We build and deploy these systems, and on every project we decide what the public side will do without a person. How we work is on the custom development page. Before any of that: open last month's access log and find out what share of it was not a person.