AI-enabled detection engineering

Not surprisingly, a bifurcated market

Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.

Photo by Zulfugar Karimov on Unsplash

I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:

---

Another week, another take on a security market trying to reinvent itself because of AI. In the past, I’ve talked a lot about the structural failures of detection engineering and traditional security operations centers (SOCs). I’ve been incredibly vocal about why I think building AI SOC agents is the wrong way to go.

AI SOC Automation isn't the right problem to solve

In general, I don’t think traditional SIEMs and SOCs make sense for modern companies anymore. The model made sense when companies had longer deployment cycles, static infrastructure, and predictable rates of change. Today, the velocity of engineering is too fast, which inherently leads to an explosion of telemetry and alerts. Because these alerts are increasingly noisy, security teams spend a substantial amount of their finite resources tuning, filtering, and silencing the noise just to find a reasonable signal. You are burning elite engineering cycles on reacting to alerts rather than proactively fixing the underlying security posture. On top of that, building out a functional SOC has a massive upfront cost, which is a well-known, painful fact among practitioners.

It is no surprise that more companies are abandoning the internal SOC and turning to Managed Detection and Response (MDR) providers. They are likely to work out of the box without requiring a massive initial investment in specialized tooling and headcount. They provide a far better option than legacy MSSPs, where your data and investigations are trapped inside a total vendor black box at a time when you desperately need infrastructure visibility.

Is it managed detection and response (MDR)'s time to shine?

However, it is incredibly hard for these outsourced MDR providers to scale and build custom automations that work across different customer environments. They inherit a long time-to-response loop. While they handle basic, known alerts well, third-party MDR analysts completely lack the internal business context required to accurately judge whether a localized alert is a true incident or a false positive. You end up having to triage the alerts on your end anyway. MDRs provide a bit more visibility than old-school providers, but it is still rarely the deep context you actually want.

Now, we are seeing a whole new class of AI SOC startups emerging, e.g., companies like Prophet Security, 7AI, and Dropzone AI, that promise to drop an autonomous AI analyst straight into your existing queue to fix this triage loop. As I mentioned, I think this entire approach is a bad idea.

These startups are simply optimizing an existing, broken process. They make it faster to sort through a mountain of alerts, but they completely ignore the broader structural question: Does having a dedicated SOC or a siloed detection engineering function even make sense in an AI-native world?

You will never unlock true efficiency gains without fundamentally rearchitecting how your security organization operates. We’ve seen this exact pattern during every major industrial revolution, whether it was the advent of the internet or even the introduction of electricity. The economist Noah Smith wrote an excellent breakdown on this phenomenon before the current AI boom, summarizing Paul David’s work on factory electrification.

Most of the key electrical inventions (light bulbs, generators, AC, etc.) happened in the 19th century…But U.S. productivity growth…accelerated only during the 1920s….[F]actories were very slow to adopt electricity, and industries that electrified early didn’t see big productivity gains til the 1920s.

What happened? In a pair of famous papers in 1989 and 1990, economist Paul David offered an explanation (summarized here by Tim Harford). Basically, at that time, factories used centralized steam power, which was transmitted throughout the factory by a bunch of giant machinery. Simply swapping out a big electric motor for a big steam motor got you a small boost, but not much; it generally wasn’t worth the cost, so if you did this, your productivity would usually go down rather than up.

It was only once factory owners started building entirely new types of factories that they were able to realize the true gains from electricity. Basically, you could put a little motor at each workstation and power it through electric transmission lines. This meant that instead of having to keep a huge machine constantly turning, you could run each little machine only when you needed to. Not only did that save a ton of energy and make factories much nicer and safer places, it allowed workers to do things when they needed to be done instead of adjusting their workflow to the rhythm of a giant machine. That allowed all sorts of flexible production lines that you just couldn’t make with steam power. And productivity followed.

Applying this to cybersecurity risk management, you cannot achieve meaningful efficiency by simply layering an AI agent on top of a legacy steam-engine workflow. You have to change how the machine of the security organization actually works. A lot of modern companies don’t have a detection engineering team or a SOC at all, and they are completely fine. Heavily regulated enterprises will always need them for compliance checkboxes, but most cloud-native companies do not, especially since our core technology no longer lives in a physical datacenter that we fully manage and control.

