In Conversation with Monzy Merza on the Rise of the Agentic SOC

The Crogl CEO on architecting the Agentic SOC to deliver measurable AI value while ensuring sensitive security data never leaves the building.

As the cybersecurity landscape shifts from simple threat detection to a complex battle of automated reasoning, the industry is reaching a critical inflection point where more data no longer equals more security. Monzy Merza, the CEO of Crogl, is the architect behind one of the most significant responses to this shift: the move toward sovereign, agentic AI. With a career defined by high-level research and global strategy, Merza founded Crogl to solve the “physics of the problem” in the agentic SOC (Security Operations Center), focusing on why traditional automation continues to fail under pressure. 

Crogl is now setting a new industry standard by proving that advanced AI doesn’t have to mean data exposure. By deploying a localized Knowledge Engine that keeps sensitive information within an organization’s walls, Merza is delivering the measurable AI value that the industry has long promised but rarely achieved.

We sat down with him to discuss how he is architecting the next era of intelligent, private digital defense.

The inspiration & the mission

The Starting Point: You’ve had a front-row seat to the evolution of cybersecurity for over 25 years, from national laboratories to global tech leadership. What was the specific moment or insight that inspired you to step away from the established path and build Crogl? What was the vision you felt was missing from the industry’s current trajectory?

It was on a customer call. We will never put all our data in one place. I had heard that before, but I never truly listened to it. Enterprise data is fragmented; it is not schematized or normalized. It can’t be. 

Then came the first derivative: competency. Security leaders are constrained by human resource challenges, but it’s not a people shortage; it’s a unicorn shortage. Analysts are expected to understand everything from email headers to APT behavior, to query writing in multiple languages, and to memorize schemas. 

The third one hurt the most: there is no such thing as a security team. Unless you think an Olympic contingent is a team. You have multiple tiers of analysts where one analyst’s work doesn’t benefit the other. One person’s success or failure has no impact on another. Learning leaves as people leave. Analysts work on individual tickets like marathon runners in their own race. There is no team! 

That led to our impossible mission: enable every practitioner to be as effective as the entire team. It’s an absurd proposition, so we broke it down to first principles. The Crogl product is the implementation of that. 

The operator’s reality

The industry has been chasing automated defense for years, yet SOC efficiency remains stagnant. Why is the human-in-the-loop model still struggling to scale? 

Because 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 of the inadequate software. The human should be in the loop to retain accountability, but if you haven’t reduced what that human has to process, you’ve just moved the bottleneck; you haven’t eliminated it. 

The second issue is an intellectual sleight of hand. Human-in-the-loop is a false requirement in the absolute. There is no PBX operator in the loop for a phone call; even the TSA has touchless security checkpoints now. Well-understood processes should not have humans in the loop. That’s counter to a human’s cognitive strength. 

Scaling isn’t a headcount problem; it’s a resource allocation problem. Apply humans to vague and nuanced tasks. Machines should work as advertised. 

The persistence of alert fatigue

The Automation Gap: We’ve had SOAR and automated playbooks for years, yet analysts are still overwhelmed. Why hasn’t traditional automation solved the alert fatigue problem? 

Learning. Rote, brittle automation is like a sprinkler running on a rainy day. Automation operates without understanding. A playbook can tell a system to quarantine a host, but it can’t tell an analyst whether that host matters, why this pattern is different from yesterday’s noise, or what the attacker is likely doing next. 

SOAR has another structural flaw: it relies on having well-structured, normalized data and assumes workflows can be cleanly templated in advance. The real world, well, it rains. Alert fatigue is a symptom. Learning, collaboration loops, and data fragmentation are the environment. Analysts are making triage decisions under time pressure without fast access to the knowledge that would make those decisions obvious. You can automate every downstream action perfectly, but you’ll just have more work. Traditional automation optimized the response layer and left the learning and reasoning layer entirely to humans. Transitioning to an Agentic SOC means closing that gap by allowing the system to actually understand the environment it’s defending. 

Contextual Reasoning: You often speak about the physics of the problem. How does moving from hardcoded IF/THEN rules to AI-driven reasoning change the way an analyst actually experiences their workday? 

