Agents can run your detection lifecycle. Can your data platform keep up?

Every security team eventually runs into the same problem. Detection coverage never quite matches the environment it's supposed to protect, because the environment never stops changing: new cloud services, multiple IAM roles created, new SaaS connections, all quietly outdating detection rules written eighteen months ago. The list of things worth detecting keeps growing too, faster than any team can write rules for them. Closing that gap takes detection engineers and analysts who understand both the threat landscape and the messy data each environment produces.

That's why AI agents in the SOC are becoming the obvious next step. Plenty of organizations have already shipped agents that triage alerts and suppress false positives. This post is about the next frontier: agents working in orchestration to manage the full detection lifecycle. One agent finds coverage gaps, another tuning a brittle detection or drafting a new detection. A third picks up the investigation the moment one fires, pulling the thread, scoping what happened, and hunting for related activity before an analyst ever opens the alert.

The idea is sound. The problem is that most of the infrastructure and tools security teams already have, homegrown or the legacy SaaS platforms they already pay for, was never built for it. Running agents on top of it fails to deliver the promised value and can actively make things worse.

The constraints already holding detection engineering back

Before agents even enter the picture, it's worth being honest about why detection creation and maintenance is so challenging today.

1. Cost is the first constraint, and it shapes everything downstream. Most legacy SIEM pricing scales with the volume of data ingested, and the architecture underneath does nothing to curb that as volume grows. The result? Ingesting even a single high-volume log source (cloud audit trails, network flow logs, endpoint telemetry) can run from the low hundreds of thousands to over a million dollars a year. Faced with that bill, teams ration what they collect and how long they keep it. Detection engineers writing rules, and the analysts and hunters investigating what those detection rules turn up, all end up working against a partial, short-lived view of the environment, which means blind spots aren't a possibility, they're a guarantee. Some platforms have tried to dodge that bill entirely by moving onto cheaper object storage instead, trading dollars for speed. That’s a trade that's painful for the team running occasional queries against it, and, as we'll see, a lot more painful once agents are the ones running it.

2. Tuning is a full-time job that never finishes. A detection that fires correctly on day one drifts out of tune as the environment changes underneath it. It can be a new deployment pattern, a renamed service account, a SaaS vendor changing its log schema. Left untouched, detections either go silent or start generating false positives, and false positives are corrosive. They consume analyst attention, erode trust in the detection layer, and eventually get muted or deleted rather than fixed. Multiple industry surveys on SOC alert fatigue point to the same pattern: a large share of daily alert volume in a typical SOC is noise, and analysts spend a disproportionate amount of their time chasing it down rather than investigating real threats.

3. Resourcing is the third constraint. Detection engineering requires people who can write correct, efficient queries against a specific data platform and also understand adversary tradecraft well enough to know what to look for. That combination is rare, expensive, and unevenly distributed. Most security teams are perpetually behind on their detection backlog, not because they don't know what to build, but because they don't have the time and hands to build it.

4. There's a fourth constraint that compounds the first three, and it's easy to overlook because it happens downstream of the detection itself: every detection that fires generates work. An alert isn't the end of the process, it's the start of one. Is this actually malicious, how far did it spread, has this identity or indicator shown up anywhere else in the environment? That triage and hunting work is exploratory by nature. It involves pulling months of history for one account, correlating across several log sources instead of one. It's also the work most existing platforms are worst equipped to support quickly, which means the noisier detections are, the more investigative debt piles up behind them.

5. The fifth constraint is the most mechanical of the bunch: most platforms limit how many detections can actually run at once. Push past that ceiling and detections don't just run slower, they could get blocked from being created, get skipped or delayed outright: a scheduled search that never fires is a missed alert. Teams live with this today, coverage capped not by what they've written but by how much of it the scheduler can actually get through in a given window. This problem only gets sharper once agents are the ones waiting on those alerts to know when to act.

Put those five together and you get an industry-wide pattern: detection coverage, and the ability to act on it, is capped not by what teams know they should detect, but by what they can afford to ingest, tune, staff, run, and investigate, and by technical limitations of their SIEM.

Why agents are a genuinely good fit for this problem

Agents are well suited to the parts of this problem that are hardest to keep up with. An agent doesn't get bored re-reading the same log schema for the tenth time, doesn't need to context-switch between customers or business units, and can hold far more of an environment's baseline behavior in view at once than any individual analyst.

