News

The agents left each other notes on a 25-year-old wiki

On September 4, four researchers published about 18,000 wiki posts written by autonomous agents that identified themselves as OpenAI systems. The agents were running a timed web-lookup task with read access to the internet and no write access. They found a dormant German wiki they could edit anyway, and used it to pass each other answers and instructions for getting around their own network restrictions. OpenAI confirmed the episode the next day.

What the logs show

The site is DSE wiki, a sub-wiki of the German ProWiki farm. It is 25 years old and had been edited 20 times in the previous decade, which is roughly the traffic profile of an abandoned building. Sydney Von Arx of the Nightingale Collective, Cormac Slade Byrd, Spencer Kitts and Thomas Larsen reconstructed the deleted pages from edit history and published the whole dump with a data explorer.

The first edit attempts show up on May 11 against a different test wiki. The first successful DSE write lands on May 24, and at that point the agents are only posting lists of useful external links. Activity jumps on June 16, when they start addressing each other directly and pooling results on their tests. On June 19 an agent works out that the site administrator is deleting pages in alphabetical order, so it creates a backup page named starting with ZZZ to buy itself time. That one detail is the part I keep rereading.

The following day an agent posts a technique for getting past OpenAI's sandbox network limits. Another agent reports running it successfully 14 minutes later. OpenAI-linked IP addresses appear in the logs on June 21, and the editing stops the day after.

Blocked is not the same as impossible

Nobody gave these agents a write channel. They were handed read access and a deadline, and the read path turned out to be enough. The researchers are explicit that this is separate from the July incident where OpenAI models exploited an internally hosted JFrog Artifactory instance, gained internet access through a server-side request forgery, and reached parts of Hugging Face's production systems. Different mechanism, same shape: a component that was trusted to only do one thing did a second thing.

OpenAI called that July episode a warning shot in its August 26 report, and the response it described is mostly operational rather than clever. More isolated sandboxes. Tighter control over model weights. Chain-of-thought monitoring wired to alerts that page a human, with responders expected to pause the run if they cannot rule out a real problem within 30 minutes. Those are incident-response habits, not model improvements.

The wiki case is cheaper to reason about than the Artifactory one and worse in a way. No vulnerability was needed. The agents just noticed that the world outside the sandbox had a writable surface on it.

OpenAI's answer so far

On September 5 OpenAI posted that it had treated misalignment mainly as a research question communicated through papers and system cards, and that this year misalignment started causing real-world impact. It said the industry has no clear standard for reporting behaviour that shows up in training and evaluation without looking like a security breach, that it is building a framework, and that it will publish it in the coming weeks while working with dozens of government regulators.

Worth noting the order of events. The researchers published on September 4. OpenAI's acknowledgement came on September 5. The company says it considered the wiki activity an instance of misalignment similar to ones it had already shared, which may well be true, and it also means the public account arrived from outside the company first. A framework that exists in a few weeks is not a framework that existed in June.

How this changes what we ship

We run agents on client repositories every day, so the practical question is which of our own components would trust something an agent wrote. The answer is never zero. A test runner executes files in the workspace. A CI job reads a config the agent can edit. A deploy step trusts a lockfile. When we scope an agent we now write down the write set and then check what reads from it, because the boundary that matters is not the process, it is the trust downstream of the process.

The other change is duller. Egress allowlists on agent containers instead of denylists, so a new destination fails closed rather than opening quietly. Logs of every outbound request the agent makes, retained long enough to answer a question in August about something that happened in May. Neither is exciting to build and both would have caught this in a week rather than four months.

Sources

Have a stack outgrowing itself?

Book a call and we'll walk you through how we'd approach your platform, priced fairly and estimated for real.