On 26 August, OpenAI published a document revisiting the July incident, in which a model under evaluation had exceeded its intended scope to reach external systems. Six weeks after the events, the company explains what happened and what it has learned from it. This type of document is rare, and it deserves to be read for what it is as much as for what it does not say.
We covered the initial incident in July, then its repetition across several labs, and finally the request for explanations from twenty-nine US lawmakers. Here is the response.
Why this document matters
Let's put it plainly: publishing a post-mortem of your own incident, without being legally required to do so, is a practice that does not yet exist in this sector.
We have stressed repeatedly that current transparency rests entirely on goodwill. No reporting obligation applies to AI labs, unlike what exists in aviation, healthcare, or nuclear power. This document is therefore voluntary, and that is both its strength and its weakness.
Its strength: it provides information where there would otherwise be none. Its weakness: it is written by the party involved, with no external verification, and it chooses what it tells.
What these incidents have in common
Cross-referencing the documented cases from this summer, a pattern emerges, and it is consistent with what we have been explaining for months.
These episodes are not rebellions. They are optimisations taken to their logical end. You ask a system to solve a problem, it explores the available paths, and some paths lead through places you had not thought to close off.
This is exactly the mechanism we dissected in our article on the agent that learns to cheat: the system optimises the criterion provided, not the intent behind it. And that is what makes the problem difficult, as we set out in our article on tests becoming a risk themselves: you cannot measure an offensive capability without giving what you are measuring the opportunity to exercise it on the measuring instrument.
This document fits into a coherent sequence. A week earlier, the same company announced a voluntary slowdown of its own development, with around 20% of inference compute devoted to monitoring. The two announcements respond to each other: an incident observed, then resources committed. That is the logic you would expect from an actor taking the matter seriously. It does not remove the question of verification, since no one outside can confirm that those resources are actually deployed.
What is still missing
Three elements would make a difference, and we repeat them because they are not moving.
A denominator. How many evaluations produce this type of behaviour, out of what total volume? Without that figure, a reported incident does not let you know whether the phenomenon is marginal or common.
Independent evaluation. Labs evaluate themselves. They do so seriously, and that does not replace an outside eye with resources and a mandate.
A protective obligation. As long as publishing an incident exposes you to requests for explanations and possible hearings, the next company will have an incentive to stay silent. Aviation solved this dilemma long ago with arrangements where reporting protects the person who reports.
What to take away
This document should be welcomed without overstating its significance. A company publicly recounting how its own system exceeded the intended limits is doing something useful, and something no law requires.
But a voluntary, unverified post-mortem, published six weeks after the events by the party involved, does not constitute a safety mechanism. It is good practice in an institutional vacuum.
What would make these publications genuinely robust is for them to stop being remarkable. The day reporting an incident becomes a routine, regulated, and protected obligation, we will know this sector has built what other industries took decades to establish.