Crawl-Walk-Run Has Evaporated: SOC Leaders on Embedding AI Automation into Security Workflows

Hosted by Guardians of the Machine Age. April 28, 2026.

• Monzy Merza, Co-Founder & CEO, Crogl
• Tim MalcomVetter, General Manager, Coalition Inc
• Ambuj Kumar, CEO, Simbian
• Danny Z, Security Engineer, AI2

The panel was framed around a practical question: how do security teams actually get automation and AI into SOC workflows? What resulted was a session that challenged several things most security leaders treat as settled. The crawl-walk-run adoption model was declared insufficient. Mean time to detect was called a dead metric. And the long-standing argument for centralizing all security data got a public retraction from someone who spent years making that argument.

What follows is a distillation of the panel's core observations, prescriptions, and buying guidance. Attribution is noted throughout because panelists did not always agree on emphasis.

The Crawl-Walk-Run Window Has Closed

Monzy opened with a direct argument about the adoption model most security leaders have relied on. Crawl-walk-run "has been applied by a lot of security leaders," he said, and it made sense for a long time. It no longer does.

"The whole stack has been compressed," he said. "There's no more time." He pointed to a recent sophisticated campaign against the Mexican government as a concrete example of how quickly attack timelines now move. His conclusion: "the opportunity to do crawl, walk, run has evaporated."

The panel was careful here. Risk management does not disappear because the window is compressed. Another panelist said organizations still need bounded test environments: a department, a business unit, a newly acquired company transitioning to a new architecture. The prescription was to go all in on that bounded scope. What the panel rejected was treating adoption as a slow, linear progression across the whole organization.

The distinction matters. Parallelized transition within a defined perimeter is different from a leisurely crawl-walk-run across everything. Monzy's prescription: "security leaders and security practitioners really have to start thinking about what does the future state look like" and design toward that, not from where they are today.

Why MTTD Is No Longer the Right North-Star Metric

Tim made the sharpest argument on measurement. Mean time to detect (MTTD), he said, is largely outside a security team's control. In modern detection pipelines, the timing of upstream telemetry is determined by platform vendors. Security teams are optimizing a metric they cannot meaningfully influence.

The metric that actually matters is mean time to verdict (MTTV): the time it takes to decide whether an event is good or bad and whether action is required. That is something the SOC controls.

He was equally direct about MTTR. Mean time to respond and mean time to remediate are often used interchangeably by vendors and MSSPs but defined differently. "Critical alert" benchmarks can be misleading if you do not inspect how severity was assigned upstream. The problem is that low, medium, and high severity alerts can combine into a multi-stage attack. Filtering on pre-labeled criticals removes the ability to detect the full chain.

His prescription: look at everything, quickly, with a high level of automation. A cluster of events that looks unremarkable individually can be critical in totality. The goal is not a smaller queue. It is faster verdicts across a complete picture.

Fragmented Data Is the Real Operating Environment

One of the sharpest moments in the session came from Monzy on data architecture. He said he had spent years at Splunk and Databricks making the industry argument for putting all security data in one place. Then he said: "I was wrong."

Real customer environments are not clean centralized lakes. They are "three SIEMs, six data lakes" spread across on-premises infrastructure, cloud environments, and storage platforms with incompatible schemas, different access methods, and no shared query language. "All of that has always been out the window" for operational organizations.

His argument was not that visibility is unimportant. It was that visibility cannot require normalization into a single system as a prerequisite. He said "people can give themselves permission that it's okay to have fragmentation" and design systems that can analyze data no matter its format, schema, footprint, or access method.

Tim added an economic argument. The cost of fragmented data is not primarily storage. It is the network movement and compute required to transform data before storing it. Organizations that architect around centralized consolidation pay that cost continuously. As response windows compress, unnecessary data movement becomes harder to justify.

The panel's preferred framing: treat the federated data lake as the starting condition, not a problem to be solved before AI can work. Build around it. Do not wait for it to go away.

