Automated L1 SOC triage with agentic AI

A SOC that functions well is not short on data. What it often lacks is time to process that data in a meaningful way. When a SIEM platform generates tens of thousands of alerts per week and the analyst team consists of eight to twelve people working in shifts, the basic arithmetic does not favor the team. L1 analysts spend most of their time reviewing alerts that end with a single answer: false positive. Again. This is not a human failure; it is a structural limit of how traditional SOCs are designed.

Agentic AI changes that arithmetic. Not by replacing analysts, but by handling the most repetitive part of their work: initial triage, context gathering, and noise filtering.

Why alert fatigue is a structural problem

Alert volume grows faster than security team capacity. Every new asset added to the network, every new SaaS integration, every expansion into cloud services contributes to the volume of events that need processing. SIEM rules written to catch malicious behaviour cannot automatically know that a suspicious-looking traffic pattern today is actually a scheduled batch deployment run by the operations team.

The result is what the security industry calls alert fatigue: analysts who have reviewed hundreds of false positives in a row begin treating every new alert with the same skepticism. At that point, the real risk is not that analysts are not working hard enough, but that they can no longer distinguish what matters without time-consuming investigation.

IBM reported that the average time to identify a data breach globally reached 194 days in 2024. Most of that time is not because the SIEM had no signal, but because the signal was buried under a pile of alerts that never got a careful look.

The scale of the problem is substantial in Indonesia too. BSSN recorded 4.41 billion anomalous cyber traffic events nationally through September 2025. Most of those events require an initial assessment to determine whether they are worth acting on. Without appropriate automation, that burden falls entirely on analysts.

What the AI agent does with each alert

When an alert enters the queue, the AI agent does not just read the triggering condition. It opens several investigations simultaneously: checking the reputation of any IP addresses or domains involved against global threat intelligence feeds, looking up the affected asset in the internal inventory to understand its classification and owner, reviewing the relevant user's recent activity in the period before the alert fired, and checking whether similar signals are appearing on other endpoints or network segments at the same time.

This process takes seconds, not minutes. The result is a concise summary with a confidence score: how likely is this alert to represent a genuine threat, given all the context gathered.

High-confidence alerts with genuine threat indicators go directly to the analyst queue with full context already attached. Low-confidence alerts that are consistent with known-normal patterns are auto-closed and logged for audit. Analysts only see cases that actually need their judgment.

The diagram below shows the agent's decision flow from the moment an alert arrives to the action taken.

How agentic AI differs from SOAR and traditional automation playbooks

SOAR (Security Orchestration, Automation and Response) has long been the standard tool for SOC automation. There is an important difference, though, between playbook-driven SOAR and an agentic approach.

SOAR playbooks work through predefined conditional logic: if condition A is true, execute action B. This works well for well-defined, already-understood scenarios, but it is fragile when confronted with unexpected variations. An alert that differs slightly from an existing template often slips past automation entirely or triggers an inappropriate response.

AI agents work differently. An agent does not match conditions to templates; it assesses the situation based on the context it has gathered and makes a decision grounded in a broader picture of what is happening. This does not mean the agent is always correct. It means the agent can handle variations that were never anticipated when the playbook was written, as long as it has enough context to assess them.

The two approaches are complementary. SOAR playbooks remain useful for responses that need to be strictly deterministic and tightly auditable. AI agents add a more flexible judgment layer on top of that.

What analysts do with the time returned

When routine triage is handled by the agent, analysts have time for work that moves the needle. Threat hunting runs much better when someone has the bandwidth to follow a chain of hypotheses through historical logs without constantly interrupting themselves to check new alerts. The same applies to deeper investigation of anomalies that do not match any known signature.

A benefit that often goes unnoticed is the improvement in escalation quality itself. When the agent passes an alert to an analyst, it arrives with context already assembled: which assets are involved, what happened recently on those systems, which indicators overlap with known threat intelligence. Analysts begin their investigation from a much more advanced starting point, rather than from zero. This has a direct effect on incident response speed, which ultimately determines how far an attacker gets before being stopped.

Automated triage solves a downstream problem: alerts that have already fired. The same agent can work further upstream, on the detections that generate those alerts, and outward toward operations, on the cost of running it all. The two capabilities below sit alongside L1 triage.

Detections that adapt without manual tuning

Triage quality is only as good as the detection rules that trigger it. This is where many SOCs lose time before the first alert even appears. Detection rules are usually written once and rarely revisited until something feels wrong. Yet the environment keeps changing: new assets are added, new SaaS apps are integrated, user behaviour shifts. A rule that was accurate six months ago slowly becomes too noisy or, more dangerously, blind to activity that did not exist before.

The agentic detection layer adapts detection logic to a continuously updated baseline of the environment. When normal patterns shift, the agent adjusts rule thresholds and context instead of waiting for an engineer to tune them by hand. The result is twofold: false positives drop at the source, so the volume reaching triage falls with them, and rules stay relevant without the never-ending manual tuning cycle.

The agent also maps detection coverage against the MITRE ATT&CK framework across the tools you already run: EDR, cloud logs, identity systems, SaaS apps, and OT devices. That mapping surfaces blind spots, the attack techniques relevant to your environment that no detection currently covers. Closing those gaps before they are exploited costs far less than handling them afterwards.

Lower operating cost and independence from a single vendor

Most SIEM cost is driven by the volume of data fed into it. The more telemetry you ingest, the larger the licensing bill and data pipeline cost. The traditional model pushes organisations to load almost every log into one platform so it can be queried later. That approach is expensive and creates vendor dependence: the more data locked inside, the harder and costlier it becomes to move.

The agentic approach reverses the order. Instead of ingesting everything first, the agent pulls context from the source on demand during triage and investigation: from EDR, cloud, identity systems, business applications, infrastructure and OT, and the existing data lake. Data that genuinely needs long-term retention still goes to the SIEM, but the expensive ingestion volume can be reduced because not all telemetry has to be moved to be analysed.

The operational effect shows up on two fronts. Ingestion and pipeline costs fall as analysis shifts from "collect first, query later" to intelligence on demand. Dependence on a single platform drops because the agent works across the tools you already have rather than forcing all data into one vendor's product. The security team keeps control of detections, investigations, and response orchestration from a single operations view, without being locked into an architecture that is hard to leave.

Capabilities available

Operational changes that become noticeable in practice

Integration with existing security infrastructure

The agentic layer does not require replacing the SIEM or EDR already in place. The agent operates as a layer on top of the running stack, pulling telemetry from the SIEM via API and returning enriched context into the analyst queue. We support Splunk, Microsoft Sentinel, IBM QRadar, and open-source platforms commonly used in Indonesia.

Onboarding into our managed SOC service begins with a calibration period of four to eight weeks, during which the agent runs in observation mode, making recommendations reviewed by analysts before full automation is activated. This period matters not only for tuning the model, but also for building team confidence that the agent is not closing cases that should have been investigated.