When its managed security provider’s contract came up for renewal, a global enterprise software company chose not to renew. Instead it stood up an in-house SOC on D3 Morpheus, run by a materially smaller team than the blended operation it replaced, across multiple SIEM platforms, with AI carrying the investigation work that used to be assembled by hand. Here is how it was decided, how it was measured, and how it runs.
Key takeaways
- The buying criterion was not AI. It was whether one platform could take over alert management, case management and automation from an MSSP by a fixed date.
- The company defined pass/fail criteria for AI investigation before the pilot, then ran a hands-on proof of concept on live production data against them.
- Attack Path Discovery investigates alerts that have no playbook, which was the capability that separated an agentic SOC from the automation the team had used before.
- The proof-of-concept environment became production. Kickoff to MVP took under two weeks, and the SOC went live ahead of the MSSP contract end date.
- The model is designed to be replicated in the company’s regional SOCs, where a smaller team plus a Morpheus instance does the work of a traditionally larger one.
Terms used in this case study
Customer profile
The situation: a split SOC and a hard date
The company ran security operations as two teams. A managed security provider handled Tier 1 and Tier 1.5 triage. An internal team handled escalations and everything after. Between them, dozens of people were involved in getting an alert from detection to closure.
The workflow was manual from the first alert. An analyst picked it up, opened a case, moved through several other tools to investigate, brought the details back, and updated the case. Multiple SIEM platforms meant context was spread across consoles and assembled by whoever was on shift.
“An alert comes in, analyst has to pick that up, make a case, go into these other tools, run their investigations, bring back the details, update the case. That entire process is very time consuming, and you need to bring them up to the more modern era.”
SOC leadership, global software company
When the MSSP contract came up for renewal, the company chose not to renew. That turned the contract end date into a hard go-live date for an in-house SOC, and it turned a tooling evaluation into an operating-model decision. The target was explicit: process alerts from numerous SIEMs, automate the enrichments, use AI to carry the analysis, and do it with a smaller team at the same quality or better.
What the platform had to do
The team had used automation platforms before and knew the failure mode: every alert type needs a playbook, every playbook needs an engineer, and the first alert nobody anticipated lands back on an analyst. The requirements were written against that experience.
- Take over the MSSP’s job outright. Alert management, case management and automation in one platform, by the deadline.
- Investigate novel alerts. An alert with no pre-built playbook had to be investigated, not parked.
- Be maintainable by the team itself across multiple SOCs, without vendor involvement for routine change.
- Keep data inside the company’s own boundaries.
“A big selling point is if we get a novel alert that we don’t have a playbook for, we expect D3 to be able to figure it out, run the investigation and come up with results.”
SOC leadership, global software company
The scorecard: criteria set before the pilot
The company did not decide on demo impressions. Before committing budget, it wrote down pass/fail criteria the AI had to clear during a proof of concept on live data.
The criteria answered four questions. Do analysts trust the output? Is it consistent regardless of who is on shift? Does it make investigation faster and deeper? And do analysts use it?
| Question | What was measured |
|---|---|
| Trust | How often analysts accept the AI-generated context without editing it |
| Consistency | Variance in disposition for the same alert type across shifts |
| Speed | Time from alert to actionable context, against the manual baseline |
| Depth | Relevant context gathered per case, against the manual baseline |
| Correlation | Time to link related activity into one incident |
| Adoption | Share of eligible alerts where analysts use the AI enrichment, within the first month |
| Confidence | Analyst-rated satisfaction with AI output |
The evaluation was hands-on from the start. The company’s technical team spent about six weeks in the platform with live production data, building alongside D3 engineers rather than watching from the sidelines: alert ingestion from Splunk, endpoint and vulnerability enrichment, dynamic query generation for additional context, and AI analysis on live alerts. By the time internal architecture approval came through, the team already knew what the platform could do. The formal proof-of-concept sessions and CISO sign-off followed within a week. The technical decision was made at its close, and the purchase followed.
“It’s a good replacement for what we do today and has everything we need in order to replace our MSSP. And then the secondary objective is all the AI enrichments that’s going to give you guys an edge in running investigations and be able to do more and faster.”
SOC leadership, global software company
The structure is reproduced here because it transfers. Any SOC evaluating AI investigation can run the same seven measures on its own data and set its own thresholds.
How the in-house SOC runs
Nothing in the detection stack was replaced. Morpheus connected to the SIEMs and tools already in place and became the layer where investigation, case management and response happen.
Pre-processing first
Pre-processing playbooks deduplicate and triage inbound alerts before assignment, so the caseload landing with the new team started no larger than the volume the managed provider had been handling.
One investigation layer over multiple SIEMs
Attack Path Discovery writes and runs its own queries against the SIEMs and the connected endpoint, vulnerability and threat-intelligence tools. It works backward from the alert to the entry point and forward to every user, host and account affected. The analyst does not choose which console to start in; the evidence from all of them arrives in one case, with one timeline and an entity graph.
Investigation written up before anyone opens it
By the time a case is assigned, the AI summary separates what the SIEM detected from what Morpheus found elsewhere, states the root cause, and scores priority on impact, confidence and existing controls. The analyst decides. Response actions are staged for approval or executed within the autonomy boundaries the company set, and every step is in the audit trail.
Adaptive tasking against the company’s own procedures
When an analyst wants more, they direct further investigation in plain language and Morpheus carries it out against the company’s SOPs. Investigation follows the evidence rather than a fixed checklist.
Reporting to leadership
KPI workspaces report alert volumes and agent activity, so SOC leadership can see what the platform is handling and where analyst time is going.
Results
- Live ahead of the contract end date The in-house SOC went into production on Morpheus before the MSSP contract lapsed, on the timeline the company had set.
- Kickoff to MVP in under two weeks The POC environment migrated straight into production, carrying an estimated 40 to 50 percent of the build with it.
- Caseload held flat through the transition Deduplication and pre-processing were tuned so the alerts reaching the new team started no larger than the MSSP’s volume.
- A smaller team, by design The in-house SOC was sized well below the blended MSSP-plus-internal operation it replaced, with the investigation work moved to the platform.
The company’s stated plan is to replicate the deployment in its regional SOCs, where a smaller team plus a Morpheus instance does the work a larger team would traditionally have done, and to extend Morpheus to its incident response team for case management, so IR and SOC share one record.
Why this matters for any SOC facing an MSSP renewal
The company was not shopping for a SOAR and did not buy the AI as a science project. The criterion was whether one platform could take Tier 1 and Tier 2 work off a managed provider by a fixed date, with a smaller team than the blended operation it replaced, and investigate the alerts nobody wrote a playbook for. That is the question most enterprise SOC leaders are asking at renewal time.
The pattern that transferred here is simple: a hands-on proof of concept on live data, criteria written before the pilot, and a POC environment built to become production. The AI did the investigation work. The company kept the judgement, the data and the guardrails.
“Our main criteria was, can we use the automation platform to replace our MSSP? The main function there is alert management, case management and automation. All the AI stuff is icing on top to make the SOC more efficient, and it becomes more important in the other instances we plan to roll out.”
SOC leadership, global software company
Frequently asked questions
Can an agentic SOC platform replace an MSSP?
For Tier 1 and Tier 2 work, yes, provided the platform can take over alert management, case management and automation by a fixed date and investigate alerts that have no pre-built playbook. In this case a global enterprise software company declined to renew its MSSP contract and moved L1 and L1.5 triage plus L2 investigation in-house on D3 Morpheus with a materially smaller team than the blended operation it replaced.
How did the company evaluate AI investigation before committing?
It defined pass/fail criteria before the pilot, grouped under four questions: do analysts trust the AI output enough to accept it unedited, are dispositions consistent across shifts, does investigation get faster and deeper, and do analysts adopt it. It then spent about six weeks hands-on in the platform with live production data, building the integrations and running AI investigation on real alerts, and scored the platform against those criteria. Once internal architecture approval was in place, the formal proof-of-concept sessions and CISO sign-off followed within a week.
How long did it take to go from kickoff to a working SOC?
Under two weeks from kickoff to a minimum viable production environment. The proof-of-concept environment migrated straight into production and carried an estimated 40 to 50 percent of the build with it. The in-house SOC went live in 2026 ahead of the MSSP contract end date.
What did Morpheus integrate with?
Multiple SIEM platforms, including Splunk, plus the company’s endpoint detection, cloud detection, vulnerability management and threat intelligence tools. Each tool remained the system of record for its own data; Morpheus became the investigation and case management layer across all of them.
What does an agentic SOC do that a SOAR does not?
A SOAR runs a pre-written playbook for each known alert type; an alert nobody anticipated lands on an analyst. An agentic SOC platform reads the alert, writes and runs its own queries across the connected environment, builds the timeline and entity graph, and presents a root-cause narrative before a person opens the case. Playbooks still govern response actions, which run deterministically under the autonomy level the customer sets.
How was alert volume kept manageable for a smaller team?
Pre-processing playbooks deduplicate and triage inbound alerts before assignment, and Attack Path Discovery investigates each remaining alert before a case is opened, so the caseload reaching analysts started no larger than the volume the managed provider had been handling, with far more of each case already done.
Related case studies
Related reading on D3Security.com
About D3 Security
D3 Security builds D3 Morpheus, the agentic SOC platform that investigates and responds to security alerts autonomously. Morpheus connects to the SIEM, EDR, XDR, identity and cloud tools an organization already runs, investigates every alert with Attack Path Discovery, and executes response through deterministic playbooks under a human-set autonomy mode. It is used by enterprise SOC teams, MSSPs and MDR providers that need to scale investigation without scaling headcount, and deploys in cloud, on-premises, hybrid, sovereign-region and air-gapped environments.
Customer details in this case study are anonymized at the customer’s request. Figures are the customer’s own, from its evaluation and production records. Request a demo or read the D3 glossary of agentic SOC terms.
Canonical URL: https://d3security.com/resources/enterprise-soc-mssp-exit-agentic-soc/
Facing an MSSP renewal of your own?
See Morpheus investigate your alerts, on your SIEMs, with your playbooks left where they are. A working session with a D3 engineer, not a slide deck.