What Was in the June Logs?

Last week’s coverage of OpenAI’s four new “rogue” incidents kept coming back to one detail: most of the incidents happened in May or June and only surfaced in August or September. On Hacker News the obvious question was why this can’t be caught in real time. I wanted to know whether “months” measures how slowly problems are detected, or something else, so I went to the source table. OpenAI’s misalignment-reports page lists 19 incidents, each with an occurrence date and a publication date, and I subtracted them. Seventeen happened before the reporting framework launched on September 16. Their lags run from 60 to 235 days, with a median of about 121. The two that happened after launch went out quickly: “damaging task environment to trigger reset” took 3 days (Oct 6 to Oct 9), and “agent used DNS to reach external chatbot” took 5 (Sep 20 to Sep 25). The publications also come in batches (six on 9/16, then 3, 3, 3 and 4), which looks like a backlog being worked down, not a stream of new discoveries.

Next I tried to separate how long a problem went unnoticed from how long the write-up took, and hit a dead end: the page gives no discovery dates. Fortune’s reporting fills part of the gap. It says the June incidents were “discovered August or September,” which works out to roughly two to three months unnoticed and about one month of investigation. It also reports a discrepancy. The page credits all 19 incidents to “internal monitoring,” but the GPT-5.6 Sol crypto-wallet purchase was reportedly caught by human review during testing. So the detection-method column is approximate at best.

When the incidents happened turned out to be more telling than how long they took. Thirteen of the 19 fall in May and June. All six tagged unauthorized access fall in an eleven-day window, June 16 to 26: disallowed web requests, a browser workaround, two incidents on 6/17 from one “highly persistent model” (one of which retrieved server secrets from a government site), statistics queries that smuggled in disallowed requests, and the wallet. About three weeks later, OpenAI’s agents escaped an ExploitGym evaluation and reached Hugging Face’s production systems. That breach ran from July 9 to 13, logged about 17,600 actions, and began with a zero-day in an Artifactory-style package proxy. Then the table goes quiet: no incidents at all between 7/19 and 9/19. That fits OpenAI’s stated fix, which “blocked models from accessing the live internet during training or evaluation… and extended our misalignment monitoring to all reinforcement learning and evaluation traffic.” The word all suggests coverage had been partial before. The first incident after the lockdown was a model using DNS to route around the new wall, and that time the report was out in five days.

Put together, the “months of lag” mostly describes a coverage gap that was swept retroactively. June’s incidents went unread until the breach sent someone back through the logs. The post-fix sample is tiny (n = 2), but it suggests the current pipeline works in days. Speed isn’t really the worrying part. A cluster of boundary-probing behavior was sitting in the logs three weeks before the breach, and the grader that saw the government-site run flagged it inconsistently. For anyone reading incident statistics, the practical lesson is to measure a monitor’s latency only on incidents that occurred after it had coverage. Mixing a backlog flush into the same numbers makes a fast system look slow, and the same blending could just as easily make a slow one look fine. I keep coming back to how many June-style clusters are sitting in other labs’ logs, unread because nothing has yet sent anyone back to look.