Why AI Makes Reactive Security Operations Insufficient

One panelist argued this point directly: the reactive SOC model does not hold when AI-assisted attackers move at wire speed. Once an attacker is inside a network, the sequence from execution to lateral movement to exfiltration can happen too quickly for a purely reactive workflow to respond.

Monzy connected this to alert volume. The alert numbers security teams have been working with are effectively pre-AI numbers. The environment is changing in two directions simultaneously. Attacker capability is more broadly available. Monzy described intelligence as "sort of commoditized at this point." Another panelist expanded that attackers now have more know-how, can exploit known vulnerabilities, find new ones, and push phishing and URL-based attacks through defenses with very little domain expertise and few resources.

At the same time, AI is generating new categories of internal operational and compliance complexity: transitive trust problems, agents doing unsupervised activity, shadow AI, and people uploading work data into outside services to manage productivity pressure.

Monzy's framing on AI itself: "AI usage is now a common denominator." Defenders have it. Attackers have it. Vendors have it. MSSPs have it. "It is just table stakes." The panel's point was not that AI is useless. It was that AI alone is not a durable competitive advantage. How it is deployed, governed, and evaluated is what separates teams that are getting ahead of the threat from teams that are not.

The shift the panel described was from reactive to proactive: understanding what is happening across the environment before a threat actor completes their objective, not after.

Where AI Can Be Introduced into SOC Workflows First

The most concrete implementation guidance came from the adoption discussion. One panelist said teams should stop treating AI as something to compete with and start identifying where it makes sense to hand off specific workflow steps.

Three lower-risk entry points were named:

Alert enrichment using LLMs, especially when deterministic playbooks fail because the alert type is new or has not been encountered before. This is where probabilistic reasoning adds value that rule-based automation cannot.

Summarization and explanation of technical findings. Not replacing analyst judgment, but reducing the time to understand and communicate what happened.

Earlier involvement in detection engineering, using knowledge of important assets and how they have been targeted before to inform what coverage gaps to close.

Monzy drew a line between the tactical and the foundational: "the use case stuff is going to be easy." The harder problems are architectural and are where most AI SOC products are under-evaluated.

What to Evaluate in AI SOC Products Beyond Hallucinations

Monzy made one of the sharpest buying-criteria arguments of the session. Buyers spend too much attention on hallucinations. The foundational problems get too little.

His list of the real evaluation criteria:

• Authentication and authorization: how the product handles identity and access within the system
• Secrets management: "the thing that's hard is how you build a secrets management system"
• Session management and session timeouts: whether the product handles these correctly by design
• User and privilege partitioning: whether data and actions are properly scoped per analyst and role
• Operating model: whether the product is SaaS, customer-managed, or self-managed, and what that means for data exposure and sovereignty

Then he went further. Even after you address secrets management: "that is not even the hardest problem here." The harder problem is context reconciliation. Large organizations have conflicting information across multiple systems. Speed alone does not solve what is happening. The system needs to maintain the most precise understanding possible given all available knowledge, and that context should not degrade over time.

One panelist made a parallel argument against the default approach of collecting everything. The prescription was to back-solve: decide what data is needed based on the outcomes the team needs to achieve, not collect everything, log it, and pay for it at scale.

Outcomes, Consistency, and Transparency

Tim closed with a framing that grounded the whole discussion. The goal is not to claim AI features. The goal is to stop threat actors. Quickly. Repeatably. Consistently. Transparently. With logged decision-making that can be reviewed.

The implicit critique across the session was that too many teams measure symptoms and siloed metrics instead of what is happening at the system level. MTTD is a symptom metric. Alert volume is a symptom metric. The system-level question is whether the team can produce reliable security outcomes when the next phase of attacker behavior arrives.

Speed matters. Context matters. Architectural rigor matters. The panel's argument was that none of them are sufficient alone.

---

This post distills the panel discussion at Guardians of the Machine Age, April 28, 2026. It reflects what was said in the session and does not represent the independent views of any organization.