The AI SOC Analyst: How We Triage 1.5M+ Alerts With a Team of 6

The original version of this article talked about triaging 10,000 alerts a month with a team of three. That headline is now obsolete. As of March 24, 2026, the live CloudRaider SOC dashboard shows 1,522,480 alerts processed, 809,853 pattern-driven auto-closures, and recent daily peaks of 59,947 alerts. The human team running that system is six people, not three.

It is 2:14 AM on a Tuesday. A Carbon Black alert fires -- suspicious PowerShell execution on a domain controller. Within thirty seconds, it is joined by four more alerts: a network connection to a known C2 domain, a credential access event, lateral movement detected on a file server, and a data staging operation flagged by DLP.

In the old model, those alerts would sit in a queue. An analyst would get to them sometime around 8 AM, after scrolling past hundreds of other notifications -- most of them noise. Microsoft demo data triggers. Product conflicts between Carbon Black and Defender. NinjaRMM scripts doing exactly what they are supposed to do. By the time a human reaches the real alerts, six hours have passed. In cybersecurity, six hours is a lifetime.

That is not how our SOC works. At CloudRaider, every alert gets processed in seconds. The AI layer handles the first pass, the noise gets suppressed automatically, and the real threats get routed to a human analyst with context already attached. The point is not to remove people from the process. It is to make sure the people in the process are not wasting their attention on junk.

Here is what the system looks like at its current operating scale, what we learned, and why we believe this is the future of security operations.

The Alert Volume Problem

The numbers in this industry are staggering. Most SOCs struggle with tens of thousands of alerts per month. Our current environment is operating at a meaningfully different scale. The live dashboard is already past 1.5 million normalized alerts processed, and over the last seven days the SOC has averaged 59,000+ alerts per day.

That distinction matters. The dashboard tracks the normalized alerts our SOC actually ingests, triages, and acts on. It does not count every upstream raw event generated by DNS, endpoint, identity, cloud, and network controls. Those raw event streams can be much higher. socperf.cloudraider.io shows the operational workload that reaches the SOC queue.

But every one of them has to be looked at. Or at least, that is the theory. In practice, alert fatigue sets in fast. Studies from the Ponemon Institute have found that SOC analysts start experiencing fatigue within the first few months of the job. After the hundredth alert that turns out to be nothing, the brain starts skipping. The thousand-and-first alert that actually matters looks identical to the 999 that did not. Analysts miss things. Not because they are bad at their jobs, but because the job as designed is inhuman.

The traditional MSSP response to this problem is to hire more bodies. Scale linearly. If you need to cover 24 hours, seven days a week, you need a minimum of 8 to 12 analysts just for shift coverage -- before you account for vacations, sick days, turnover, and training. At industry rates of $150,000 to $250,000 per fully-loaded analyst, you are looking at $1.2 million to $3 million per year in staffing costs alone. Then add the SIEM licensing, the EDR licensing, the threat intel feeds, the training programs, the management overhead.

For most mid-market organizations, this is simply not feasible. They end up with one of two outcomes: they outsource to a traditional MSSP that treats them as one ticket in a queue of ten thousand, or they go without dedicated security operations entirely. Both options are bad.

We believed there was a third option.

How We Built an AI-First Triage System

Our approach starts from a simple premise: the first pass on every alert should not require a human. Not because humans are unnecessary, but because most alerts do not deserve human attention. The machine should handle the sorting. The human should handle the thinking.

We built our triage system around pattern recognition at scale. In the production SOC today, we maintain 561 active false positive patterns that have already produced 809,853 auto-closures. Each one was learned from a real investigation, documented with specific conditions, and deployed across every customer environment we protect. Here are a few categories to give you a sense of what this looks like in practice:

