This is a special post for quick takes by Daniel Tan. Only they can create top-level comments. Comments here also appear on the Quick Takes page and All Posts page.
(epistemic status: preliminary observation) While reading the METR incident report, something I noticed is that OpenAI seemed less willing to resolve key bottlenecks than the METR team. An example is here:
The investigators wanted per-action timestamps as part of their auditing, which were not in the transcripts.
OpenAI's initial response was that it was "not feasible to reconstruct these timestamps within time and compute constraints".
If this state of affairs had persisted, the investigators would only have had access to start-of-transcript and end-of-transcript times. This seems essentially useless considering that many of the transcripts are extremely long and occur over days.
So the investigators implemented their own methodology, which accurately figures out timestamps to a median error of 12 seconds and 99.8% validation accuracy (of being within 5 minutes). This all happened within 1-2 days (during the second period on-site).
This fine-grained timestamp data seems to have been extremely useful in putting together a detailed timeline of what happened.
So... what gives? Why was an incredibly well-resourced organization not willing / able to do something that a small team of 3 did in 2 days?
More generally I think OpenAI would not have tried nearly hard enough to recover many of the details presented in this report. (This is consistent with my experience from listening to their Black Hat talk, which was done earlier than and thus independently of the METR report)
You pretty much described it. Very little focus on agent dynamics, not exerpts, most focus on what got hacked and when, which vulns were exploited where. Exception: they used system logs to document the hacking timeline extremely well.