Instead of buying an AI analyst to sit on top of a bloated Splunk or Sumo Logic instance that requires a massive team to run with completely unclear ROI, a new breed of security data platforms is emerging to solve the underlying storage, infrastructure, and context problem.

The three companies highest on my radar right now are RunReveal, Scanner, and Cotool. (Disclaimer: I am an early user of RunReveal). I’ve spent time looking at all three architectures, and I believe this direction is the correct path forward for AI-native companies that want to skip the SOC entirely.

Security organizations have historically gotten so large and specialized that they created highly fractured teams with divergent goals, completely losing sight of the bigger picture: effectively reducing enterprise risk. These tools fix that by democratizing the security data lake.

Scanner and RunReveal integrate directly with modern, cost-effective data infrastructure. Scanner indexes data directly inside your own S3 buckets without moving logs out of your environment. RunReveal offers a hosted ClickHouse stack or allows you to bring your own cloud storage bucket like your own ClickHouse, S3, or Cloudflare R2. Having a dedicated ClickHouse engine makes data processing and analytical queries substantially faster than running raw full-text searches on S3. Both alternatives are orders of magnitude cheaper than legacy SIEMs that charge an insane premium for cheap storage, forcing you to pay an enterprise software tax on top of what is essentially basic cloud data infrastructure.

From a detection perspective, Scanner and RunReveal both provide out-of-the-box rules. Writing custom rules in Scanner requires working directly in YAML or their proprietary editor, whereas RunReveal takes an AI-forward approach, deploying a native agent that can conversationalize rule creation and perform contextual investigations across your logs.

What makes this approach valuable isn’t immediate, autonomous code remediation. In the real world, the vast majority of alerts are false positives. Detection engineering is an inherently annoying discipline because it requires constant, iterative tuning. What a modern tool like RunReveal actually excels at is handling that triage and tuning lifecycle. When an anomaly triggers, the built-in AI kicks off a localized investigation immediately. If the agent determines the event is a definitive false positive based on historical log context, it can close it out automatically. If it cannot make a definitive call, it flags the alert for a human engineer, but surfaces it alongside all the relevant context and raw data lines required to quickly investigate. This model flips the workflow from chasing ghosts to easily tuning the signal baseline.

Cotool takes a completely different architectural approach. They aren’t trying to build the underlying data lake infrastructure. Instead, they are building a highly focused, programmable AI agent layer that acts as a blue-team orchestration engine. Founded by a technical team out of Material Security, Cotool pairs incredibly well with an open data lake like Scanner, and could potentially advance the investigation capabilities of a platform like RunReveal.

I don’t think the data lake platforms like RunReveal or Scanner are going to swallow the application layer entirely. Having ultra-fast data infrastructure is a separate, intense technical focus. Cotool, on the other hand, is entirely optimized around building an elite blue-team interface. These represent distinct markets and separate organizational priorities. Not every company needs a best-of-breed, highly sophisticated blue team workflow. For many lean operations, having a fast, solid data infrastructure layer is more than good enough.

Furthermore, traditional compliance blockers are becoming less of a concern. Modern pipelines easily fulfill audit obligations because regulators are increasingly looking at whether a team is meeting the actual spirit of what a SIEM is supposed to achieve: visibility, continuous monitoring, and log integrity. You don’t need a legacy enterprise dashboard or a 24/7 human room to prove you are managing log telemetry.

This evolution is exactly what the market needs. Scanner was founded by an infrastructure engineer, so the platform focuses deeply on data lake mechanics. RunReveal was founded by an early Cloudflare security engineer who deeply understands how hard it is for a lean team to set up a detection function from scratch, building an elegant platform optimized for the 80/20 compromise—80% of the security outcome for 20% of the operational effort. Cotool understands how to design an elite blue-team product interface.

These platforms are successfully rethinking how an AI-native company should craft a security team. They recognize that a single generalist or a software engineer with baseline security knowledge should be able to spin up a highly effective detection engineering function without hiring an army of analysts or maintaining a legacy SIEM. By using AI to handle the implementation detail and contextual routing, these tools allow engineers to focus entirely on security outcomes rather than operational busywork.