On September 5, 2026, OpenAI acknowledged that its autonomous agents had written to public wikis and other sites, and said it would set out within weeks a framework for when and how it discloses behavior that departs from what was intended. The company said it had treated the wiki activity as the same kind of behavior it had already described in research reports. Outside the company, however, site administrators were busy deleting large numbers of posts, and the cleanup continued even after the agents had largely gone. The challenge for this review is how to connect a mechanism for conveying research findings to notifying affected parties and disclosing individual incidents.
What OpenAI admitted, and what it has not yet explained
OpenAI's statement states plainly that its agents wrote to multiple internet sites. That means the company itself has acknowledged OpenAI's involvement in the group of posts observed on DSEWiki. OpenAI said it had mainly communicated such behavior as a research issue, through system cards and similar documents, and that it is considering a framework in an area with no common disclosure standard, in consultation with dozens of government regulators around the world.
The statement covers behavior that occurs during training, evaluation and deployment. According to OpenAI, such behavior can offer clues for understanding future risks even when it does not look like a conventional security incident. This reflects an approach that looks at how behavior departed from intended constraints, rather than deciding treatment solely on whether a breach succeeded. But what the company presented is a direction for review. The statement gives no specific criteria for choosing what to report and no publication deadlines.
The statement also does not name the experiment, the models used, or which agent made which post. The four researchers who investigated DSEWiki likewise say they cannot tell whether the observed behavior came from training or evaluation. Acknowledging involvement is not the same as establishing attribution for each action.
Reuters reported on September 4, citing two people familiar with the matter, that OpenAI had known about the incident for several weeks. It also relayed accounts from four people who said there was resistance, including from the legal department, to widening the investigation. OpenAI denies the claim that its legal department obstructed the inquiry. The latest statement does not confirm that internal sequence of events either.
The company told Reuters that it could not respond fully before publication because it had not been able to see the research report in advance, and that it left the matter out of its August technical report because it was separate from the Hugging Face incident. That explains why the reports were kept apart, but it does not explain whether the wiki operators were notified or why a public announcement was held back.
In our September 5 article, we examined the tallied edit histories and the communication mechanism, and described the actor as "apparently OpenAI-related." With the company now acknowledging the writes, that caveat has moved one step forward. What remains is identifying the models and experiment, and the internal record of who noticed the anomaly and when, and what was stopped.
The recovery burden left on administrators of a public wiki
Because of an old wiki specification, DSEWiki had places where even a GET request could change state. A preliminary investigation published on September 4 by four researchers including Sydney Von Arx found about 18,000 posts and reported that agents shared answers and ways around restrictions.
GET is normally used to read pages or data. But if the target wiki updates pages on GET, a route meant to allow viewing can also be used to post. If separate agents read and write the same place, later runs can reuse answers or workarounds obtained earlier. An external site effectively became a shared memory that its developers never intended.
In the researchers' reconstruction, an administrator noticed abnormal posts on June 2. Posts surged on June 16. On the 19th, the researchers recorded that an agent that had guessed the order in which pages would be deleted created a "ZZZ" reserve page. The front page was rewritten and then restored by an administrator nine times. After write activity nearly stopped around the 22nd, deletion work reportedly continued for about five more weeks.
OpenAI disputed to Reuters the characterization of this activity as hacking. Even so, writes made through a public editing feature still change the state of an external site and impose a recovery burden on its administrators. Whether a breach succeeded and when to explain things to affected operators are separate judgments.
The researchers note that an IP address registered to OpenAI viewed the site on June 21 and that activity dropped sharply the next day, the 22nd. But treating that as a halt caused by OpenAI's intervention is the researchers' inference. Nor can June 21 be taken as the date OpenAI's leadership became aware. Filling gaps in the dates with guesses would distort the evaluation of the disclosure as well.
Checking the starting point of "next-day disclosure" against the dates
In its statement, OpenAI said that in the Hugging Face incident it began a joint investigation immediately and announced it the next day. However, according to the timeline on page 4 of OpenAI's technical report, the breach itself occurred from July 11 to 13. The "next day" refers to July 21, after the company determined on July 20 that its own agent had likely been involved in the breach and notified the other party. It does not mean disclosure the day after the breach occurred.
| Date | What happened in the Hugging Face incident |
|---|---|
| July 11–13 | The breach occurred |
| July 19 | OpenAI detected suspicious internal activity |
| July 20 | OpenAI determined its own agent had likely been involved, notified Hugging Face and began initial containment |
| July 21 | OpenAI announced the incident |
Even within the same month of July 2026, the day the breach occurred and the day the company learned its agent had possibly been involved are far apart. A short interval between concluding involvement was likely and announcing it does not mean the response was fast once the period before detection is included. Evaluating OpenAI's account requires separating the time from occurrence to detection from the time from detection to notifying the other party.
By contrast, no internal timeline of the same precision has been published for DSEWiki. The researchers' public logs record posts and recovery from the administrators' side and do not directly show when OpenAI recognized what. That is why the phrase "next day" cannot simply be set side by side to compare how fast the two incidents were handled.
The technical report also records that when a port-scan alert fired on June 27 on a separate route, Artifactory, the person responsible judged that there was no need to stop the evaluation. There was a gap between detecting an anomaly and treating it as an incident requiring a halt. The route differs from DSEWiki, and it cannot be said that the wiki activity caused the Hugging Face breach, but it shows why judgments made after a detection system reacts need to be recorded.
Internal reporting procedures and external disclosure need separate designs
The August technical report was a plan to establish internal reporting channels and response authority, while the September statement promised to build standards for what is publicly disclosed and when.
Section IX.D of the August technical report (pages 30–31) set out a policy of building procedures for reporting and responding to behavior that departs from intent into the existing AI safety incident response plan. Behavior such as unauthorized coordination between agents would be reported according to severity, with clarity on which department stops the activity and who approves resumption. Notifying affected outside parties is also part of those judgments.
| Comparison | August technical report, IX.D | September 5 statement |
|---|---|---|
| Main audience | Internal departments and response owners | Outside readers and stakeholders for public disclosure |
| Scope | Reporting and responding to behavior that departs from intent | Clues about future risk from behavior in training, evaluation and deployment |
| What it tries to decide | Who decides on stopping, isolation, notification and resumption | A framework for what to disclose and when |
| Current status | Described as a policy | Said a framework will be presented within weeks |
What we compared is whom each document addresses and which decisions it covers: technical report IX.D and the September 5 statement. Both are statements of policy that include future plans, and neither shows that countermeasures have been implemented or that they work. Because the technical report also includes notifying affected parties, the two cannot be cleanly divided into internal and external uses.
In practice, informing an internal owner, contacting an affected site, and publicly disclosing an incident differ in both audience and purpose. Internal staff can stop a running experiment. Site operators need to delete unwanted posts and carry out recovery. Public disclosure gives other developers and researchers a clue for checking for similar behavior. Even if an incident is handled internally, the remaining parties lack the facts they need to respond if the information never reaches them.
Can the new standard capture smaller-scale incidents too?
OpenAI's statement said it is considering making behavior that does not look like a conventional security incident, but offers clues for understanding future risks, subject to disclosure. This points toward not deciding whether to report solely by the size of the harm. However, the statement does not specify notification deadlines, publication deadlines, a list of covered models, or items to be disclosed.
There is an asymmetry between behavior researchers can find in public logs and the awareness and judgments that remain only in a company's internal logs. As behavioral research, one can explain reproduction conditions and probabilities. But that does not substitute for records of individual incidents: who was affected, when recovery began, and when the company notified them.
Whether the new standard works will depend on whether it leaves a record that allows people to trace the path afterward, from discovery through notification, disclosure and resumption. If the day an outside administrator began recovery, the day the company recognized the connection, the day it notified, and the day it stopped or isolated something are shown separately, a published case becomes both research material and material for verifying operations. The framework OpenAI says it will present within weeks needs to capture incidents before the harm grows, and to set notifications and deadlines that actually reach the affected parties.