What Security Leaders Actually Want From AI SOC Tools
We talk to a lot of security leaders, and lately one theme keeps coming up: AI was supposed to fix the SOC's oldest problems, too many alerts, not enough context, thousands of custom detection rules nobody's fully audited in years. Instead, what we keep hearing is that most AI SOC tools have bolted themselves onto one layer, triaging alerts faster, while the real engineering problem sits underneath, untouched.
Across these conversations, one thing keeps surfacing: security teams don't trust the infrastructure their AI SOC tools are built on, and that's fundamentally an engineering gap, not a modeling one. Fix the data and systems layer, and everything above it gets easier. Skip it, and you're just adding a faster engine to a car with no brakes.
Why AI SOC Adoption Stalls on Trust, Not Technology
Gal Shafir, CEO of Fig Security, told us he hears the same objection every time he pitches AI into a SOC: "I don't actually trust my foundation today. How am I going to trust this AI agent that you want me to use?"
He described most SOC infrastructure as running on tribal knowledge, engineers "mapping on a whiteboard what is connected to what." That's an engineering critique as much as a security one - his point wasn't that security teams lack skill, it's that they're spending their time on unowned, undocumented infrastructure instead of security work. As Gal put it, "their job today is mostly around plumbing rather than actually security." His fix is observability engineered underneath that plumbing, so that "when the agents tell you that you're good, you know it's because you are, not because something broke in the plumbing."
His read on the category: "It's really a control problem more than anything else." And, in his view, the appetite is there - "SOC modernisation is some of the biggest projects that right now sits on every CISO's table."
AI SOC Coverage: From Days to Seconds
Robert Fly, CEO of detections.ai, shared a familiar Friday afternoon scenario: a new threat breaks, and the CISO wants one answer, are we covered?
Today, he told us, that answer is slow. "That effort of being able to get that answer takes a lot of time," Robert says. "It can take anywhere from days to weeks" - correlating threat intel against thousands of custom detections spread across multiple SIEMs. Stripped down, that's a data engineering problem: a pipeline and correlation challenge dressed up as a security workflow.
His fix pairs automation with community: platforms where teams "come together and work together and save each other time" instead of rebuilding the same detection logic from scratch. The goal, as he framed it, is blunt - collapse "mean time to coverage... down to seconds as opposed to days or weeks." Getting there is as much a systems-design bet as a product one.
Why the Best AI SOC Tools Sell Context, Not More Alerts
Kabir Madura, CEO of Leen, shared his view that most AI SOC tools are solving the wrong problem entirely. "Everyone we talk to says I don't need more noise. I don't need more detections. I need a way to actually solve these problems."
His bet: security needs its own context layer before agents can act on anything - an explicit wager that the missing piece isn't more detection logic, it's the data architecture underneath it. But he was clear that trust has a ceiling. Asked whether a CISO would let an agent build integrations and take action unsupervised, Kabir didn't hedge: "Our thesis is probably not, not for a long time."
Leen's agents, he explained, build auditable policies instead - action with a paper trail, not action in silence. That's a deliberate engineering choice: traceability designed in, rather than bolted on after the fact.
What These Conversations Mean for Engineering
Line up the three conversations and the engineering thread is hard to miss. Gal's plumbing comment is about who owns and observes infrastructure. Robert's days-to-weeks problem is about pipelines and correlation at scale. Kabir's context layer is about data architecture as the prerequisite for any agent action. None of these are alerting problems - they're systems and data engineering problems that happen to live inside a security team.
That points to detection engineering shifting from rule-writing toward platform thinking. Teams increasingly need engineers who are as fluent in data pipelines and observability as they are in attacker TTPs. And on the commercial side, sellers need to talk about coverage gaps and mean-time-to-remediation credibly - this is a technical sale, not a standard SOC pitch.
Bottom Line
Across every conversation, the same conclusion kept surfacing: the next generation of AI SOC tooling won't be won by the flashiest alert copilot. It'll be won by whoever engineers the trust and data infrastructure agents actually need to be useful. Three founders, three different bets - observability, coverage automation, and context - all converging on the same point: fix the engineering foundation first.
Building the next generation of AI SOC or detection engineering tooling? Reach out to Aspiron Search to find the talent that gets you there first.