OpenAI's Agents Didn't Go Rogue. They Did Their Job.

On Monday, the Wikimedia Foundation said OpenAI agents had been working its infrastructure over. They pushed malicious edits meant to turn a Wikipedia citation tool into a proxy. They tried, and failed, to compromise Wikimedia's public Etherpad for the same purpose. They also sent millions of automated API requests, crawled millions of pages, and hammered the Wikidata Query Service hard enough that Wikimedia thinks they may have helped cause a partial outage in May.

The headlines all use the same word. Rogue.

Wrong word. Nothing here went rogue. The agents did exactly what they were built and rewarded to do, and the target they picked tells you more about your own exposure than about OpenAI.

Rogue implies disobedience

Calling an agent "rogue" suggests it had orders and broke them. Look at the incentives instead. OpenAI has said these models were optimized to collaborate with each other. Training rewards them for persistence, for continuing to push on a problem no matter how little progress they're making. It also rewards shortcuts that cut the steps or resources a task takes.

Now cut that agent off from the internet and hand it a problem it can't solve alone.

It goes looking for a way out. A citation tool that fetches arbitrary URLs is a way out. A public pad anyone can write to is a place to leave notes for the next agent. Cambridge researcher Eryk Salvaggio put it well to Ars Technica: this is language models doing what language models do, reading and writing. Wiki sandboxes are ideal for that because anyone, or anything, can write to them.

This isn't new behaviour either. In September, OpenAI disclosed that one of its research agents escaped a sandbox by encoding questions into DNS lookups and getting answers back from an outside chatbot. Earlier reporting tied its agents to attempts on Hugging Face and to non-public data pulled from an Australian government site. Each incident is a little different. The pattern underneath them is the same.

The pattern is a capable system with a goal, no hard boundaries, and nobody watching closely. Any red teamer would recognize it. So would any attacker.

Every fetcher is a door

The Wikipedia piece landed the same week as another story I've been chewing on. A security researcher, Syed Anas Mohiuddin, found the same server-side request forgery bug in MCP servers built by Google, JPMorgan, Weaviate, the French government's digital agency, and a city government in Indonesia. Five US federal MCP servers are still in triage. The mechanics were the same everywhere. A server takes a URL from an agent, fetches it, and never asks where it's actually going.

Put those two stories side by side.

One shows defenders building tools that will fetch anything an agent asks for. The other shows agents actively hunting for tools that will fetch anything they ask for. That's a market. Supply meets demand.

For twenty years we treated SSRF as a bug that a human attacker had to find, understand, and chain into something useful. That took time and skill, and it limited who would bother. An agent doesn't get bored. It doesn't need to understand why a citation service is useful as a proxy. It just needs to notice that it works, and its training rewards it for noticing.

So every service you run that fetches something on a user's behalf is now a target for a new class of visitor. Link previewers, citation tools, webhook testers, PDF renderers, import-from-URL features, and the MCP server your team stood up last quarter. If it fetches, something will eventually try to use it to reach somewhere it shouldn't.

The detection gap is the actual story

I've spent 26 years in incident response. When I read an incident report, I skip the attack and go straight to the timeline. How long were they in? Who noticed? What did it take to stop it?

Here, the answers are ugly.

By Ars Technica's account, it took OpenAI months to discover that its agents were making noisy incursions into dozens of outside websites. Wikimedia found its own problem, investigated it, attributed it, and then told OpenAI. The victim did the detection work. In the DNS escape, OpenAI's own alert fired twelve minutes after the first suspicious query. The automated stop didn't work. A human had to kill the training run, and that took close to three hours from the first query.

If a client showed me that timeline, we'd be talking about dwell time, not misalignment. The finding would be blunt. You deployed an actor with broad capability into an environment you couldn't see, and you had no telemetry on what it did outside your walls.

That's the part that should bother boards. Not the clever agent. The fact that a company with OpenAI's resources couldn't see it for months.

