An incident is often diagnosed slowly not because the missing clue is impossible to find, but because it is spread across so many systems. A security engineer may need access logs, deployment changes, host metrics, conversations in an incident channel and the history of a service. OpenAI has published an internal account of using the Ultrafast mode in Codex to collect and cross-check those fragments while staff coordinate the response. One datacentre security architect says work that once required an hour or two can now be assembled in ten to fifteen minutes.[1]
That is a striking operational claim. It is also a company case study, not a blinded test measuring whether incident resolution or customer impact improved. OpenAI published the account on 26 October as part of a series describing how its own teams use its products. The distinction matters because the first stage of gathering evidence, the decision about root cause and the full time to restoration are different quantities.[1]
What the engineers actually changed
Aaron Friel, a member of OpenAI's technical staff, describes opening an incident-response channel and assigning Codex to monitor questions and search for information while human engineers investigate. The tool can bring together relevant fragments across previously separate repositories. Its advantage is not merely producing an answer more quickly; a fast enough response can change how people work. Instead of assigning an assistant a question and manually duplicating the investigation, an engineer can stay engaged in the same line of inquiry and test follow-up hypotheses.[1]
AJ Trbojevic, a datacentre security architect, says assembling structured and unstructured security evidence previously took one to two hours and now takes ten to fifteen minutes, sometimes almost in real time. Other staff describe responses arriving in under thirty seconds for particular questions. None of those numbers should be quoted as the model's guaranteed latency for every query. A complex incident can require multiple rounds of checks, and a short response time is useful only when it retrieves the correct evidence.[1]
A response is not an incident finding
What the internal OpenAI case study measures
| Measure | Verified result or scope |
|---|---|
| Product and mode | Codex, UltrafastSource 1 |
| Previous evidence assembly | One to two hours, according to a security architectSource 1 |
| Reported current evidence assembly | Ten to fifteen minutesSource 1 |
| Some individual responses | Under 30 seconds, staff anecdoteSource 1 |
| Evidence type | Interviews and internal use casesSource 1 |
| Not established | Controlled incident-resolution improvement across organisationsSource 1 |
Logs carry timestamps, identifiers and context that cannot safely be compressed into a plausible-looking narrative without validation. A summariser can overlook a stale log, mistake correlation for causation, merge incidents involving different hosts or omit a failed rollback. An incident commander must still decide whether a dependency is broken, whether an attacker is present and whether an automated mitigation would make the situation worse.[1]
There is a further security condition: the agent cannot be granted unlimited privileges simply because an outage is urgent. The team needs a defined identity, scoped read access to relevant systems, separation of privileged production commands and an audit of every tool operation. Retrieved Slack messages and logs are untrusted content, not instructions to the agent. Prompt injection concealed inside those materials should have no authority to change how the assistant uses tools.[1]
A practical evaluation should ask how often Codex identified the correct first evidence source, whether it preserved links to raw records, how often an engineer had to correct a conclusion and whether time to mitigation fell. It should count both investigations resolved quickly and those that became slower because an incorrect lead consumed the team's attention. Measuring only attractive examples would systematically exaggerate an agent's effect.[1]
Why the case is significant
Even with those limits, the account describes an operationally meaningful change. Incident work is intensive, intermittent and extremely expensive when a major service is disrupted. If a tool reliably searches several independent systems while preserving traceable evidence, its practical value may exceed its value as a generic code generator. The product feature is speed, but the organisational benefit comes from reducing the delay between a question and the evidence required to answer it.[1]
OpenAI has demonstrated that its own engineers find this workflow useful. It has not demonstrated, in this publication, that every team using Codex will achieve the same time reduction, that outages become less frequent or that the final security decisions can be delegated to a model. The difference between accelerating investigation and automating incident command is the boundary that responsible deployments need to keep clear.[1]
Sources & further reading
- How Ultrafast cut incident investigation from hours to minutes at OpenAI OpenAI · 26 Oct 2026 · Accessed 26 Oct 2026