The analyst’s daily activities are riddled with constant cognitive switches: absorbing new information, relating things, learning, and performing tasks. They follow rules, policies, and runbooks, and they have to use their own intuition to reason through problems. The tools have to match the operators; the tools must match the physics. 

This isn’t an “OR” question. It’s an “AND”. SecOps needs both: rules (symbolic) and reasoning (neuro) in a single system. We’ve always talked about Crogl as a neuro-symbolic or a compound system with connectionist and symbolic logic. Analysts need both capabilities. Well-understood processes can be handled with high accuracy and speed using symbolic methods like if/then, and graphs can hold an organization’s knowledge maps. 

Layer in language models, and now we start edging closer to the analyst’s requirements. Then we need an orchestration system to flow the task to an outcome by leveraging that neuro-symbolic system. Add a constant learning loop, and we have an analyst assistant. Now we can have an impact. A human analyst can handle two dozen alerts in a day, but they might see 4,500 in that same period. With a system like this, we fundamentally change the analyst’s job. 

AI: Delivering value in the agentic SOC 

The Value Filter: In 2026, where is AI actually delivering measurable ROI in the SOC, and where is it currently falling short of the marketing promises? 

Real ROI right now is in autonomous investigation. AI that can take an alert, pull context from multiple sources, correlate it against known TTPs (Tactics, Techniques, and Procedures) and asset history, and hand the analyst a documented finding. That’s measurable. You can count the hours. You can count the coverage. 

Where it’s falling short: everywhere vendors are selling “AI-powered” as a UI feature. Summarization that saves an analyst 90 seconds, dashboards that look smarter but surface the same data, or chatbots sitting on top of your SIEM, that’s not ROI. That’s driving around in a circle; you’re going really fast, but not going anywhere. 

The filter I’d apply is: does this AI do investigative work, or does it dress up the same workflow? If your analysts are still making the same triage decisions with the same incomplete context, the AI isn’t delivering. It’s decorating. Many security leaders are trapped by the survivorship-bias metrics of Mean Time to X (MTTx). Well, there is no MTTx for something you don’t see. There is no MTTx for data gaps that were missed, and there is no MTTx for use cases that you aren’t alerting on. Many AI tools are chasing MTTx without appreciable outcomes. 

Human Elevation: A key goal of agentic AI is to help analysts work faster. How do we design these systems so they truly elevate the human analyst rather than just creating another “black box” to monitor? 

You design for outcomes, not outputs. If your system produces another alert, another score, or another dashboard, you’ve just added another thing to monitor. That’s not elevation. 

To elevate the analyst, the system needs to take on the investigative workload: gather context, test hypotheses, document findings, and present a conclusion with supporting evidence. And it needs to be transparent. Not a black box, but a system that shows its reasoning so the analyst can validate or challenge it. The goal isn’t to replace humans; it’s to let humans spend time on judgment, not data assembly. 

The Knowledge Engine: How does the concept of a knowledge engine differ from the traditional way we store and query security logs? 

A traditional log store answers questions you already know to ask. You write a query, you get records. The intelligence sits in the query, which means it has to be in the analyst’s head before they start. Every data store has its own schema and its own query language. Analysts are expected to be experts across forty-plus tools at once. That’s a design problem. 

A knowledge engine builds a semantic layer across heterogeneous data sources without requiring normalization. It’s a data-to-use-case map. It works where the data lives. Underneath, this is a neuro-symbolic architecture: machine learning to reason about meaning and relationships, paired with a symbolic layer that makes every step auditable, repeatable, and inspectable. The system connects an identity event, a network anomaly, and a threat intel record in real time, and shows its work. 

The operational difference is that you stop designing the SOC around the assumption that analysts can hold institutional knowledge in their heads. In a true Agentic SOC, the knowledge lives in the system. Crogl handles the investigation; the analyst makes the call.

Emerging risks: Third-party AI & data sovereignty 

The Exposure Risk: As Agentic SOC integrates more third-party AI tools, what are the hidden risks regarding sensitive telemetry and data exposure that CISOs should be worried about? 