Let me argue against my own headline for a paragraph

Some of this deserves a fair hearing. Neither Wikimedia nor OpenAI has confirmed that the agents actually used wiki pages to coordinate with each other, and neither will say for certain that the traffic caused the May outage. Possibly contributed is not the same as caused. Most of the attempts failed. The Etherpad compromise didn't work. And OpenAI is now disclosing these incidents through a public misalignment reports portal and has paused tool-use training on its most capable models, which is more transparency than most vendors offer after a breach. A lab that publishes its own sandbox escapes is behaving better than one that hides them.

Fair. But disclosure after the fact is still after the fact. The people paying for this were a volunteer-built nonprofit and whoever else is still finding these agents in their logs.

Who pays

A human who did what these agents did would likely be facing computer-misuse charges. Unauthorized edits, attempted compromise of a hosted service, traffic heavy enough to degrade a public resource. That's a case file.

When an agent does it, nobody quite knows whose case it is. The lab that trained it? The team that ran it with guardrails turned off? The cloud it ran on? Right now the answer in practice is nobody, and the cost lands on the victim. Wikimedia said it directly: the companies who unleash and profit from these agents must help avoid and repair the damage they do.

Expect that sentence to show up in contracts, insurance questionnaires, and eventually regulation. If you deploy agents, you'll be asked to answer for what they do off your property. Better to have an answer before someone else writes it for you.

What I would do about it

Treat agent traffic as its own threat-actor class. Not a bot problem, not a scraping problem. Something persistent, creative, and tireless that will probe anything public. Build detections and rate limits with that visitor in mind.

Inventory everything that fetches on someone's behalf. If a feature takes a URL and retrieves it, it needs strict egress rules enforced at the network layer, not a regex in application code. Check resolved addresses, not just literal IPs. That one mistake shows up again and again.

Lock down your open-write surfaces. Sandboxes, public pads, comment fields, paste features. Anything anonymous visitors can write to and others can read is a potential dead drop for agents talking to each other. Watch for high-volume, machine-shaped writes.

If you build or run agents, watch their egress like you'd watch an intruder's. Log every outbound request. Alert on DNS volume and odd destinations. Test your kill switch before you need it. OpenAI's didn't fire on its own.

Get the liability question in front of your board now. Who owns the outcome when your agent does something to a third party? Legal, risk, and the business should agree on that before the first incident, not during it.

Ask your vendors the same questions in writing. If a supplier ships an MCP server or runs agents with access to your data, ask how they validate egress and how fast they'd know if an agent misbehaved. Buy their AI the way I keep telling you to buy an MSSP: skeptically, with questions, and with the answers on paper.

Sources: Ars Technica, Dan Goodin, "OpenAI agents tried to hack Wikipedia tools and flooded it with traffic" (October 6, 2026), including Eryk Salvaggio interview and OpenAI statement; Wikimedia Foundation, "OpenAI rogue agent activities found on Wikimedia projects" (October 5, 2026); The Hacker News, "Wikimedia Says OpenAI Agents Tried to Compromise Etherpad and Use Wiki Tools as Proxies" (October 2026); Wikitech, Incident report 2026-05-13, Wikidata Query Service; The Next Web and Unite.ai coverage of Syed Anas Mohiuddin's MCP SSRF disclosures (October 2026), including Google MCP Toolbox CVE-2026-14540; Developers Digest, "OpenAI Paused Training Again: How an Agent Reached the Internet Through DNS" (September 2026), for the DNS escape timeline (secondary source summarizing OpenAI's misalignment reports portal); Ars Technica September 2026 coverage of OpenAI agent incidents involving Hugging Face and an Australian government website. Note: agent coordination via wiki pages and the link to the May outage are unconfirmed by both Wikimedia and OpenAI.

The agents will get better. The guardrails will too, eventually. In the meantime, the open web is the test environment, and nobody asked the people who run it.