TL;DR
- Expel CEO Dave Merkel hosted three security leaders from ZoomInfo, RiotGames, and Markel to discuss practical steps to being intentional about AI deployment
- The main takeaway is that the line between human control and automation in a SOC varies—there’s no one-size-fits-all method for every company (and there shouldn’t be).
- You can find the full recording on the webinar on-demand here
Shawn Thomas has spent 20 years in security operations, and most of that career has been an argument for trusting the people in the room, not the machine.
“I’ve spent 20 years talking about why we don’t trust security operations people,” said Thomas. “Yet suddenly we’re just going to trust a computer that’s known to hallucinate over a human. It’s such a fascinating transition.”
That’s how we opened our latest webinar, “Where do humans belong in today’s security operations center?” after Dave Merkel, Expel’s CEO and co-founder, welcomed a panel of three cybersecurity leaders:
- Shawn Thomas, Senior Director of Threat Intelligence and Response and Fraud at ZoomInfo
- Merlin Clemens, Security Engineering Manager at Riot Games
- Lewis McIntyre, Senior Director of Cyber Fusion at Markel
Merk opened by calling AI resistance career-limiting, and nobody on the panel argued the point. But resistance to AI and blind trust in it turned out to be two different problems, and the panel spent the hour on the second one.
Three ways humans stay in the process
McIntyre described the shift he’s watched happen. “When most people hear autonomous, they think of just taking out the human altogether.” His alternative keeps a human watching the whole process instead of just approving it afterward. That’s closer to human-over-the-loop than human-in-the-loop, with full automation reserved for almost nothing.
Clemens went further and said he’d drop the word autonomous from the conversation entirely. “We’ve had augmented SOCs forever,” he said. “This is just another tool in the toolkit.” His point: security teams have absorbed new categories of tooling before (EDR, SOAR, PKI) without handing over judgment to any of them—AI is just the next one in that line.
What actually decides where AI gets to run
Before the panel, Merk asked the three of them to map their own tasks on a two-axis grid: trust required against impact if the call goes wrong. High-trust, high-impact tasks stay human. Low-risk, repetitive ones are fair game for automation.
Here’s what the results looked like:
McIntyre put detection engineering and remediation in the human column without hesitation: “I always want an engineer to be supervising that loop, or to be inside of that loop.” At Markel, a human has to click deploy, and remediation has to be defensible to the regulators the company reports to.
Thomas pushed the framework further, arguing that impact is a property of the specific decision, not the task category. “Context is king,” he said. “If I get a suspicious login at 3am and I don’t have staff, why not automatically lock out that account and reset sessions? What’s the cost of that, as long as it’s not an executive who’d freak out?” A production change gets no AI near it. A routine account lockout at 3am, with the right guardrails, might.
Each panelist named their own version of that context: McIntyre watches revenue-generating systems, system administration, and executive identity, and said his team is deliberately less aggressive with automation around executives, even though technically they hold less system access than most engineers. The sensitivity is about who they are, not what they can touch. Clemens tracks critical infrastructure, calibrated to what his company actually is: “I’m a video game company, so I’m not taking down medical equipment or a finance company. I’m taking down services.” Thomas added two more factors to business impact: time sensitivity and severity, what he called how bad is bad.
What it costs when nobody’s watching
The panel didn’t have to hypothesize about what goes wrong, because they’ve all lived it. McIntyre described a security vendor whose automation started deleting accounts in his company’s cloud environment. When he asked the vendor to explain it, they struggled to. “At the end of the day, I’m the one holding that bag,” he said, because he brought on the vendor.
Clemens described something worse. An automation read an empty API value as a wildcard and banned a legitimate system hash across a 7,000-device deployment overnight, bricking machines company-wide as they rebooted. The incident stretched past 3am, while the customer contact he was updating happened to be on a Disney vacation with his family, watching it unfold from a hotel room. “If you apply that to humans,” Clemens said, “the system was hard-coded, and there were changes outside that automation nobody accounted for when writing it. Now apply AI to that mix. What are all the variables it has to track to not do the same thing?”
Who owns the mistake
Clemens told the story that made the accountability argument concrete. Early in his career at an MSSP, he isolated a device that turned out to belong to the company’s CEO. His VP called minutes later and told him to undo it. He refused. “Nobody’s above the wall,” he said. “If you’re going to fire me for protecting the company, I’ll stand by my decision.”
Merkel tied the thread together: “You want a human to be able to own that mistake.” An AI system can’t be held responsible for a bad call, can’t explain its reasoning to a regulator, and can’t stand in front of a VP (or a judge, for that matter) and defend a decision. A person can. That’s exactly why a person has to be positioned to make the call in the first place, not just review it afterward.
The math didn’t work out the way vendors promised
Cost came up as its own reality check. Automation cuts some repetitive workload, but licensing, training, and token spend add up fast. “Many companies are discovering that AI is actually more expensive than the people,” Merk said. You have to make sure you’re pricing it against what it actually replaces, not what it promised to replace.
What to do with this
Here’s a condensed version of the panel’s advice:
-
- Automate the repetitive, low-trust work. Think alert triage on known infrastructure, enrichment, reporting. Keep a person on detection engineering, remediation, and anything touching an executive account.
- Evaluate impact by the specific decision, not the task category. Two different remediation actions can have the same classification, but once a decision is made, result in very different outcomes. Focus on that outcome, not the category.
- Price automation against what it actually replaces—training and token costs included—not against the vendor’s promised outcome.
- Build toward a human watching the whole process, not a human rubber-stamping the end of it.
No one on this panel was arguing against AI, or even asking to slow it down. Instead, they argued that the job hasn’t changed as much as the tooling has, which means someone still has to own a mistake. And as of right now, that isn’t a job for a robot.
You can get more from the full conversation here.