It’s en vogue to talk about AI data risks, but only a handful of organizations really put their money where their risk is. There are obvious risks with data leakage of security alert data, the AI provider being breached, or an unresolved alert due to a SOC’s fear of running up costs. Most AI SOC tools charge by investigation volume, which acts as a direct deterrent to investigating every alert. 

Then there is the “A” (Availability) in the CIA model of security. Outage issues have stalled many organizations in non-agentic SOC scenarios. SOCs that are reliant on a single AI provider, or a SaaS provider that is reliant on a single AI provider on the backend, are sitting on an availability time bomb. 

Finally, there is accountability. Historically, security vendors have not been held responsible for their software’s failures. With agentic SOC, especially a fully automated system, there is a risk that the system incorrectly deems an alert benign. If that AI system is a magic box, the organization has even more problems. 

The Sovereign Architecture: You’ve advocated for Your Data Never Leaves models. Why is data sovereignty becoming a non-negotiable requirement for modern security infrastructure? 

Because the data you use to run security AI is a map of your defenses. It shows what you watch, what you don’t, how you respond, and where you’re slow. Sending that outside your perimeter isn’t just a privacy consideration; it’s a strategic one. 

Regulated industries figured this out first. Finance, defense, healthcare, they can’t send sensitive telemetry to a vendor cloud and call it compliant. But this isn’t only a compliance argument. Data sovereignty in AI-powered security requires architectural commitment, not just policy promises. That’s why Crogl is not a SaaS. Customers get a completely private, customer-managed environment, air-gapped, on-premises, or cloud, because full control of your risk posture, your alerts, and your semantic knowledge isn’t a feature. It’s the foundation. 

The Model Poisoning Threat: How should organizations protect their proprietary security data from being used to train external models without their consent? 

First, assume it’s happening. Any time proprietary data is used to train or fine-tune external models, you lose visibility into how that data is reused. That creates both leakage and integrity risks. The safest approach is architectural: keep training and inference within controlled environments, and avoid contributing sensitive data to shared models entirely. This isn’t just about protection; it’s about ownership. Your security data is a strategic asset. Treat it that way. 

The road ahead

The SIEM Evolution: Is the traditional SIEM reaching its end of life, or is it simply evolving into a new kind of data layer? 

SIEM isn’t going away, but its role is changing. The SIEM was built to be both the system of record and the system of reasoning. It tried to do both imperfectly because those are two different jobs. The data layer job, ingest, store, and retain, it will keep doing that. The reasoning job, figuring out what the data means, AI is taking that over. 

What you’ll see is SIEM becoming infrastructure while the Agentic SOC layer moves up the stack, closer to the analyst. It changes who controls the stack. The intelligence layer moves up the stack, closer to the analyst, and increasingly doesn’t care what format the data underneath is in as long as it can query across it. Organizations that have spent years waiting to normalize their data before deploying AI are going to find that normalization was never the prerequisite they were told it was. That’s a significant shift in leverage, and it changes who controls the stack. 

Beyond tech: Hard truths and personal passions 

The Builder’s Truth: For the next generation of tech enthusiasts and developers building in the security space: What is one hard truth or piece of advice you’d give them to ensure they are solving real-world problems rather than just building faster horses? 

Go work in a SOC before you ship a product to one. Not for a tour, and not for a demo. Go sit next to an analyst during a busy shift and do what they actually do, not what the requirements document says they do, and not what the CISO described in the RFP. See what happens when the queue is full and the clock is running. 

I did exactly this before building Crogl. I took an operator role, no team, no title, and simply did the job. What I found in that seat was fundamentally different from what I had observed from the outside for 20 years. The graveyard of security startups is full of technically elegant solutions to problems nobody has, delivered in a form the practitioner can’t use. My advice: solve the job as it exists, not as it is described. 

On a lighter note: Outside of tech, what’s the one non-tech hobby or project you’re currently obsessed with solving or perfecting? 

I deeply value learning, building, and serving the security domain. Cybersecurity spans politics, psychology, and physics, and every discipline in between. It is intensely enriching to be in this industry. Outside of that, I am obsessed with food: eating and cooking, especially with my family. We practice recipes from the masters and experiment with everything from Spanish omelets to Lebanese shakshouka.