• Vendor demo and test data. Microsoft Sentinel comes pre-loaded with demonstration data -- Solorigate simulations, Contoso-domain artifacts, sample threat indicators. These generate real alerts in real dashboards. We have patterns that identify and auto-close every known demo data trigger.
• Product conflicts. When you run Carbon Black alongside Microsoft Defender, they inspect each other constantly. Defender sees CB injecting into processes and flags it as suspicious. CB sees Defender's real-time scanning and logs defensive evasion indicators. Both tools are doing their jobs correctly, but together they produce a firehose of meaningless alerts. We have specific conflict resolution patterns for every common EDR and AV combination.
• Known operational patterns. NinjaRMM scripts running maintenance tasks on endpoints. Vendor VPN traffic from managed service providers. Backup software performing scheduled operations. IT admin tools executing PowerShell during business hours from known jump boxes. Every customer has operational patterns that are unique to their environment. We learn them, validate them, and codify them.
• Infrastructure noise. Cloud provider health checks, load balancer probes, DNS resolution patterns from internal recursive servers, certificate renewal automation. The plumbing of modern IT generates alert volume that has nothing to do with security threats.

The critical point is this: each pattern is learned once and applied across every customer we protect. When we identify a new false positive pattern in one environment, we evaluate it against all environments and deploy the suppression globally where it applies. This is one of the structural advantages of an MSSP model -- but only if the MSSP is actually investing in systematic pattern development rather than just staffing more seats.

The result of this approach is measurable. The live SOC dashboard currently shows 809,853 auto-closures tied to pattern learning and 26.2% noise reduction across normalized alert flow. Those alerts are classified, documented, and closed with full audit trails. If a pattern ever needs to be revisited -- if something we classified as benign turns out to have a malicious variant -- we can pull every historical instance and re-evaluate.

The Human Layer: Where Judgment Matters

The alerts that survive pattern closure are the ones that actually matter. But here is what makes our model different from a traditional SOC: these are not raw alerts. By the time a human analyst sees a flagged event, it has already been enriched with context from multiple sources.

The analyst does not start from "suspicious process detected." They start from "suspicious process detected on a domain controller belonging to Customer X, by a user account that has not logged in from this location before, connecting to an IP address that appears in three threat intelligence feeds, during non-business hours for this organization." The difference between those two starting points is the difference between fifteen minutes of investigation and four hours of investigation.

Our analysts spend their time on judgment calls. Is this lateral movement from an admin doing their job, or from a compromised account? Does this data exfiltration pattern match a known business process, or is it actually suspicious? Should we escalate to the customer's IT director at 3 AM, or can this wait until the morning standup?

These are the questions that require human intelligence, contextual understanding, and professional judgment. No AI system today can reliably make these calls. And frankly, we would not trust one that claimed it could. The stakes are too high. A false negative on a genuine intrusion can cost an organization millions. A false positive escalation at 3 AM erodes trust and credibility. Getting this balance right requires experienced practitioners who know the difference.

The math works out to something remarkable. A six-person team can absorb a six-figure weekly alert load because they spend almost no time on repetitive queue work. Every alert they look at has a meaningful probability of being worth the effort. Their hit rate on genuine security incidents is dramatically higher than industry averages, not because they are magically different people, but because the system is feeding them filtered signal instead of raw noise.

The Compounding Effect

Here is where the model gets genuinely interesting from a strategic perspective. Every investigation we run makes the system smarter.

When an analyst closes an alert as a false positive, they do not just click a button. They document what made it a false positive, what conditions were present, and whether those conditions would apply to other environments. If the answer is yes, a new pattern gets created and deployed. The next time any customer generates the same alert profile, it gets handled automatically.

When an analyst identifies a true positive, the same process runs in reverse. We document the indicators, the attack path, the detection logic that caught it, and the enrichment data that confirmed it. Those become detection engineering inputs. Over time, we are building a library of what real threats look like across diverse environments, and that library makes every subsequent investigation faster and more accurate.

A pattern found in one customer environment protects every customer we serve. This is the compounding effect, and it is the structural advantage of an AI-first MSSP that invests in systematic learning.

