Cutting 90% of the Noise: Agent-Driven Security Operations

There are two standard responses. Hire another analyst, or tune detections until the volume fits the staffing.

The first is expensive and temporary. The second deserves more attention than it gets, because of what it actually is: a decision to set your visibility from your headcount. Nobody writes that down. It happens one suppression at a time, in a change ticket, and the detection you turned off is the one you will be asked about.

On one engagement we removed L1 findings triage and prioritisation entirely by wiring agents to Amazon GuardDuty and the customer’s third-party monitoring SaaS.

The number is the easy part of this post. The design underneath it is the part worth arguing about, because the naive version of the same architecture is genuinely dangerous.

L1 looks like a staffing problem, which is why it never gets fixed

Staffing problems have a known remedy, and reaching for a known remedy feels like progress. That is the trap.

What makes a finding actionable is almost never the finding. It is context that lives somewhere else: what this resource is, who owns it, whether it is production, whether the behaviour is normal for this workload, whether it correlates with three other findings from the same hour, whether a change window is open.

An L1 analyst spends their shift moving that context by hand, across consoles, and then makes a judgement that the context has largely already made for them.

Once you see it that way the automation target changes. You are not automating the analyst’s opinion. You are automating the freight.

Three layers, separated by what each may get wrong

The design that worked separates three things that most teams ship as one. The useful axis for separating them is not capability. It is permitted error.

Agents enrich and correlate. They gather context, pull ownership and tags, look for related findings, and describe what happened in the resource’s own terms. This is research, and research tolerates error. An agent summary that is 90% right still puts an analyst thirty minutes ahead. Non-determinism is acceptable here for exactly one reason: nothing is decided.

Deterministic rules own disposition. Suppress, escalate, or route is decided by rules evaluated against the enriched record. Not by the model. This is the load-bearing decision, so it has to be reproducible, reviewable, and explainable to whoever asks why a finding was closed. If you cannot answer “why was this suppressed?” by pointing at a rule, you have built a system that loses findings politely.

Humans own escalation and the rule set. The team’s work moves up a level: the 10% that matters, and ownership of the rules that produced the other 90%.

That second half is the one everyone skips, and it is not a nice-to-have. It is the entire safety mechanism. Without it you have an unattended classifier with your logo on it.

What 90% actually means

I am careful with the wording because the claim is easy to inflate, and I have heard it inflated.

It does not mean 90% of findings were false positives. It does not mean we deleted 90% of the detections.

It means 90% of findings no longer need a person to reach a disposition, because enrichment plus a deterministic rule reaches it. Those findings still exist, are still recorded, and are still queryable. What changed is that they stopped consuming attention.

That distinction is the whole difference between an automation programme and an outage with a lead time. Six months from now, someone will ask why a specific finding was auto-closed. If you cannot reconstruct the answer, you did not reduce noise. You hid it, and you will find out on the worst possible day.

The failure modes worth naming

What it costs

Someone has to own the rule set, and that someone is senior. You have moved effort from a shift pattern to a backlog, which is a better place for it but not a free one — and it is now visible to whoever plans your capacity.

You also inherit a new dependency. When the enrichment layer degrades, the deterministic rules are evaluating against thinner records, and a rule that was correct on a full record can be wrong on a partial one. That failure is quiet unless you instrument for it. Fail closed: an incomplete record escalates rather than resolves, which means your 10% grows on exactly the days you are least able to absorb it.

And this only pays above a volume threshold. Below a few hundred findings a day, the rule set costs more to maintain than the triage it replaces, and a spreadsheet plus a competent analyst wins. I have recommended the spreadsheet.

How you know it is working

Two signals, neither of which is the noise number.

The first is that the escalation queue gets harder. If the 10% reaching your analysts still contains obvious work, the rules are not doing their job and the number is flattering you.

The second is that rule changes come from analysts rather than from engineers. That is what ownership looks like from the inside, and it is the only version of this design that survives its first year.

Why I keep building in this space

This work is why the open-source tooling I maintain looks the way it does.

Secrust exists because the real signal lives in correlation — many failures, then a success, for the same principal — where no individual event is suspicious. Watari exists because once you have narrowed to the meaningful 10%, the case management around it should not be the expensive part of your stack.

Both are built on OCSF for the same reason the enrichment layer above works at all: one schema is what makes automated context assembly tractable. A bespoke parser per source is how these programmes die — not from a hard technical problem, but from an integration surface growing faster than the team.