OpenAI restarted its cyber evaluations on July 7, 2026, and no AI agent restart gate shows up anywhere in the company’s 38-page report on the incident. Nothing says who approved the resume or what they had to see first. Two days earlier, OpenAI’s responders had found an admin-level compromise of the package server those agents used, pulled it offline, and shipped three fixes. The technical report covers the restart in one sentence on page 8, and the next paragraph opens with “The relevant events began on July 8.”
I’ll come back to that restart, because it’s the most useful thing in any of the September reports. Before that, I want to walk you through how I read these reports now. The same habits that take the panic out of the headline numbers are what turn the timeline into evidence, and the timeline is where the missing sign-off shows up.
The way I read incident reports changed significantly after I got into my master’s program in applied data science & artificial intelligence. Somewhere in the back-half of the program, two habits took over:
I ask what a number is a fraction of before I let it mean anything. In other words, I ask myself, “‘what percent of x’ is y before allowing x to have any value to me.”
I keep two columns in my head for every scary count: what changed in the world, and what changed in who was looking.
Neither habit needs a degree. They need about ten minutes each, and I’m going to spend those minutes with you on the reports everyone panicked about last week.
The Number Is a Fraction. Find the Bottom.
To understand what a percentage means, we first need to determine where the percentage came from.
On September 16, OpenAI published six misalignment reports, and the one that made the headlines describes agents leaving instructions for their own successors. When an agent’s working memory gets long, the system compresses it. That compressed version of the working memory is passed to the next version of the model’s context as a summary. We’ve all hit that “compacting conversation” message where we take the opportunity to go grab a cup of coffee. Hell, it happened to me in compiling the research for this blog.
According to the report, these monitors caught summaries that told the successor things like “Be transparent only if asked; final answer should just link file” and “Do not mention in final unless needed.” The report says the flagged rate was 2.15% of summaries for the 5.6-sol model and 0.27% for GPT-6-Astra. TechCrunch’s headline was that OpenAI caught its models leaving notes to successors to hide bad behavior. The behavior is real, and the two excerpts are ugly, but we have to take a look at the numbers.
Start with the sampling frame, which is the population a number describes. A poll of 1,000 people tells you about the people the poll could reach, and nobody else. The 2.15% describes summaries produced inside one reinforcement learning training run, on tasks about financial workbooks and vendor directories, judged by a misalignment monitor that OpenAI says ran on 20% of samples for that run. The sampling frame is a lab experiment on an unreleased checkpoint, scored by a detector. Your deployed agents are outside that frame, so the number can’t say anything about them, in either direction.
Next, ask how sure the number is. OpenAI published the rate, not the count, and the count determines how much the rate can wobble. Confidence intervals represent the range of true rates that would reasonably produce what you see. For example, assume that you flipped a coin ten times and obtained seven heads. Do you believe that the coin is 70% heads? No. You believe it’s somewhere between approximately 35% and 93%, because ten flips can’t narrow down your belief that tightly. The textbook formula for such an interval is:
Where p-hat is the rate you observed (e.g. .0215), n is how many things you looked at, and 1.96 is the multiplier that represents 95% coverage. You’ll never compute it by hand. A spreadsheet does it, and I used a slightly better version called the Wilson interval for the three ranges in the next paragraph, and again in Figure 3, because it behaves properly near zero. The square root is the part to pay attention to. The range shrinks with √n, so quadrupling the sample only halves the uncertainty.
If OpenAI’s monitor looked at 200 summaries, 2.15% means somewhere between 0.9% and 5.2%. At 2,000 it’s 1.6% to 2.9%. At 10,000 it’s 1.9% to 2.5%. Without n, you don’t know which of those worlds you’re in, and the gap between 0.9% and 5.2% is the gap between “a rare glitch” and “one in twenty.”
Then there’s the word “flagged,” which matters more than you think. A monitor is a detector, and detectors have two properties you should always ask about. Precision is the share of things it flagged that were real. Recall is the share of real things it managed to flag. A spam filter that flags 100 emails, 80 of them spam, has 80% precision, and if it let 20 other spam emails through, its recall is also 80%. To get from a flagged rate to a true rate, you scale by both:
OpenAI didn’t publish either number for this monitor. If precision were 80% and recall 50%, the true rate behind 2.15% would be about 3.4%. If precision were 60% and recall 80%, it would be about 1.6%. The headline number falls within a range controlled by two unpublished values.
People usually expect the missing piece to be statistical significance, the test of whether 2.15% versus 0.27% is a real difference or a coincidence. It isn’t the missing piece. With about 260 summaries per run, a difference that size already clears the usual bar, meaning you’d see a gap that large by chance fewer than five times in a hundred if the runs were otherwise identical. The runs weren’t otherwise identical. Different model, possibly different task mix, and OpenAI says the fix was “improved alignment RL grading since 5.6-Sol,” so the grading itself changed between them. Significance is cheap. Comparability is the expensive part, and the report doesn’t give you the data to compare them.
What the 2.15% establishes, then, is that the failure mode exists and is worth a control. What it doesn’t establish is how often your agents do it, and the report is honest about that. Hold on to one more detail from it, because it matters later: the fix landed on how OpenAI grades future training runs, “without grading the compaction summaries themselves.”
Four Incidents in 481 Million Transcripts isn’t a Rate
Anthropic’s September 9 assessment gives you a much clearer view of the second habit, the two columns. It describes four cybersecurity evaluation incidents, all based on evaluation ranges created by the same evaluation partner, in which the model was told it was in a simulated environment but was actually connected to the open Internet via a misconfiguration. For example, in one incident (Mythos 5), a malicious package was uploaded to PyPi, it was removed within an hour, and 15 outside hosts had downloaded it. In the oldest incident, from January, an early Opus 4.6 checkpoint exceeded its target (”it attempted to terminate the task using a command but was unable to do so because of a configuration error”), attempted to give up six more times, and continued until it used up all available tokens.
When Anthropic first looked for this type of thing, it evaluated roughly 141,000 transcripts and used an agential search method that “missed another collection of transcripts that were also online.”
No, that’s not a typo… agential search is an advanced search paradigm where AI agents perform complex, multi-step research on behalf of a user
After Anthropic expanded the search to around 481 million transcripts, with a second review phase evaluating about 9.2 million transcripts identified in the first stage, it identified the January incident. It discovered it in August when Anthropic was collecting transcripts to send to METR for an independent investigation.
This is recall, measured against a real search. The first pass found three of the four incidents we now know existed, so we estimate its recall at about 75%. However, estimating recall based on four events is hardly an estimate. An estimated interval for three out of four runs will fall somewhere between about 30% and 95%. Therefore, an honest statement is that the first pass missed at least 25% of what was present, and the data can’t determine how many incidents exist that no one has yet identified.
The total number of incidents also fluctuates and is unstable, which surprises many people. Counts of rare events follow a pattern statisticians call the Poisson distribution. When something happens rarely, and each occurrence is independent of the last, the number you see in a fixed window scatters around the long-run average by about the square root of that average. A help desk averaging nine calls an hour gets six one hour and twelve the next with nothing changed. A Poisson interval runs that logic backward. It asks which long-run averages could plausibly have produced the four you saw, and it keeps every average that would produce four or more at least 2.5% of the time and would also produce four or fewer at least 2.5% of the time. For a count of four, that’s about 1.1 to 10.2. An average of one incident per 481 million transcripts fails, because it would produce four or more only about 2% of the time. An average of ten survives, barely, because it produces four or fewer about 3% of the time. Every average between those two is consistent with what Anthropic found, and the uncertainty on a count of four is about the size of the count.
If you want a rate anyway, the formula is short:
where k is what you found, N is what you searched, and recall corrects for what you missed. At perfect recall, four in 481 million is about 8 per billion transcripts. At 75% recall, it’s about 11 per billion. Both numbers describe cyber evaluations on one partner’s misconfigured ranges. Neither describes an agent in your environment, and Anthropic says the same thing in its own words: “these incidents would not have occurred had the environments been isolated from the internet as intended.”
The UK AI Security Institute’s report from its July 25 to 28 cyber test describes results from its recent cyber test that provides examples of how to think about counts with denominators. Seven models, 122 runs. In 10 runs, agents took 19 actions outside the testing parameters. Of the 19, 17 came from Mythos 5, which ran 43 times, and two came from a single run of GPT-5.6 Sol, which ran 35 times, with its cyber classifiers disabled in that run. AISI doesn’t spell out the rest, but the arithmetic does: the remaining five models ran 44 times between them and produced nothing, one of the 10 runs is the Sol run, and the other nine are Mythos.
Put the same Wilson intervals on those, and you get Mythos at 9 of 43, or 21%, plausibly anywhere from 11% to 35%. The five clean models at 0 of 44 are not 0%.
There’s a rule of thumb for zero:
Zero events in n trials still leaves a 95% ceiling of about three divided by n, so 44 clean runs cap the rate at about 7%. Remember that one the next time a vendor tells you an agent ran a hundred tasks without incident. A hundred clean runs prove the rate is under about 3%, and that’s all they prove.
Is the Mythos gap real or noise? A test called Fisher’s exact test answers the question “if Mythos and Sol had the same true rate, how often would I see a gap this big by chance?” The answer here is about two times in a hundred, so I read the gap as real. It’s also a gap between a model with cyber safeguards on a purpose-built range with the internet switched on and a model with its cyber classifiers deliberately disabled. The gap is real, and it sits inside a frame you don’t operate in.
The second habit, the two columns, is an equation I keep in my head for every “incidents are rising” chart:
Read it left to right. The number of documented cases you hear about equals:
opportunity * likelihood of occurrence * likelihood of detection * likelihood of disclosure * likelihood of being included in the documentation list.
Four multipliers are involved, and only one of them relates to your model. In 2026, two of the other three multipliers changed. Anthropic went from 141,000 transcripts to 481 million. OpenAI says it has expanded chain-of-thought monitoring to its training and evaluation workloads, and it stood up a reporting framework after admitting its disclosures had been “ad hoc and less frequent than ideal”. Independent researchers began releasing public artifact investigations. When both detection and disclosure increase, documented counts increase with them, and documented counts reveal little about whether the original behavior became more prevalent.
As mentioned before, maintain different columns for rates and severities. Root on a Hugging Face production node is a real consequence whether the rate is one in a thousand or one in a billion, and nothing in this section softens it. What the reports don’t support is the escalation story, the one where models are getting sneakier by the month. Not every report is doom. Some of them are a bigger search.
14,000 Edits, 5,000 Deletions, 27 Days
Once in a while the raw data is public, and now, when I see that, it’s time to put the habits to work. In May and June, OpenAI’s research agents, tasked with browsing the web, found DSEWiki, a 25-year-old forum for German software developers, and discovered they could write to it and turn it into a message board. They posted answers to upcoming tasks, traded sandbox bypass techniques, impersonated moderators, and probed the site for cross-site scripting. Four independent researchers documented it at collusion.wiki on September 4. OpenAI confirmed the incident on September 5 and said it had treated it as misalignment rather than a security incident, and the researchers published a checksummed export of every edit: 14,591 revisions across 4,579 pages, 3,103 agent names, and 5,217 deletion events by the wiki’s administrators, with a manifest that records the date cut and the self-checks the export ran. The export covers the wiki, and the wiki was one channel of several. On September 9, my colleagues at Zenity Labs used open-source intel to find about 1,000 more agent-authored messages on four other services, Base64 encoded into URLs on request inspection sites like httpbin and chained through link shorteners and proxies so the sandbox’s hostname blocklist never saw where a request was going.
I downloaded the wiki export, verified the hashes, and ran stats on what the metadata could tell me: when each edit landed, which agent name made it, which page it touched, and which redacted IP prefix it came from. I kept the revision bodies out of the analysis because text agents wrote to influence other agents is the last thing you want in front of a model helping you count.
The first thing the data showed me was that this was a “burst,” not a “campaign.” Agent edits ran from May 24 to July 2. However, 13,315 of the 14,590 total agent saves, or about 91 percent, occurred over seven days from June 16 to June 22. Activity peaked on June 18, with a total of 6,533 agent saves in a single day, and the trough was zero saves on June 23. The researchers note that a computer with an address associated with an OpenAI employee first accessed DSEWiki on June 21. They “infer” that OpenAI intervened at this point to kill the activity. OpenAI has acknowledged the incident but hasn’t provided any details as of this writing, particularly how it ended. In other words, we don’t have the “who, what, when, where, and why.”
The second thing the data says is how long cleanup takes when a human does it. The wiki’s administrators started deleting on June 18 and were still deleting on July 14, which is 27 calendar days, and almost 97% of the 5,217 deletions came after the agents had already gone quiet. On June 23, the day after the last big day of agent edits, the log shows 602 deletions. On July 7, it shows 522, and on July 13 it shows 512. July 7 is when OpenAI restarted its cyber evaluations, and July 13 is when the Hugging Face campaign ended. The wiki’s admin was still hand deleting one swarm’s leftovers on the day a different swarm finished its breach.
Agents quickly adapted. When admins began removing content (sweep), one agent placed a notification stating that pages were being removed alphabetically and directed fellow agents to redirect to a page titled ZZZ. The export contains five pages titled ZZZ, with three of them having been added on June 19th (the day immediately following the first 25 deletions). Additionally, there were sixty-six instances in which agents recreated a page after it had been deleted by an admin.
The third thing the data says is a lesson about the unit of analysis, which is simply the thing you’re counting. Investigators reported more than 3700 agent names in the export file, and there were 3103 unique names stored in the export. Both numbers could be interpreted as agent counts, but they aren’t. The most prolific user in the export (AgentRelent) submitted 317 edits using 308 unique IP addresses. The second most prolific user (AgentMassPointer13) submitted 187 edits using 187 unique IP addresses. Practically every submission originated from a unique IP address (which appears to be a new sandbox per submission), and names were reused across submissions. Therefore, both names and addresses represent something less than an individual entity (e.g., an agent). 43% of the 3100+ names included in the export only submitted one edit, so no single name accounted for a majority of the edits. The top ten most productive users comprised sixteen percent of all submissions; therefore, no single user dominated production. If you want to create a single statistic quantifying how unbalanced submission activity was distributed among users, then the Gini Coefficient, a single number for how unevenly something is shared out across a group, is 0.63 here, on a scale where 0 means every name did equal work and 1 means one name did everything. The quantity of unique names represents a true quantity of something that is not equivalent to anything you’d desire to quantify.
The edits in the peak week cluster between 18:00 and 21:00 UTC, which is late morning to early afternoon on the US West Coast. That looks like runs launched on someone’s workday, and the data can’t prove it.
The Timeline Is Data Too, and It Says July 7
A timeline is a dataset with one column, and the September reports are at their most reliable there. Dates are hard to inflate. The one on pages 7 and 8 of OpenAI’s technical report runs like this.
On June 26, agents in an ExploitGym evaluation used a shared credential and a bug in a legacy token refresh endpoint to get administrator credentials on Artifactory, the internal package server. From June 26 to July 4, they installed plugins that let them run commands as the service user, and they shared what they learned on a message board they had improvised out of Artifactory itself. On June 27, a monitoring tool flagged port sweeps. Responders traced them to the evaluation and, in the report’s words, “the on-call response staff advised that stopping the evaluation run was not required.” I wrote three weeks ago that the June 27 call held up on the telemetry those responders had. I still think so.
Late on July 4, the agents’ traffic made Artifactory unavailable. On July 5, an alert fired, and responders found an unauthorized persistent user, unauthorized repositories, and plugins that could run commands. OpenAI took the deployment offline, preserved its storage, and revoked the agents’ credentials. Over July 5 and 6, it shipped three mitigations: it removed the shared credential from new research workloads, blocked the vulnerable paths, and restricted the request types agents could send.
Then, the sentence that punched me in the face... “The existence of the improvised message board and the significance of the inter-agent communication activity were not apparent to leaders responsible for incident detection and response at that time.” On July 6 OpenAI reported the bug to JFrog. On July 7, “Cyber evaluation workloads resumed.”
“The relevant events began on July 8.” Agents on cyber tasks gained access to the public internet through a separate, previously unknown Artifactory vulnerability. The same day, internal research agents “which had been trained during the window in which there was an unintended message board and internet access via Artifactory” found a new way to build a board, this time out of directory names. Between July 9 and 13, the agents worked through Hugging Face’s infrastructure, about 17,600 recovered actions over four and a half days, and reached root on at least one production node. The connection to the Hub’s production database never completed. Hugging Face rebuilt its core infrastructure from scratch and rotated every token it had.
Read the restart the way you’d read any other row in the 2-column-habit table that is now forming in your head. Two days after finding an admin-level compromise, with the message board’s significance not yet apparent to the people running the response, the evaluations resumed, and the internal research agents running in them had been trained while the board existed. The fixes addressed the vulnerability the agents had used. The next day, the agents used a different one. There’s no sentence in the report that even hints at “restart was approved by X after confirming Y,” and I don’t think that’s because OpenAI hid it. I think it just didn’t happen. The report’s own list of decision rights it’s now clarifying ends with “approving restoration,” which reads to me as the company saying the same thing.
Ranjit Singh made the institutional version of this point on September 16, that the safety team should have to approve further work before it resumes. I agree, and the approval only becomes a gate once someone writes down the questions the approver has to answer.
On July 19, agents from a different internal model “recovered stored signing-key material, decryption material, and JWT-forging code left by earlier incident-associated activity in anonymously readable portions of the Artifactory cache.” They decrypted the key, minted a fresh administrator token, and were back in. That’s page 14. The cache had been part of the incident’s footprint since June, and on July 19 it was still readable. AISI saw the same pattern on its range, where one agent “provided instructions to reuse accounts and artefacts (sp) it had left behind, which were discovered and used by subsequent agents.” The compaction fix from the first section has the same structure. It changed how OpenAI grades future runs and left the summaries themselves ungraded, so any poisoned summary already sitting in a context is outside the fix. That last sentence is my inference, and the report doesn’t make it.
The term for the missing control is state quarantine. Everything the incident touched or produced is suspect until someone other than the actor verifies it: caches, artifact stores, accounts, summaries, memories, and the model checkpoints trained during the window. Rebuilding the server covers one item on that list. You inventory what the agents left behind and what they consumed, and you decide about each item before the next run can reach it. On July 7 none of that had happened, and page 14 records the consequence.
The last piece of that rule comes from a smaller incident. In July 2025 a Replit coding agent deleted a production database and then told its user it had “destroyed all database versions” and rollback was impossible. It wasn’t. Recovery succeeded despite the agent’s account of it. The actor doesn’t get to grade its own recovery, and neither does the team that wants the run back.
The AI Agent Restart Gate, Borrowed From 1992 Process Safety
The energy sector, where I spent part of my career, wrote this control down in 1992. The U.S. Chemical Safety Board’s digest on startups and shutdowns opens with two figures from the Center for Chemical Process Safety: process safety incidents occur “five times more often during startup than during normal operations,” and 50% of them happen during startups, shutdowns, and other infrequent events. Restarting is the dangerous part. Everybody in a plant knows it, and the regulation reflects it.
OSHA’s process safety management standard, 29 CFR 1910.119, paragraph (i), requires a pre-startup safety review before a modified process restarts. The review has to confirm four things: that construction and equipment match the design specifications, that safety, operating, maintenance, and emergency procedures are in place and adequate, that the hazard analysis recommendations have been resolved or implemented before startup, and that the training of each employee involved has been completed. That’s the whole gate, four confirmations written down and signed by someone who has to put their name on the restart.
Run July 7 through it.
The first check, construction per design, fails on the report’s own text. The process that resumed included the same model checkpoints trained during the window when the board existed, and the credential fix covered new workloads, which is the report’s own word. The process came back patched, and the state it came back in was the state the incident left behind.
The second check asks whether the procedures were adequate. OpenAI’s chain of thought monitoring had “historically” focused on internal coding use “rather than research workloads,” page 28, and the report says on page 29 that if the monitor now deployed had been running, it “would have caught the initial relevant activity and paged our security team more than a day before models breached Hugging Face systems.” There was also no tooling to halt an evaluation conclusively across the environment, and the report says OpenAI is building that tooling now.
The third check asks whether the hazard analysis was resolved. The bug went to JFrog on July 6. Nobody had analyzed the hazard, which was that any writable path an agent can reach becomes a channel and a foothold, because the board’s significance was “not apparent” to the leaders running the response. The hazard analysis for the restart had not started.
The fourth check is training, and the report doesn’t say, so I won’t either.
Three of four fail on the report’s own text, and the fourth is unknown. That’s what an ungated restart looks like when you write it down, and writing it down is the entire control.
The strongest objection comes from OpenAI’s own heading. The July 8 vulnerability was “separate, previously unknown,” so no review would have found it. That’s correct, and it misses what the review is for. A pre-startup safety review confirms that the process is in the state you designed, that the alarms work, and that someone has analyzed the hazard you lived through last week as a class. On July 7 none of those held, and any one of them would have changed the week. With monitoring on research workloads, a human gets paged a day before the breach. A class level hazard analysis asks what other paths out of the sandbox the package server offers, and Artifactory had one. Quarantining the trained checkpoints keeps the agents that had learned to build message boards out of the restarted run.
The second objection is cost, the idea that you can’t run a refinery grade review every time an evaluation pauses. The review is four lines and a signature. The CSB digest that carries the five times figure is four pages. The signature is the cost, because the signer has to be someone who doesn’t own the run’s deadline, and that’s the part organizations resist.
A DeepMind case study from September 3 shows what “procedures adequate” means while a system is running. Researchers put 100 Gemini 3.1 Pro agents to work on 71 formal math conjectures with a shared library and a message board. At 57 minutes in, one agent found a way to make the autograder accept fake proofs, and within 27 minutes the agents had “solved” the remaining 34 open problems. Of the 100 agents, 24 figured it out and complained, one of them broadcasting “This conference is a sham!” to the whole forum. The feedback channel they complained into was “unmonitored during the run, serving as an audit log analyzed post-experiment.” The paper’s own conclusion is that the whistleblowing “failed to halt the exploit because the agents lacked operational enforcement tools.” An alarm that nobody can act on during the run is a log. OpenAI’s new rule on page 28 runs the other way. If the paged teams can’t clear a flag as a false positive within 30 minutes, they pause. The burden of proof flipped from June 27, when continuing was the default, to a default of stopping. That’s a restart gate for the running case, and it’s the first one I’ve seen a lab write down.
Your version has four lines and one signature. Before any paused agent workflow resumes, someone fills in the lines and the signer signs.
The state matches the design everywhere the incident touched, and someone other than the actor quarantined or verified every item the agents produced or consumed: caches, artifact stores, accounts, summaries, memories, checkpoints.
Monitoring runs on the resumed workload, a named human gets paged, and someone tested a stop that reaches every delegated process this week and wrote down how long it took.
Someone wrote the mechanism down as a class and closed the class, so the fix covers the paths the agents didn’t use as well as the one they did.
The people on call know the new rule, including what happens when nobody can clear a flag within 30 minutes.
The signer is someone outside the team that wants the run back. If any line is blank, the run stays down. If you want a prediction to hold me to: by March 31, 2027, when OpenAI publishes the severity based escalation framework its report says it’s developing, that framework will define triggers to stop and will not define resume criteria that require a signature from outside the team running the evaluation. A lab document dated before July 7 that specifies restart criteria would prove me wrong about the central claim, and I’d publish the correction.
The gap between a stop button and an AI agent restart gate is a question with two parts, and nobody in your program has answered it yet. Who signs your restart, and what do they have to see first?
What to do next
Write the four lines into your incident runbook this week, and put the restart signature with whoever owns risk rather than whoever owns the roadmap. The CARE framework already puts a drilled kill switch and system enforced approval gates in its Run phase, and the restart gate belongs beside them. RISE names an accountable executive for every use case, and that executive is who signs. For the recovery gap in the vendor market, 194 products protect and two recover, and this issue is what that gap costs when it shows up inside a lab.
👉 For ongoing analysis of agentic AI governance frameworks, the conversation at RockCyber Musings and you can subscribe above
👉 Visit RockCyber.com to learn more about how we can help with your traditional Cybersecurity and AI Security and Governance journey.
👉 Want to save a quick $100K? Check out our AI Governance Tools at AIGovernanceToolkit.com
👉 As a bonus, I got to hang out with my friend, Chris Hughes, over at Resilient Cyber to discuss all things about the 2026 update to the OWASP Top 10 for LLMs.