We track analyst questions -- the things they ask during investigations, the enrichment data they wish they had, the context that would have saved them time. Those questions become automation targets. If an analyst asks "has this user logged in from this location before?" more than twice, we build an automated enrichment that answers that question before they have to ask it.

This is the compounding effect in action. Our false positive pattern library started with a handful of rules. It is now 561 active patterns with 809,853 auto-closures recorded against it, and we add new ones as fresh operating noise appears in customer environments. Our enrichment pipeline started with basic IP and domain lookups. It now pulls user behavior baselines, geographic anomaly detection, and cross-customer threat correlation automatically.

Competitors who staff their SOC with junior analysts on rotating shifts start from zero with every customer engagement. Their institutional knowledge walks out the door with every resignation. Our institutional knowledge is encoded in code and patterns that persist and improve over time. This is the moat.

The Numbers

We believe in transparency about operational performance. Here is where we stand today, using current production data as of March 24, 2026:

Those numbers are not aspirational targets. They are the live aggregate metrics on socperf.cloudraider.io as of March 24, 2026. The dashboard currently shows 1,522,480 total alerts processed overall, with a recent daily peak of 59,947 in a single day. Of that total, 809,853 alerts have already been absorbed by pattern-driven auto-closure, supported by 561 active false positive patterns.

The team size deserves context. Six people doing this volume is not about working harder. It is about working on the right things. Our analysts do not spend time on shift handoffs, alert queue management, or copy-pasting IOCs between tools. The system handles all of that. They spend their time on the alerts where human judgment is irreplaceable, on detection engineering to improve the system, and on customer communication when it matters.

For our customers, the cost implications are significant. They get SOC coverage that would traditionally require a seven-figure annual investment, delivered at a fraction of that cost. Not because we have cut corners, but because we have eliminated the structural inefficiencies that make traditional SOCs so expensive.

What We Have Learned

Building this system has taught us several things that were not obvious at the start.

First, the AI layer is only as good as your pattern engineering. Machine learning models are useful for anomaly detection, but the real leverage comes from deterministic pattern matching on known false positive signatures. These are not sophisticated algorithms. They are carefully documented rules based on deep operational experience. The sophistication is in knowing what to look for, not in the technology that looks for it.

Second, you cannot automate judgment. We tried. Early on, we experimented with automated severity scoring and auto-escalation for certain alert types. It did not work well. The edge cases are where the real threats hide, and edge cases require context that no automated system currently handles reliably. The human layer is not a legacy component we are trying to eliminate. It is a permanent and essential part of the architecture.

Third, cross-customer intelligence is the most underappreciated advantage of the MSSP model. When we see a new attack technique against one customer, every other customer benefits from that detection within hours, not months. This is something that in-house SOCs simply cannot replicate, no matter how well-funded they are. Breadth of visibility is a structural advantage.

Fourth, transparency builds trust. We publish aggregate SOC performance metrics instead of hiding behind marketing abstractions. When a new tool deployment introduces unfamiliar patterns, that shows up in the data. When daily tempo spikes during an active week, that shows up too. This transparency has been one of the strongest drivers of customer trust. People believe what they can verify.

The Future

The future of security operations is not replacing analysts with AI. Every vendor pitch that promises fully autonomous security operations is selling a fantasy that the current state of AI cannot deliver and that the threat landscape does not allow.

The future is making every analyst dramatically more effective. It is eliminating the noise so they can focus on the signal. It is giving them context before they have to ask for it. It is encoding institutional knowledge into systems that persist and improve, rather than losing that knowledge every time an analyst leaves for a higher-paying job.

That is what a learning security platform does. It gets better over time, not just from better algorithms, but from the accumulated operational experience of every investigation, every false positive pattern, every detection improvement. The system we have today is meaningfully better than the system we had six months ago, and six months from now it will be better still.

We built CloudRaider because we believed there was a better way to do security operations. The numbers suggest we were right. But the real proof is not in our metrics. It is in the fact that our customers sleep better at night knowing someone is watching -- and that the someone is not drowning in noise.