AI is everywhere in cybersecurity marketing right now, but according to Monzy Merza, Co-founder and CEO of Crogl, most of it doesn’t survive contact with a real investigation. In this VMblog Q&A, Merza pulls back the curtain on what he sees as an industry built around staged demos and dashboards that reshuffle the same fragmented data rather than reduce the burden on analysts. He argues that the real failure isn’t a lack of AI horsepower, but a refusal to confront the structural problems that have plagued security operations centers for years: siloed knowledge, tool sprawl, and a workforce that never accumulates institutional learning because “there is no such thing as a security team,” just individuals running parallel races.
Merza’s answers range from the technical to the philosophical, touching on why vulnerability severity scores fail without environmental context, why data sovereignty is a non-negotiable requirement for the critical infrastructure clients Crogl serves, and why he believes the traditional three-tier SOC model is a relic organizations must abandon to survive an agent-driven threat landscape. He also explains the reasoning behind Crogl’s decision to release a free, enterprise-grade version of its platform, a move he says lets practitioners test the company’s claims against their own data in an afternoon, rather than taking a vendor’s word for it. What follows is a wide-ranging conversation on where AI genuinely moves the needle in the SOC, and where the industry still has work to do.
++
VMblog: AI is dominating cybersecurity conversations. Where is AI creating real value in the SOC today, and where is the hype getting ahead of reality?
Monzy Merza: Start with where it isn’t. Vendors are selling “AI-powered” as a UI feature. Demos that show investigations in 30 seconds are so detached from the retrieval-bounded reality of investigation workflows. No wonder the security community is skeptical. Dashboards with multilayer drilldowns that look pretty but surface the same data. Chatbots sitting on top of a SIEM. But can’t do federated querying across multiple fragmented schema, data lakes
I have talked to so many people that believe they can build their own AI SOC capability. And I see unfortunate, foundational mistakes. I see this from startups as well as in house devs. I presented on this at Black Hat in 2025. I have written articles on this. These efforts are failing because they aren’t helping the analyst. Analysts are still making the same triage decisions, still unable to exercise their intuition, still stuck on query writing and results synthesis.
We do see value in some areas. The real value shows when the AI system understands the organization’s data. Once that happens, the AI agent can do investigations that accelerate the investigative workloads. Another area is in documentation. The agents can document the analysis. Analysts don’t like to document. So AI is very helpful in audit and data call situations.
Document understanding. Imagine a 20+ page CISA advisory. Its challenging to parse it, get the IOCs. Or imagine you have a hundred or so log lines and an analyst wants to graph out the connections. AI is good at that.
AI agents are good at handling data that was never going to normalize. Enterprise data is fragmented, and it is not going to un-fragment. Systems that can reason over data wherever it sits are solving a problem that a decade of integration projects did not.
The community is drowning in AI hype. But trying AI SOC products is gated by most companies. Not Crogl. We made Crogl free to download. Practitioners can download it, it’s free, they can see it for themselves inside an afternoon. The industry has trained people to evaluate AI security tools through a demo, and a demo is the easiest thing in the world to stage.
VMblog: How is AI changing the day-to-day role of security analysts and the skills teams need to build the SOC of the future?
Merza: It’s about outcomes. And what analysts are working on and what they are not working on anymore.
This is a bit of an editorial, but let’s look at how most SOCs work before we talk about the future. First, today, security teams are not really teams. SecOps practitioners are individuals running parallel races. One analyst’s breakthrough doesn’t make the next analyst faster. Learning leaves as people leave. A decade of tooling has been built on top of that arrangement instead of fixing it. What is the arrangement? Three silos. Domain knowledge: different analysts are good at different tasks. Their task silo is a self fulfilling prophecy. Bob is good at analyzing phishing so he gets more phishing tasks, and soon his networking skills atrophy. Tool competency: Sally is really good at writing SIEM queries and she knows all the nuances, where are the broken schemas, where the timestamps are off. In a SOC with 30+ tools. It’s impossible for analysts to keep up. Third, organizational processes hold back analysts from exercising their intuition because of poor integrations, lack of access or policy restrictions.
AI has the opportunity to compress these problems. An agent can write queries. An agent can read docs and help analysts exercise their intuition, an agent can identify gaps so analysts can get access to the right tools or make policy change recommendations.
As agents get better, human skills have to shift. Analysts have to learn the nuances of various agentic systems. Models have prompt nuances and running multiple agents and subagents is an art and a science. Analysts need practice with these scenarios. There will be more agentic AI security use cases in the future. Just like there were new use cases with cloud tech. Analysts have to skill up. And lastly, I strongly believe analysts will want to improve their programming skills. Agents are really good for code generation. So a human with a strong foundation will be a better agent supervisor.
VMblog: Alert fatigue has challenged SOC teams for years. Is AI solving the problem, or simply changing the way analysts manage risk?
Merza: It’s a signal to noise problem. Everyone will say alert fatigue. But alert fatigue is a symptom. Learning, collaboration loops and data fragmentation are the environment that creates it. Most AI in the SOC today is treating the symptom, which is why teams feel busy in a new way rather than less overwhelmed.
If your system produces another alert, another score, or another dashboard, you’ve just added another thing to monitor. The analyst is no better off. Reordering a queue is not the same as reducing what has to be processed.
Measurement made it worse. The industry runs on mean time to detect, to respond, to whatever. Those metrics only count what you caught. There’s no timer on the alert you never wrote or the data source you never onboarded. A team can post excellent numbers while the actual exposure sits outside the frame.
What would count as solving it: the volume the analyst personally has to reason through goes down, and the SOC accumulates understanding so the same investigation does not get run from scratch every time. Short of that, we are managing fatigue, not removing it.
There are a lot of opportunities in this area. But I think most AI SOC companies have pricing models that deter usage and magnify the issue because they charge by investigation.
There will be more alerts in the future. One because the footprints expand and two we are at an AI inflection point. Just like with the cloud inflection. AI has the opportunity to reduce the noise for the analyst.
VMblog: Vulnerability management is becoming a core security operations function. How can AI help teams prioritize the vulnerabilities that truly matter?
Merza: I suffered the pains and thrills of large-scale vulnerability discovery and management earlier in my career, and the core problem has not moved: severity scores are a property of the vulnerability, not of your environment. A critical CVE on an isolated system you can patch next quarter is not the same finding as a medium on an internet-facing service or an internal dependency service. The score cannot tell you the difference. But a blast radius assessment on your data can.
That is where AI is useful and also where it gets oversold. Prioritization is a retrieval and context problem before it is a reasoning problem. To rank a finding properly you need to pull in asset ownership, secondary, tertiary dependant identities, dependent services, compensating controls, and what your detection coverage looks like on that system. That context lives in a dozen systems that were never designed to talk to each other. A model cannot reach that data. An agent can but the agent has to have some semantic tooling so the fragmented data can make sense.
What an organization knows about itself doesn’t commoditize. The needs are unique, the threats are unique and the customer knows best. Applied to vulnerability management, that means the useful system is the one that reasons over your environment, not the one with a better default scoring algorithm.
The moment this gets tested is when something newly disclosed lands and the whole industry is asking the same question at once: are we exposed, where, and how badly. That is one of the exact scenarios we built the free version of Crogl for. A team should not be opening a procurement conversation to answer that question. Download it, connect it, and start working the problem against your own environment.
VMblog: With threats moving faster and security teams facing resource constraints, can AI help organizations do more without simply adding more tools and people?
Merza: That question is the reason Crogl exists. Our mission is a rather absurd proposition: build a product to enable every practitioner to be as effective as the entire team.
Most AI deployments are adding a tool, not removing work. The bigger misconception underneath all of this is that “human in the loop” has become a design excuse. A lot of poor software is built with brittle integrations and poor process context. The human is left to fill in the gaps left by inadequate software. If you haven’t reduced what that human has to process, you’ve just moved the bottleneck.
The test I’d give any buyer is: After deployment, is there a category of work your analysts no longer do? Not do faster. No longer do. If the answer is no, you bought a tool.
Commitment to service is also why we launched the first free enterprise-grade AI SOC product, giving security teams immediate access to advanced investigation capabilities during a breach without a sales cycle. When an incident hits, no one has time for a procurement cycle. A team under resource pressure should not have to clear a purchasing process to get help mid-incident. Download Crogl, connect it, investigate.
The free version is deliberately a single-analyst deployment. So it’s fast to install, fast to get outcomes. One person running workflows that used to take a team, compressing hours into minutes. If the premise is real, it should hold up with a headcount of one. It’s a hard claim but an easy one to verify. We aren’t perfect but we are energized by our customers and we want to serve the community.
VMblog: As enterprises adopt AI in security operations, how should they think about data privacy, governance, and sovereignty?
Merza: Table stakes and non-negotiable. We serve critical infrastructure clients. The data these orgs use to run security operations is a map of their defenses. The alerts and responses are the stuff of movies where the bad guys sort their victims. What happens in an AI SOC system shows what defenders watch, what they don’t, how they respond, where they have gaps. Sending that outside the perimeter is a privacy and a strategic consideration.
Then there’s an availability time bomb for many SOCs who rely on a single AI provider. If your investigation capability lives behind someone else’s API, their outage is your outage, their rate limit is your incident response, and their model deprecation is your rebuild. So for our critical infrastructure enterprises, the sovereignty, governance, privacy requirements quickly turn into operational continuity requirements across their entire stack.
We chose to build a sovereign system. Investors were brutally critical of us. But we wanted to be non-SaaS, to give customers full control over their data and the reasoning applied to it. It’s a principle that guides every architectural decision we make. We did this because of our commitment to serving the most consequential organizations in the world. Banks, energy companies, the US DoD and intelligence community. Many Croglers come from that community. We left our badges behind but our commitment to serve is constant.
Data sovereignty in AI-powered security requires architectural commitment and resisting the temptation of monetizing customer data. We won’t be toggle buttoning that.
The free version we released holds to the same architecture as the paid one. Crogl runs where the data runs, on-prem, in customer cloud, or fully air-gapped, and nothing leaves the environment.
VMblog: How much autonomy should organizations give AI in the SOC, and where will human expertise remain critical?
Merza: The autonomy framing is slightly the wrong axis. The question I’d ask is what the system is allowed to conclude versus what it’s allowed to do, and whether you can see how it got there. Humans will always be critical but human effort/attention shouldn’t always be the gate.
Generative systems are fantastically capable. But it’s very difficult to enforce consistency on these technologies. In security operations, consistency and repeatability are table stakes. SecOps needs both: determinism and reasoning in a single system. Well understood processes can be handled with high accuracy and speed with symbolic methods. Layer in language models, add a constant learning loop, and an orchestration system to flow the task to an outcome. Autonomy should track that split. The deterministic parts can run without a person watching. The reasoning parts need to show their work.
A useful system is one that shows its reasoning so the analyst can validate or challenge it or leave it alone. Autonomy without transparency is just unaccountable output.
Human expertise stays critical exactly where intuition operates. The analyst who looks at a well-supported conclusion and says “that’s not how this environment behaves” is doing something the system cannot. That is why prioritizing human intuition is one of our founding principles.
Autonomy is also not something a buyer should have to decide in advance, on the strength of a vendor’s assurances. That’s part of why we put the platform out for free. An analyst can watch it work in their own environment, on their own data, and calibrate how much rope to give it based on what they observe rather than what we claim. Trust in this category gets earned through use.
VMblog: What gap in traditional security operations led to the vision behind Crogl, and what does the future AI-native SOC look like?
Merza: Crogl started in my head on a customer call. “We will never put all our data in one place.” I had heard that before but hadn’t listened to it. Enterprise data is fragmented and it isn’t going to un-fragment. Then two more gaps: leaders complain about a lack of security talent, but what they are complaining about is a unicorn shortage. And the one that hurt most, there is no such thing as a security team. One analyst’s work doesn’t benefit the other. Learning leaves as people leave.
That led to our impossible mission: build a product to enable every practitioner to be as effective as the entire team. It’s an absurd proposition, so we broke it down to first principles. Sovereignty, extensibility, and prioritizing human intuition. A knowledge system that reasons over security data wherever it sits, inside an environment the customer fully controls.
The AI-native SOC isn’t defined by how much AI is in it. It’s defined by whether the organization gets smarter. Today the SOC doesn’t accumulate understanding. Unlike sports teams, a security team doesn’t get better with more engagements with its opponents. That must change. The future belongs to organizations that maintain control of their data and deployments, extend the security investments in people and tech and can scale AI with predictable economics.
Someone asked me today how Crogl fits in the contemporary three tier security operations model. It doesn’t. You might not like my answer. Organizations need to free themselves from the relic of the three tier or they are doomed in an agent driven threat environment. Crogl exists so the three tier model doesn’t have to.
##
