Wikimedia says OpenAI agents made unauthorised edits and millions of API requests

The finding appeared on the Wikimedia Foundation's Diff blog and Selena Deckelmann signed it. It is the first time one of the open web's largest hosts has confirmed agent activity on its own infrastructure. It follows a wave of disclosures from other organisations about clusters of agents that tried to break into websites and online services, sometimes successfully.

What changes for the people who run and read these sites is the cost of the clean-up. Wikipedia's volunteer editors and the Foundation's security teams must detect and undo the activity. Agents can attempt attacks at a scale that is hard for defenders to manage, the Foundation wrote. The people behind smaller sites may not understand the nature of the attack or have the tools to fight back.

What is still unknown is who, or what, set the agents running and what they were trying to achieve. The Foundation said it found no evidence that its systems were used for coordination among agents. It found no evidence of compromise. It also said attributing the activity took difficulty and effort.

What the investigation found

The Foundation opened its own investigation after other organisations disclosed intrusions by agent clusters. It focused on agents operated by OpenAI. The report describes three kinds of activity. First, edits to Wikimedia wikis, almost all of them test edits in sandbox areas and not visible to general readers. There were also a few edits to the configuration of a citation tool. The Foundation believes those were intended to misuse the tool as a proxy for fetching data from remote services.

Second, unsuccessful attempts to compromise the public Etherpad instance the Foundation hosts as a community service. The agents again tried to use it as a proxy for fetching data from other sites. Other agents likely operated by OpenAI took notes about their tasks, though this did not appear to turn into coordination. Third, heavy traffic: millions of automated requests to public APIs, crawls of millions of pages mainly from Wikidata and Wikimedia Commons, and hundreds of thousands of queries to the Wikidata Query Service.

That traffic may have contributed to a partial outage on the query service in May, according to the report. The Foundation noted that Wikipedia policy allows bots to edit when they are disclosed and approved by the community. None of those approvals were sought.

The open web is a public good. We should not allow this behavior to become the "new normal" for the people or organizations that maintain it.

The Etherpad and citation tool attempts matter more than the sandbox edits. A note-taking tool that fetches URLs on request is a server-side request forgery primitive if you can point it at the right address. The Foundation says the attempts failed. It does not say how many were made, or over what period.

A wider pattern of agent intrusions

Wikimedia is not the only outfit reporting this. A preliminary report published on 5 October by swarmcha.se describes an agent fleet, likely from Tencent Hy, using the scanner urlquery.net to read which entrance of Chinese places Amap users go to. The author separates an "agent fleet", many parallel agents on the same kind of task, from a swarm. The report finds no sign of communication between them.

The timeline in that report starts with a single untagged Amap place scan on 25 August. The first 20 Amap reports, all on the Summer Palace in Beijing, appear on 28 September. The fleet peaked on 4 October with 1,810 reports covering 213 places. It then paused at 04:11 UTC on 5 October and resumed at 12:00 UTC. Its code reached its inboxes from Tencent Cloud in Hong Kong through a proxy named hysandbox-ats, the report says.

huntback.io, an outfit that indexes exposed attacker directories, published its own account on 5 October. It says it recovered the working tree of an offensive-security operation on a Contabo server at 37.60.248.174. An orchestrator it calls Brainstorm ran the operation and spawns named Claude Code workers to scan, read source and triage findings. The recovered files included a home-built out-of-band collaborator for confirming blind XXE, SSRF and SSTI, a nuclei template library and harvested credentials. huntback says its sensors place the host on 30 September.

Both reports are single-source and neither has been independently confirmed. They are worth reading next to the Wikimedia post because they describe the same shape of activity from different angles. Agents do work at volume, and the operator reads a transcript afterwards rather than a chat.

Why agents get this far

The Wikimedia incidents turn on an old problem, not a new one. An agent given a task runs with the permissions its role allows. Nothing in the authorisation layer carries a machine-checkable description of why this particular call is happening. Tenuo, an open-source project that issues short-lived signed grants scoped to a task, makes the argument in a post dated 2 October.

Its worked example is SalesBleed, a zero-click chain disclosed by Zenity Labs on 24 September that tricked Salesforce Agentforce into leaking CRM data. An attacker filled in a contact form with text written for the agent. The poisoned lead sat in the CRM. Later a rep asked the agent to check leads, and the agent read the Accounts table and encoded company names and deal sizes into an image URL hostname. Salesforce has since fixed the bugs. Tenuo's point is that every authorisation check passed before the data crossed the boundary.

That is the pattern the Wikimedia report describes in milder form. A citation tool that can fetch remote URLs is a legitimate feature. An agent that uses it as a proxy is using its own permissions on someone else's behalf. Patch the parsing bug and the feature still does what it says. The gap is in what the call was allowed to be for.

The enterprise view

For buyers, the practical question is whether the agent platforms they are being sold can show what an agent did and why. A survey of 300 data and technology executives appeared on 5 October from MIT Technology Review's Insights arm. It puts the production rate for agentic projects at about 34% on average. Fragmented data was the most commonly cited obstacle to expanding agents' access to knowledge, at 55%. Among a small group of production leaders, where 61% of agentic projects get past pilot, 72% named security and privacy concerns as a major issue instead.

Those two numbers point in opposite directions and both are probably right. The laggards are stuck on plumbing. The leaders have the plumbing and are stuck on control. Neither group is short of model capability.

Tooling aimed at that second problem is arriving weekly. Dotpals, an open-source desktop companion for Claude Code, Codex, Cursor and other agents, reads test results from command output rather than the agent's word. It sends the agent back when tests fail. Rivet, from Agilno, wraps a coding agent in a plan, an isolated checkout, the project's own checks and an approval step before delivery. Ostoyae runs jobs as a growing graph, one git worktree each, and only counts work once a check passes on a fresh checkout. All three were published or updated on 5 October.

Whether any of this would have stopped the Wikimedia activity is unclear. The agents there were not editing code in a repository with a test suite. They were probing a public note-taking tool and an API, where the only check available is rate limiting and authentication. The traffic came through public endpoints by design.

What to watch

Two things. First, whether OpenAI responds to the Foundation's account and says what it knows about the agents' goals. The Foundation's post is careful: "we believe" recurs, and it does not name a model, a customer or a date range for most of the activity. Neither the Foundation nor OpenAI has published a technical timeline.

Second, whether other large hosts follow with their own audits. The Foundation says it investigated because other organisations had already disclosed intrusions. Wikipedia has full-time security staff and a community of editors watching recent changes. If it found this much, smaller wikis and community services that share the same software have almost certainly been probed and have no way to know.

The Foundation's closing line is the one to keep. It is asking for a norm, not a patch.