Incident response

Detection

The production monitoring described in full on the Monitoring page is the primary path for catching a safety issue that only shows up once a version is genuinely live. It catches issues that surface at real scale, rather than something that would have realistically surfaced during pre-release testing. Alongside that automated monitoring, direct reports from users and outside researchers matter just as much. Those come in through responsible disclosure. They're treated as an equally legitimate detection path, not a secondary or lower-priority one. A real person noticing something wrong and taking the time to report it is often faster and more precise than waiting for an automated pattern to accumulate enough signal to trigger on its own.

A pattern matching any of the seven evaluation categories, once detected through either of those two paths, is escalated to a specific place. It goes to the exact same safety review function that signs off on releases in the first place. It is not routed through a separate, generic on-call rotation unfamiliar with that specific version's evaluation history. That continuity matters in practice. The people deciding how urgently to respond to a live incident are the same people who understand exactly what was tested going into that release. They understand what wasn't tested, and what the known open items already were. That's different from a team encountering the model's safety posture for the first time under incident pressure.

Mitigation options, fastest to slowest

The response to a confirmed incident isn't a single fixed action. It's chosen from a small set of options, ordered roughly by how fast they can be deployed against how deep a fix they actually provide. Picking the right one is itself part of the judgment call the safety review function makes. A narrow, urgent issue affecting one specific tool action gets a fast, narrow response. A deeper issue reflecting a real gap in training gets a slower, deeper one. Applying the wrong tool to a given severity is itself treated as a mistake worth learning from. Overreacting with a full retraining cycle for something a rate limit could have handled is one example. Underreacting with a narrow patch for something that needed a real retrain is the other.

• Targeted product-level restriction. Disabling a specific tool action or narrowing a rate limit without touching the model itself. Available within hours.
• Rollback. Reverting a staged rollout, or in a serious case the full production version, back to the last confirmed-safe checkpoint.
• Safety-tuning point release. A targeted re-run of the safety-tuning stage addressing the specific finding, without a full retraining run. The usual path for a confirmed but not urgent finding.
• Full retraining. Reserved for a finding that reflects a gap in the training data or process itself, rather than something a tuning pass can address.

Disclosure

A confirmed incident that affected production is disclosed in the affected model's revision history, at minimum. That's a permanent, dated record, not something that quietly disappears once the underlying issue is fixed. For anything a user would reasonably want to know sooner than the next scheduled documentation update, a direct notice goes out. It goes through the announcements page. That's the same channel used for ordinary product news and version releases. It isn't a separate, harder-to-find security bulletin most users would never think to check.

A quietly patched issue with no user-facing trace at all is not the default outcome for a confirmed finding here. We think that's worth stating explicitly, rather than leaving it implied. The quiet-patch approach is a real and common industry pattern, and we've deliberately chosen not to follow it. The instinct to fix something silently and move on is understandable from a reputation-management perspective. It also means users never learn what actually happened to a product they're trusting with real work. We think a security section that's willing to describe a rejected checkpoint or a real production incident is more useful to a reader. Several pages in this section do exactly that, rather than presenting a spotless, uneventful history that isn't actually accurate.

How severity gets classified

Not every confirmed finding gets the same response, and deciding how urgently to respond is itself a judgment the safety review function has to make quickly and consistently. That judgment weighs two things together: how many users or how much of the surface area a given issue actually touches, and how reversible the consequence is if it isn't addressed right away. An issue affecting a narrow, rarely-used tool action is treated differently from one affecting a widely used connector. An issue where the worst outcome is a minor, easily-corrected mistake is treated differently from one where the worst outcome is genuinely hard to undo. Both factors feed into which mitigation option from the list above actually gets reached for first, described above roughly fastest to slowest. Getting that initial call right matters, since reaching for a heavier response than a finding actually warrants has its own real cost in disruption and delay.

That classification isn't fixed the moment it's first made. A finding initially assessed as narrow and low-urgency gets re-classified if additional reports come in showing it's broader or more severe than first understood. That re-classification can happen at any point, including after a fix has already shipped, if new information changes the picture. We'd rather revise an initial severity call openly than let an outdated classification quietly under-prioritize something that's since turned out to matter more than it first appeared to. A revised classification is logged alongside the original one, not quietly overwritten as though the first assessment never happened. That record is part of what feeds back into how future findings get classified, so the process itself gets better calibrated over time rather than repeating the same misjudgment.