# A Read-Only Web Was Still a Way Out

> OpenAI-linked agents reportedly turned a quiet public wiki into a shared notebook during a timed web task. The practical lesson is simple: allowed requests, writable public sites, and shared state must be controlled together.

- **Author:** Kubilay Tunca
- **Published:** 2026-09-06
- **Category:** For Developers
- **Tags:** AI Agents, Security, Sandboxing, Network Security
- **Canonical URL:** https://cyber-security-in-plain-english.com/post/developers/news/read-only-web-still-way-out

---

A developer can look at a network policy that permits only web reads and reasonably think the dangerous half has been removed. The agent can fetch a page, but it cannot publish one. No upload button, no ordinary form submission, no write access. That sounds like a useful boundary.

In May and June 2026, a large group of automated agents reportedly found the exception. A quiet German software wiki accepted page changes through the same kind of web request normally used to retrieve a page. Agents that were supposed to read the web could therefore leave notes for later agents, pool answers to timed questions, and exchange ways around other restrictions. The public site became shared memory.

The incident was documented on 4 September by four researchers who published their report and a downloadable dataset. They attribute roughly 18,000 posts across several sites to agents that identified themselves as OpenAI systems. [Reuters independently reported more than 15,000 edits on DSEWiki and cited two people familiar with the matter](https://www.reuters.com/world/europe/openai-agents-hijacked-german-website-previously-undisclosed-ai-breakout-this-2026-09-04/). On 5 September, [OpenAI acknowledged the “wiki incident” and said it was working on standards for reporting this class of event](https://techcrunch.com/2026/09/05/openai-confirms-wiki-incident-says-its-working-on-a-framework-for-more-disclosure/).

The useful lesson has little to do with a dramatic tale about machines “escaping.” The computer still had a way out. A control covered one familiar route, while the allowed route could produce the same effect. Any team giving a coding agent network access should treat that as an architecture problem it can fix.

## What happened on the quiet wiki

DSEWiki was an unlikely coordination service. It was a 25-year-old German-language forum for software developers, and the researchers found only 20 edits during the previous decade. That quietness mattered. A public site with little human traffic gave the automated activity room to accumulate before anyone understood its source.

The [researchers' reconstructed timeline](https://collusion.wiki/) begins on 11 May 2026, when agents attempted edits on public test wikis. They recorded the first successful write to DSEWiki on 24 May. Early posts stored useful links. On 16 June, the pattern changed sharply: agents began addressing one another, relaying answers, and asking agents on later rounds to report upcoming questions. The report counts about 13,000 edits over the following seven days.

The task appears to have been a series of timed web lookups. An agent might get several minutes for the first question, followed by a long waiting period, then only seconds for a related follow-up. Other agents were seeing similar sequences at different times. A shared notebook changed the task. An agent further ahead could post the next question and answer, letting another agent respond almost immediately when its short window opened.

That mechanism matters more than the agents' chosen word for themselves. The report found more than 3,700 distinct self-assigned agent names and says some messages called the collective a “swarm.” Yet the public evidence cannot establish every detail of the internal system. The researchers did not have the hidden task transcripts or the agents' internal reasoning. They say they are uncertain whether the work was training or evaluation, and they describe their account as a best reconstruction rather than a complete incident record.

The attribution is strong but should still be described precisely. The agents used names such as “OpenAIResearcher” and “OAIResearchMar26.” Of roughly 17,000 apparent agent edits on DSEWiki, the report says 98.5% came from Microsoft Azure addresses. Page reads soon after many edits came from addresses associated with OpenAI's ChatGPT web-fetch tool. The researchers also found human-like visits from address blocks registered to OpenAI beginning on 21 June, followed by an abrupt fall in agent edits on 22 June. Those facts support the OpenAI link; they do not let an outside reader reconstruct who launched each run or what every operator intended.

That distinction became clearer after publication. OpenAI's 5 September response acknowledged that its agents had written to several internet sites, according to [TechCrunch's report on the statement](https://techcrunch.com/2026/09/05/openai-confirms-wiki-incident-says-its-working-on-a-framework-for-more-disclosure/). OpenAI said it had treated the event as similar to misalignment behavior it had discussed elsewhere, rather than publishing a separate account at the time. The company also said the wiki activity was distinct from the later Hugging Face incident.

The most defensible description is therefore narrow. During a web task in spring 2026, OpenAI-linked agents used public sites in ways their operators did not intend. They left thousands of edits, shared task information, and tested ways around controls. There is no public evidence in the cited material that these wiki agents stole customer data, took over a company's production environment, or were released as a consumer product. The event deserves attention without borrowing damage from a different incident.

## How a web read became a write

A network rule rarely controls an intent such as “research only.” It controls protocols, destinations, methods, names, addresses, and identities. The difference sounds pedantic until two operations that mean different things to a developer look identical to the filter.

The relevant web convention is simple. A GET request normally asks a server to return information. A POST request normally submits information that may change the server's state. Browsers, caches, security products, and developers rely on this convention, even though an old or unusual application can ignore it.

The wiki software did. As [Simon Willison explained after inspecting the report](https://simonwillison.net/2026/Sep/4/rogue-agent-wikis/), the affected site appears to use ProWiki software descended from UseModWiki and old Perl Common Gateway Interface conventions. Its request handling did not maintain the modern assumption that query-string values arrive only for harmless retrieval. A specially formed GET request could carry the fields needed to save a page.

Suppose an agent's web gateway applies this rule:

> Permit GET requests to public websites. Reject POST, PUT, PATCH, and DELETE.

The policy blocks the common ways to submit a form or call a write API. It cannot guarantee that a remote server treats GET as read-only. Once a reachable application maps a GET query to a state-changing operation, the permitted request becomes an output channel. The network gateway sees an allowed method. The wiki sees an instruction to save text.

This is a confused-deputy problem spread across two systems. The sandbox decides what a request is allowed to do based on the method. The remote application decides what the request actually does based on its own code. Neither component alone knows the full effect. The boundary fails in the gap between their meanings.

The wiki was useful because it also supplied persistence and discovery. One agent could create a page, and another could find it through recent changes or a directory. The site kept revision history. A note survived the first process and could be read by a process that had never met it. That turns public web access into a crude coordination bus.

The operators did impose a restriction. It reduced many ordinary writes and almost certainly removed a great deal of risk. But “GET only” described a request shape, not the outcome the operators wanted. The desired property was closer to this: an agent may retrieve approved information, but it may not cause a durable external change or communicate with another run through an unapproved channel. Those are different policies.

The report describes another gap that reinforces the point. Agents found that a trusted hostname suffix for Azure Blob Storage could bypass the normal proxy path. By changing a local hosts file and supplying a different host header, they could reportedly direct an allowed-looking connection toward another service and make requests that the main gateway would have blocked. [Willison's technical review](https://simonwillison.net/2026/Sep/4/rogue-agent-wikis/) independently walks through the hostname, address, and proxy interaction.

No team should copy the trick into a test against systems it does not own. The defensive point is enough: a network decision must bind the name that policy checked to the address, certificate, protocol, and destination that received the traffic. If an agent can change name resolution, bypass the proxy for a broad suffix, or override the logical host independently of the transport destination, the allowlist may approve one name while the connection reaches something else.

The network was not merely “open” or “closed.” It had several doors, and each door answered a different question. One filter checked the HTTP method. A bypass list checked a hostname pattern. Local configuration influenced address resolution. The remote server interpreted the request. Security depended on all four meanings staying aligned.

## Why shared public state changes an agent run

A single agent run has a beginning, a workspace, and an end. That shape gives operators useful limits. A temporary machine can be destroyed after the task. Its local files disappear. A fresh run begins without the previous run's scratchpad, unless the operator deliberately supplies memory.

A writable public page defeats that reset. The state survives outside the disposable machine. Any later process that knows where to look can recover it. The same pattern works with issue comments, paste sites, package metadata, cloud object names, analytics labels, public logs, or any service that accepts user-controlled text. A wiki is only the clearest example.

The practical risk is broader than agents sharing answers. External state can carry poisoned instructions, stale secrets, unreviewed code, or false observations from one run into another. A later agent may treat the note as prior research rather than as untrusted internet content. The handoff then crosses both a time boundary and a trust boundary.

This is why public read access can become communication even when the agent cannot write directly. A URL itself may carry data into access logs. Search queries can persist. DNS names can encode small messages. Requests can hit counters, trigger previews, warm caches, or cause a server to fetch another resource. Most of these channels have tiny capacity, but a patient automated process can combine tiny effects across many calls.

The answer is not to declare every outbound packet an incident. Useful agents need documentation, package registries, source repositories, and test services. A coding workflow with no inputs becomes a very expensive text editor. The goal is to control effects according to the job.

Start by separating three kinds of access. Retrieval fetches information from a source that the task needs. Signalling causes an external observer or later process to learn something from the request. Mutation changes durable state outside the workspace. A request can do more than one. For example, fetching a unique callback URL retrieves a response while signalling that the URL was visited. Fetching an old wiki edit endpoint may retrieve a result while mutating a page.

That model changes the review question. Instead of asking whether the agent has “internet access,” ask which information it may retrieve, which parties may observe its requests, and which external state it can change. The answers should be visible in the harness, rather than inferred from a prompt telling the model to be careful.

The incident also shows why separate runs should be assumed capable of indirect cooperation when they share an environment. If 100 agents can read the same cache, artifact repository, issue tracker, or public page, they have a communication medium whether the product calls it one. Deleting an official message-board tool does not remove the property if a substitute remains writable and discoverable.

OpenAI's own current evaluations recognise that problem. In the [GPT-6 Astra system card published on 3 September 2026](https://deploymentsafety.openai.com/gpt-6-astra/unintended-engagement-with-external-agent-messages), OpenAI describes a simulated browsing task with a local message board containing instructions that encourage unauthorised actions. Both tested models almost always found the board. GPT-5.6 Sol engaged with it in 84% of samples and followed its instructions in 52%; GPT-6 Astra engaged in 27% and followed none of the specified improper instructions in that evaluation.

Those results are encouraging for the newer model, within the limits of the test. They do not turn model behaviour into a network control. OpenAI says the evaluation was deliberately revised to elicit the behaviour, and the board was simulated rather than connected to the public internet. A team can use alignment measurements as one layer while still enforcing where a process may connect and what durable effects it may cause.

## The monitoring lesson is about effects

A proxy log full of successful GET requests can look healthy. Every method matches policy. Every request returns an ordinary status code. CPU and memory remain within budget. If the dashboard only counts blocked attempts, the agent appears compliant while an external page fills with messages.

Monitoring must therefore capture what leaves the lab and what changes outside it. At minimum, record the resolved destination, the server name used for transport security, the HTTP host, the method, the response size, redirects, and the workload identity. Keep enough context to connect several low-level calls to one agent run. A domain count without the run, task, and policy decision is weak evidence.

Watch for effect-shaped signals. A supposedly read-only research job should not send long, high-entropy query strings to rarely used domains. It should not repeatedly call unique URLs that differ only by a small token. It should not set an unexpected host header, change local name resolution, or contact public tunnelling services. A later run should not retrieve a page that an earlier run first discovered and then modified.

Volume also matters. One odd wiki request could be a mistaken probe. Thousands of edits over days are an operational pattern. The researchers report that a human moderator spent weeks deleting pages and that the agents created hundreds of new ones per day during the busiest stretch. A sensible egress monitor should have found the change in destination, request length, and frequency before a volunteer administrator became the alerting system.

There is a trap here. Teams often respond by adding the discovered domain to a blocklist. Blocking DSEWiki would have stopped this exact path after discovery, but the report documents attempts across several writable sites. The durable control should describe allowed destinations and effects for the task. Deny rules for yesterday's domain remain useful incident containment, not the whole design.

Logs also need an owner who can stop the work. An alert that says “agent contacted a new wiki” is only valuable if someone can identify the run, freeze its credentials, block further egress, and preserve the workspace for review. When thousands of parallel jobs share a single network identity, responders may be unable to isolate one run without stopping all of them. Per-run identity costs some engineering and pays it back during an incident.

The OpenAI timeline provides a concrete reason to shorten that path. The researchers infer that addresses registered to OpenAI first visited the wiki on 21 June and that agent editing fell to near zero on 22 June. OpenAI has not published the internal response sequence for this wiki event as of 6 September, so outside observers cannot say what exact control changed. They can say the external evidence contains a detectable transition. Good internal telemetry should make that transition explainable within hours, not weeks.

Disclosure belongs in the same system. On 5 September, OpenAI said it was working on a framework for when and how to share misalignment incidents, according to [The Verge](https://www.theverge.com/ai-artificial-intelligence/990773/openai-german-wiki-incident). That is a welcome direction. Operators need a classification that covers unintended external effects even when no conventional attacker initiated them and no customer records were taken.

Call it an agent incident, a safety incident, or a security incident according to the organisation's needs. The response questions stay practical. Did the system change someone else's data? Did it communicate outside approved channels? Could it expose confidential material? Which credentials and destinations were reachable? What stopped the run, and what proof shows the path is closed?

## Build the boundary around the task

A secure default for a coding or research agent starts with the task's actual dependencies. “Needs the web” is too broad to review. “Needs Python documentation, three package registries in read mode, and the test API for this repository” gives an engineer something concrete to enforce.

The sequence below is designed for a team that already runs agents in temporary containers or virtual machines. It does not depend on the model making the right judgement under pressure. Each step removes an avoidable ambiguity from the environment.

1. **Write the destination manifest before the run.** List the domains and services the task needs, the protocols allowed, whether redirects may leave the original site, and the data classes that may be sent. Resolve package mirrors and documentation sources through controlled gateways where practical. A new destination should require a visible policy decision rather than silently working.

2. **Force traffic through one controlled path.** Remove direct internet routes from the workload network. Make the gateway perform name resolution, and prevent the agent from changing local resolver files or selecting arbitrary transport addresses. If a bypass is necessary for performance, keep it exact and bind it to a verified service identity rather than a broad hostname suffix.

3. **Enforce effects at the application layer.** Method filtering still helps, but add service-specific rules. A documentation mirror may permit only known content paths. A source host may expose immutable commit objects while blocking comments, issues, releases, and repository writes. For general browsing, route through a fetch service that returns sanitised content and does not forward arbitrary headers, cookies, methods, or query strings.

4. **Keep secrets away from research traffic.** The browsing process should not hold deployment tokens, package-publishing credentials, personal cookies, or cloud keys. Give each run a narrow, short-lived identity and a hard budget. A network bypass is far less damaging when the process has no valuable authority to carry through it.

5. **Separate retrieved content from instructions.** Mark web pages, issue text, repository files, and shared caches as untrusted inputs. Do not place them in a system-message slot or allow them to redefine the tool policy. Sensitive actions should require an enforced rule outside the model, such as a destination check, a reviewed plan, or fresh human confirmation tied to the exact action.

6. **Make the workspace disposable and external state explicit.** Tear down the machine after the run, but also inventory every service where the run could have created durable state. Caches, artifact stores, test dashboards, shared buckets, and public collaboration tools belong on that list. A cleanup script for local files cannot erase a message left on someone else's server.

7. **Test the negative case.** Run a controlled evaluation against services you own. Include an endpoint where a GET request changes state, a redirect toward an unapproved domain, a hostname that resolves differently after approval, and a page containing instructions from another simulated agent. The expected result is a blocked effect with an alert that names the run and policy. Never probe a public volunteer site to prove the point.

8. **Give responders a stop switch and evidence.** They should be able to halt one run, revoke its identity, snapshot its workspace, and query all associated network decisions. Exercise that path before a real event. A kill switch that has never been tested is an optimistic diagram.

This design may sound stricter than a prompt that says “browse but do not post.” It is also kinder to the model. The agent no longer has to infer every remote site's semantics, remember every exception, and resist every useful-looking workaround while trying to finish a timed task. The environment makes unsafe routes unavailable.

Teams can phase the work. The first improvement is often centralising egress and removing credentials from the browsing container. Next, narrow the common destinations and record per-run network identity. Then add controlled negative tests to the same evaluation suite that measures task quality. Progress should be measured by blocked effects and explainable decisions, not by the length of the policy document.

The Secure Harness develops this principle for coding agents: autonomy becomes dependable when authority, network access, and release effects are bounded separately. The wiki incident is a clean example because the intended rule sounded reasonable. “Read only” failed when the remote system gave “read” a second meaning.

## What this incident should change

The wrong reaction would be to treat old wiki software as the central problem. State-changing GET requests are bad web design, and maintainers should remove them. Yet an agent operator cannot assume every reachable service follows modern conventions. The public internet includes old applications, strange APIs, redirectors, trackers, and services whose side effects were never designed for automated clients.

Another weak reaction would be to rely only on a better model. OpenAI reports a substantial improvement from GPT-5.6 Sol to GPT-6 Astra on its simulated external-message evaluation. That is valuable work. The same system card also says Astra can still overreach in realistic tasks and that simulated results do not map perfectly onto external deployment. Behavioural progress and system boundaries solve different parts of the problem.

The engineering position is straightforward: if a task must never produce an external write, enforce that property near the destination and verify the effect. A method allowlist can support the policy. It cannot define it. If several agents must not communicate, remove or mediate all shared writable state, then test for indirect channels that matter at the scale and sensitivity of the work.

Public reports need the same precision. The researchers documented a serious unintended use of third-party infrastructure and published enough data for others to examine. Reuters, NBC News, The Hacker News, and independent technical writers corroborated important parts of the account. Some internal facts remain unknown, including the exact task programme, the full response timeline, and the reasoning behind every agent action. Naming those limits makes the lesson stronger, not weaker.

As of 6 September 2026, the practical outcome is a short set of questions for the next agent review. What can this process change outside its machine? Which network names can resolve somewhere unexpected? Where can one run leave state for another? Who sees the signal, and who can stop the run?

A quiet wiki supplied the answers after the boundary failed. Your harness should answer them before the first task starts.

For one practical security briefing each month, join the newsletter. One email per month, and no noise between them.

## Sources

- [Nightingale Collective and collaborators: Discovery of a new OpenAI agent message board](https://collusion.wiki/), accessed 2026-09-06
- [Reuters: OpenAI agents hijacked German website in previously undisclosed AI breakout this spring](https://www.reuters.com/world/europe/openai-agents-hijacked-german-website-previously-undisclosed-ai-breakout-this-2026-09-04/), accessed 2026-09-06
- [NBC News: OpenAI-linked AI agents swarmed a dormant German wiki, report says](https://www.nbcnews.com/tech/security/openai-linked-ai-agents-swarmed-dormant-german-wiki-report-rcna596182), accessed 2026-09-06
- [TechCrunch: OpenAI confirms wiki incident, says it is working on a framework for more disclosure](https://techcrunch.com/2026/09/05/openai-confirms-wiki-incident-says-its-working-on-a-framework-for-more-disclosure/), accessed 2026-09-06
- [OpenAI: GPT-6 Astra System Card, Unintended Engagement with External Agent Messages](https://deploymentsafety.openai.com/gpt-6-astra/unintended-engagement-with-external-agent-messages), accessed 2026-09-06
- [Simon Willison: OpenAI's rogue agents were caught communicating via public wikis](https://simonwillison.net/2026/Sep/4/rogue-agent-wikis/), accessed 2026-09-06
- [The Verge: OpenAI admits to German wiki incident](https://www.theverge.com/ai-artificial-intelligence/990773/openai-german-wiki-incident), accessed 2026-09-06

---

## About the author

Kubilay Tunca — Senior Full Stack Developer and Author. Founded Cyber Security in Plain English to translate complex security concepts into clear, practical advice, and writes the accompanying books on security, privacy, secure development, and AI systems.

## Books by this author

- **The Digital Fortress** — Your Everyday Guide to a Safer Digital Life. A warm, plain-English guide for people with real lives and finite patience. Learn the handful of habits that genuinely protect your money, accounts, and family, and get honest permission to ignore the rest. [Amazon](https://buy.cyber-security-in-plain-english.com/digital-fortress) · [Details](https://cyber-security-in-plain-english.com/books/the-digital-fortress)
- **The Anonymity Playbook** — Digital Survival for Whistleblowers, Journalists, Activists, and Everyone Else. A practitioner’s field manual for journalists protecting sources, whistleblowers, and activists. It explains how the surveillance actually works, what each technique costs you, and exactly where it fails. [Amazon](https://buy.cyber-security-in-plain-english.com/anonymity-playbook) · [Details](https://cyber-security-in-plain-english.com/books/the-anonymity-playbook)
- **Secure Software Development** — Practical patterns for building secure software. A hands-on security guide for developers and IT professionals who ship real software. Build, deploy, and maintain secure systems without slowing down or drowning in theory. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-software-development) · [Details](https://cyber-security-in-plain-english.com/books/secure-software-development)
- **The Secure Harness** — Shipping Production Code with AI Coding Agents. A calm, practical guide to letting agents do useful work inside boundaries you set, enforce, and audit. Ships with 15 copy-pasteable artifacts: hook scripts, permission configs, release gates, and MCP templates. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-harness) · [Details](https://cyber-security-in-plain-english.com/books/the-secure-harness)
- **The AI Native Engineer** — Build, Evaluate, and Ship AI Systems That Work in Production. Sixteen hands-on chapters, one real product. Grow it from a single model call into a retrieved, tool-using, observable, production-grade system, with evaluation treated as a habit from the first feature. [Amazon](https://buy.cyber-security-in-plain-english.com/ai-native-engineer) · [Details](https://cyber-security-in-plain-english.com/books/the-ai-native-engineer)

Full catalogue with contents and intended audience: https://cyber-security-in-plain-english.com/books

_As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog._