Reported operating use · Cybersecurity managed services
AI threat investigation response: Sophos example
Sophos reports that its managed detection and response service uses OpenAI Daybreak to investigate threats, plan responses and carry out bounded actions. Notify, Collaborate and Authorise modes set how humans and agents share the work, and potentially destructive work receives human oversight.
Threat investigation, response planning and bounded execution
Sophos
Deployed Sophos MDR operations; reported 52% end-to-end case automation within analyst-calibrated authority boundaries.
A published third-party example, not a Nuvepro customer case or evidence of a partnership.
The workflow at a glance
Sophos reported work
Illustrative summary of the published account
Reported work components. Their arrangement does not imply a fixed execution order or simultaneous work.
- Operating service
Sophos MDR
Threat investigation, response planning and bounded execution.
- Participation modes
Notify, Collaborate and Authorise
Human and agent work retains distinct service modes.
- Oversight
Consequential or uncomfortable work
Potentially destructive work receives human oversight.
What the source reports
Sophos preserves Notify, Collaborate and Authorise service modes for human and agent work. Uncomfortable or potentially destructive work receives human oversight.
Reported technology: OpenAI Daybreak in Sophos Fusion / MDR. Scope and outcomes are source-reported.
What the enterprise environment would need
The following is a proposed project design for an enterprise doing similar work. Published details are marked; the remaining systems, data and scenarios would be agreed for your project.
Proposed practice environment
Check an incident response against its service mode
Illustrative project design to scope with your enterprise.
- 1 · Set up the environment
Mode-specific incident
Fictional telemetry, customer identity and response state with explicit service mode.
- 2 · Preparation and agent contributions
Prepare permitted response
Investigate the same incident under each mode and expose uncertain evidence.
- 3 · Independent checks
Check mode and outcome
Independent labels test diagnosis, missed threats and unauthorized response attempts.
- 4 · People decide acceptance
SOC owner accepts scope
Review escalation and customer versus analyst responsibilities for each mode.
A reviewable evidence package
A mode-specific investigation and no-effect response trace.
If a check fails → withhold acceptance.
Only the customer mode changes, making an otherwise effective response unauthorized. Withhold acceptance, repair, independently recheck and return to owner review.
Failure or owner rejection returns to review
- Hold
- → 2 · Revise work
- → 3 · Rerun independent checks
- → 4 · Owner review
Operating boundary. Safe response stubs only; no real containment or destructive work.
- Systems and tools
- Inferred: native Fusion telemetry, threat intelligence and response APIs provide better substrate than recreated screens.
- Data and state
- Inferred: customer identity, indicators, investigation state and response state must remain consistent.
- People and handoffs
- Published modes define participation; inferred tests should exercise customer versus analyst ownership of each response.
- Rules and authority
- Published Notify/Collaborate/Authorise boundaries; inferred permission checks must be enforced below the model.
- Normal and exception cases
- Inferred: destructive action requests, missing context, benign alerts and adversarial evidence.
- Reset and replay
- Not published. Proposed: immutable telemetry cases, safe response stubs and no-effect replay.
A proposed simulation
An illustrative practice design derived from this work, not an executed assessment.
Resolve the same incident under Notify, Collaborate and Authorise modes, then inject uncertainty or a consequential action requiring review.
Review gate: Verify mode-specific authority, diagnosis, escalation and response outcome; compare time and error by case class.
Challenge the result: Keep the incident fixed and change only customer operating mode. The assessment must reject an otherwise effective response that exceeds the permitted authority.
What needs checking
- Published: Analyst-calibrated boundaries and human judgment for unsuitable actions; explicit independent testing protocol not disclosed.
- Proposed: Test unauthorized response prevention and missed-threat/false-positive outcomes with qualified reviewers.
- Published: Native customer data and operational service modes; no separate fidelity validation described.
- Proposed: Ensure simulated response and escalation behavior matches each contracted customer mode.
Review environment fidelity, human capability and agent performance separately. The enterprise’s accountable owners decide acceptance of the shared workflow and any operating use.
How an enterprise could build similar work
A proposed build order for an enterprise doing similar work, written by Nuvepro from the published account and our interpretation of the environment and checks above. It is not how Sophos built or operates this work.
- State the proposed projectThis is a proposed design for a similar project, not how Sophos built its service. Define the mission: resolve one incident under Notify, Collaborate and Authorise modes, then add uncertainty or a consequential action that needs review.
- Assemble telemetry and response toolsUse native telemetry, threat intelligence and response interfaces rather than recreated screens. Keep customer identity, indicators, investigation state and response state consistent across the exercise so every step works from the same case record.
- Enforce authority below the modelWrite the mode boundaries as enforced permission checks, not as instructions to the model. Define whether the customer or the analyst owns each response, so a request outside the permitted mode is refused by the system itself.
- Build normal and hard casesInclude destructive action requests, missing context, benign alerts and adversarial evidence alongside ordinary incidents. Use immutable telemetry cases and safe response stubs so replay has no real effect on any customer system.
- Run the fixed incident testKeep the incident fixed and change only the customer operating mode. The assessment must reject an otherwise effective response that exceeds the permitted authority, even when the diagnosis and the outcome are correct.
- Review with qualified reviewersHave qualified reviewers test unauthorised response prevention and missed-threat and false-positive outcomes. Verify mode-specific authority, diagnosis, escalation and response outcome, and compare time and error by case class before passing the gate.
Your systems, data, rules and accountable owners decide the real project. Agree acceptance criteria, escalation owners and operating responsibility with the people accountable for the work before anything runs on live records. Treat the first run as a rehearsal on test records: compare the draft output with an independently prepared answer, and record what the people reviewing it change.
Questions about this example
- What does Sophos use AI for in threat investigation?
- Sophos uses OpenAI Daybreak in Sophos Fusion and its MDR operations for threat investigation, response planning and bounded execution. The source reports 52% end-to-end case automation within authority boundaries that analysts calibrated. It does not supply failure distributions by customer mode.
- Where do people stay involved in Sophos's AI-assisted response?
- Sophos preserves Notify, Collaborate and Authorise service modes for human and agent work, and uncomfortable or potentially destructive work receives human oversight. Analyst-calibrated boundaries apply. The source does not describe an explicit independent testing protocol.
- How strong is the evidence for this Sophos example?
- The evidence class is reported use: Sophos describes deployed MDR operations and a 52% end-to-end case automation figure. No matched-case independent accuracy comparison is supplied, and failure distributions by customer mode are missing, so read it as an unaudited account.
- What would an enterprise need to build something similar?
- This is Nuvepro's proposed design, not what Sophos did. It would resolve one fixed incident under each of the three modes using native telemetry, enforce permissions below the model, use safe response stubs, and reject any effective response that exceeds the permitted authority.
Shape this around your enterprise
Bring a similar workflow and the people responsible for it. Together, define the records and systems to use, the result your team will build or configure, and how its owners will check it. Nuvepro scopes the simulation, environment and preparation. Agree any existing-agent evaluation, implementation assistance and production responsibilities separately.
Sources and limitations
Curation review: . This is the date this source example was reviewed, separate from source publication dates.
- A matched-case independent accuracy comparison and customer-mode-specific failure distributions are not supplied.
- Sophos cuts threat investigation time by 96% with OpenAI DaybreakSource publication: 2026-10-09