I let an AI triage my clients alerts for a week. Here’s what it missed.

A real experiment, a real miss, and the specific kind of attack that doesn't show up when you're only looking at what's statistically unusual.

I spent a week letting an AI model pre-triage the alert queue with minimal intervention from me for one of my clients who hired me to automate their triage. So we started building a model and a flow. Ranked by likely severity, auto-close anything it scored as confidently benign, surface only what it flagged as ambiguous or high-risk. I wanted to know, honestly, how far this could go before it broke. So we ran a test, in an actual queue, with actual noise, during an actual week where nothing convenient happened to make the test easy.

Here's what it got right, what it got wrong, and the one miss that mattered.

What it was genuinely good at

Volume reduction was immediate and real. The queue that normally took the first ninety minutes of my morning to get through as I was getting familiar with how their T1 triages alerts dropped to about twenty. Repetitive, low-signal patterns, failed logins from known corporate VPN exit nodes, vulnerability scanner noise from our own authorized scans, alerts from a misconfigured logging rule that's been generating false positives for months, all that got correctly auto-closed without me touching them. That alone is a legitimate, defensible use of the technology. Most analyst time is currently spent on exactly this category of nothing.

It was also decent at correlation. Multiple alerts that were actually one incident, a brute-force attempt followed by a successful login followed by unusual data access, three separate tickets in the old system got bundled into a single incident with a coherent timeline. That's a real time save and a real reduction in the kind of tunnel vision you get when you're looking at alert #2 of 3 without context for #1 and #3.

Where it started to wobble

Anything involving a slow, low-and-slow pattern spanning more than about 72 hours got under-prioritized. The model was scoring each session mostly on its own merits rather than weighting it against a rolling baseline of that specific user's behavior over a longer window. A single login from a new device, scored alone, looks like nothing. The same login, as the fourth in a sequence of small access expansions over four days, is a textbook account takeover in progress. The model wasn't wrong about any individual data point. It was wrong about the shape of the campaign, because it wasn't holding the whole week in its head the way a person tracking the same account across days naturally does.

The miss that actually mattered

Here's the one that should we took note of. Mid-week, a service account — the kind nobody watches closely because it's "just" an automation account made an API call pattern that was technically within its normal permission scope, technically from an expected IP range, and technically at a normal hour. Scored individually, on every dimension the model was weighting, it looked clean. It scored low and got auto-closed.

What it actually was: a legitimate-looking OAuth token, originally issued for a sanctioned third-party integration, being used by someone who'd compromised that third-party vendor's environment and was now making calls that matched the account's normal pattern almost perfectly, almost perfectly, because the call volume was about 15% higher than that account's historical baseline, spread out just enough to avoid tripping any single threshold. This is a known technique: living off a trusted, already-authorized identity rather than trying to create a new suspicious one, specifically because most detection, human or automated is tuned to flag things that look new, not things that look like slightly-more-active versions of something that already had permission to be there.

I only caught it because I happened to spot-check the auto-closed bucket out of habit, not because the system flagged it. If I hadn't, that one stays closed.

What this means if you're thinking about doing the same thing

The lesson isn't "don't use AI for triage." The volume reduction is real and worth having. The lesson is that AI triage, as currently built, is scoring snapshots — this alert, this session, this call — against thresholds, when a meaningful share of real attacks are specifically engineered to stay under every individual threshold while accumulating into something obviously wrong over time. If you're rolling this out, the auto-close bucket needs a human spot-check built in as policy, not as a nice-to-have, and your baselines need to be per-identity and rolling, not global and point-in-time.

And the part that's actually about you, not the tool

The thing that caught the miss wasn't a smarter model. It was a habit — checking the bucket nobody was technically required to check, because something about the week felt like it deserved a second look. That instinct doesn't show up in any tool's changelog and it doesn't get cheaper to acquire just because the tooling around it gets more advanced. If anything, the better the automation gets, the more valuable that specific, hard-to-automate habit becomes, because it's the only thing standing between "the system said it's fine" and actually knowing it's fine.

However, having a solid ML workflow triage system in place is something all SOCs needs to orient towards, its just that you need to know what is worth automating, what needs to be monitored and how to fine-tune it so its your asset, not a mess.