TL;DR: Alert investigation only becomes safe at scale when every stage is governed, from read-only intake and evidence-linked narratives to risk-weighted disposition and human-gated response, according to D3, with 800+ self-healing integrations and a reported 18-minute median drift repair time. The practical lesson is that automation without auditable controls just accelerates bad conclusions, not better ones.
NHIMG editorial — based on content published by D3: Investigate every alert, but govern every stage
By the numbers:
- Morpheus runs 800+ self-healing integrations, and when one drifts, the median repair is 18 minutes rather than the four to six weeks a manual fix typically takes.
- The median repair is 18 minutes rather than the four to six weeks a manual fix typically takes.
Questions worth separating out
Q: How should security teams automate alert investigation without losing control of the outcome?
A: Automate the sequence, not the authority.
Q: Why does investigation automation fail when scoring is opaque?
A: Opaque scoring forces analysts to trust a verdict they cannot inspect.
Q: What do teams get wrong about autonomous SOC claims?
A: Teams often confuse assistance with autonomy.
Practitioner guidance
- Keep alert intake read-only Separate evidence collection from any response action so analysts can review an unchanged attack path before the system alters state.
- Require transparent scoring inputs Expose the factors, weights, and contradicting evidence behind every alert disposition so reviewers can challenge the result instead of trusting a black box.
- Gate response by action consequence Use command-risk tagging or an equivalent approval model so high-consequence actions wait for human review while lower-risk actions can proceed faster.
What's in the full article
D3's full analysis covers the operational detail this post intentionally leaves for the source:
- How the Morpheus workflow maps each investigation stage to a specific control decision and risk boundary
- The full explanation of Effective Alert Risk, including how exposure, identity blast radius, data proximity, and intel match influence disposition
- Examples of the evidence-linked narrative model and how contradiction handling is built into reviewer workflow
- The maintenance model behind 800+ self-healing integrations and the repair assumptions that keep coverage intact
👉 Read D3's analysis of governed alert investigation automation →
Alert investigation lifecycle automation: where governance breaks down?
Explore further
Automated investigation only scales safely when governance is embedded in the workflow, not bolted on afterward. The article makes the case that each stage of alert investigation can fail differently, which is why a single automation layer is not enough. A read-only intake path, transparent scoring, evidence-linked narratives, and governed response gates are all separate controls, not interchangeable features. For cyber operations teams, the lesson is that speed without stage-level control increases the odds of false confidence.
A question worth separating out:
Q: How do you know if alert investigation automation is actually working?
A: You should be able to inspect the evidence, reproduce the reasoning, reverse a flawed disposition, and restore any broken integration quickly enough that coverage does not decay. Reliable automation is visible in auditability, recoverability, and connector health, not just in alert volume reduction.
👉 Read our full editorial: Alert investigation automation needs governance at every stage