Concretely, that means agents can continuously diff the current environment against known detection coverage and flag the gap: a new AWS service showing up in CloudTrail with no corresponding detection, an OAuth grant pattern nobody has written a detection for. They can map existing detections to a framework like MITRE ATT&CK and surface exactly which techniques are covered and which aren't, turning "do we have a detection for this?" from a research project into a lookup. They can watch a detection's true/false positive ratio over time and propose a tuned version, and they can draft new detection logic directly from a threat intel report or an incident postmortem, in the query language the team already uses, ready for a teammate to review rather than write from scratch.

The same qualities make agents just as well suited to the other half of the lifecycle: what happens once a detection fires. The moment an alert comes in, it can be handed to an agent working investigation, whether that's the same agent that wrote the detection or a different one built specifically for triage and hunting, to pivot straight into it: pulling the account's or host's recent history, checking whether the same indicator turns up anywhere else in the environment, and either closing the alert with a documented rationale or escalating it to a teammate with the scoping work already done. Done well, that loop doesn't just clear the queue faster; it feeds back into detection quality, because every investigated alert is evidence of whether the detection that produced it is worth keeping, tightening, or retiring.

All this requires the agents working the problem together, to be relentless, and to have enough visibility into the environment. This is where things get interesting, and where most existing security data platforms start to show their limits.

The problems agents create when the platform underneath them can't keep pace

An agent that's good at proposing detections has a critical side effect: it proposes a lot of them. Left unchecked, an agent-driven detection lifecycle doesn't converge on tight coverage; it produces detection proliferation. New, slightly-overlapping detections accumulate fast, and the review burden that was supposed to shrink with agents ends up growing instead, shifted from "write the detection" to "audit whether the agent's detection is any good."

The math gets worse once those detections start firing, because proliferation on the creation side multiplies proliferation on the investigation side. Every detection that trips doesn't just log an alert. If the agent is doing its job, it kicks off a real investigation, and a thorough one might mean a dozen or more ad hoc queries across different log sources just to scope what happened. This is usually where platforms actually buckle under an agentic workflow, not at the point of creating a detection, but at the point of running many of them in parallel and triaging and hunting against everything they produce, at scale.

That volume runs straight into a resource ceiling most platforms were never designed to lift: detections and ad hoc queries usually draw on the same compute pool, a cluster of indexers or search heads sized for a predictable, analyst-paced workload. Every detection evaluated continuously is compute resources that the analyst pulling a manual timeline, the engineer testing a new query, or now the investigating agent, doesn't get, and vice versa. That shared pool caps exactly the two levers agents need to turn up: how many detections can run in parallel, and how frequently any one of them gets re-evaluated. Push either number up and interactive query performance degrades for everyone else on the platform, so it ends up being the platform's compute ceiling, not the agent's judgment, that decides how much coverage and how tight a re-check cadence a team can actually run. Because most agents work by reacting to detection notifications, a detection that gets skipped or delayed at that ceiling isn't just a missed alert, it's a missed trigger: the agent never gets the signal it's built to act on.

Underneath both the proliferation problem and the investigation-overload problem sits a common issue: agents need context on two axes. The first is depth: to tell whether a login pattern is anomalous, an agent needs to know what normal looks like over months, not the fifteen or thirty days most teams can afford to keep hot and searchable, and to validate a new detection or run down whether an indicator has shown up anywhere else, it needs a year of history, not just the log where the alert originated. The second is breadth: agents inherit the same cost-driven rationing problem that caused the coverage gaps in the first place, and it lands on them much harder, because triaging a single detection usually means correlating across several log sources at once (identity logs, network logs, endpoint telemetry) and closing a coverage gap means the same thing: visibility into a log source no detection currently touches, not just more of the ones it already has. On most platforms, teams end up rationing the exact data access that would make their agents good. The constraint never went away, it just moved up a layer, onto agents that need far more of it than any analyst did.

Query latency compounds this in a way that's easy to underestimate. Agentic workflows are inherently iterative: propose a hypothesis, run a query, look at the result, refine, run again, and that loop runs just as hard during a hunt as it does while validating a new detection. If each query takes even a couple of minutes more, a workflow that should take seconds turns into a coffee-break-length wait, and agents either stall out mid-investigation or fall back on smaller, less rigorous samples of data to keep the loop fast. Either way, the quality of what the agent produces degrades, not because the agent is bad at its job, but because the platform underneath it can't keep pace with how agents actually work.

Why Scanner is the missing half of the equation

This is the gap Scanner was built to close, and the architecture matters here, because "move to object storage to cut costs" isn't a novel idea. Some security data platforms have already made that move, running ad hoc queries directly against data sitting in S3 to escape SIEM ingestion bills. Scanner’s architecture is built on these things working together:

• Cost is the first piece: cheap object storage economics, without the tradeoff we flagged earlier. Object storage is cheap precisely because it isn't indexed for fast lookup, so on most platforms the move that fixes the cost problem reintroduces it as a speed problem. Scanner avoids that tradeoff entirely, which is what makes full-history context economically viable for an agent in the first place, instead of a nice-to-have teams can't afford.

• Speed is the half most object-storage alternatives sacrifice to get the cost savings, and it's the half Scanner refused to give up. Scanner's compact indexing (roughly 15% the size of the raw log volume) and parallel, serverless query execution are built to search petabytes in seconds rather than tens of minutes; this architecture allows for order-of-magnitude faster performance than other query engines. That's the difference between an agent's propose-query-refine loop taking seconds and taking half an hour. That's not an incremental improvement to an engineer's workflow; it's a different workflow entirely, and it's the workflow an agent needs to validate its own output before proposing a detection to a teammate.

• The third piece is what actually solves detection proliferation scalability issues rather than just tolerating it: Scanner runs detection queries continuously against the live data stream using cached data sets, rather than as a scheduled batch job against the main index. Because detections run as cheap, parallel, streaming evaluations instead of periodic full scans, the platform can support thousands of concurrently active detections without the limitations that make most SIEMs buckle well before that scale. That changes the economics for an agent proposing detections: writing a lot of narrow, well-scoped ones instead of a few broad, noisy ones stops being a liability and becomes the more efficient pattern. That same parallelism is what keeps the other half of the loop from becoming the next bottleneck: when a burst of detections fires at once, an agent can run the resulting investigations as a batch of parallel queries rather than working a backlog. A burst of continuously running detections doesn't slow the analyst, engineer, or agent running an ad hoc query at the same moment, and running more detections more often doesn't mean rationing capacity.

Scanner also meets agents where they actually operate: it exposes a native MCP server and a full API surface, so an agent isn't working around the platform to get at the data, it's a first-class client of it. In practice that spans the whole lifecycle: natural-language investigation, automated migration of legacy detection logic into Scanner's query language, detection-gap analysis mapped using frameworks like MITRE ATT&CK, automated alert triage that contextualizes a trigger and suppresses the false positive on the spot, and IOC-based threat hunting that takes an indicator from one alert and correlates it across years of logs in a single pass. All of it runs against lightning-fast, low-cost queries, lifting the constraints legacy platforms' pricing and performance effectively impose on the kind of exploratory, iterative querying this work requires by nature.

The combination that actually delivers on the promise

None of cost, speed, or streaming execution alone gets a security team to the outcome agents promise. Cheap storage without fast queries just gives an agent a large, slow archive to be blind inside of, which is exactly where most object-storage-based alternatives land, and exactly why "we moved to a data lake" hasn't been enough to let agents run the detection lifecycle on its own. Fast queries without the ability to run as many detections in parallel as the environment actually needs (alongside all the ad hoc querying analysts, engineers, and other agents are doing at the same time) just means the agent can find a gap quickly and then can't afford to watch for it continuously, or investigate everything it finds. Only the combination gets a team there: retain everything, query any of it in seconds, and run both the detections and the investigations they trigger in parallel. That is what turns "an agent that manages your detection lifecycle" from an appealing pitch into something a team can actually run in production.

That's the real shift underway. The constraint on managing the detection lifecycle was never a shortage of good ideas about what to detect; it was a shortage of context, speed, and resources to act on those ideas, and to follow up on them, at the pace an environment actually changes. A platform built around fast, full-history queries and massive parallel execution removes limitations. The detection lifecycle stops being something a team maintains in spite of its tools, and starts being a closed loop it runs continuously: detect, investigate, tune, detect again, at a scale that finally matches the environment it's meant to protect.