Use case · Security operations

Every alert arrives already investigated. Your analysts make the call.

An AI agent enriches each SIEM and EDR alert, groups related detections into one incident, runs read-only investigation queries and drafts a case summary with a recommended disposition. Isolating a host or disabling an account still needs an analyst's approval.

For sOC managers and heads of security operations at organisations running an in-house or co-managed security operations centre.

Many alerts, one incidentALERT QUEUEINCIDENT · CORRELATEDSummary draftedDisposition proposedAnalyst decidesContainment on holdApproveHold

Night shift

02:40, and the queue is still climbing.

Two analysts are on shift. The SIEM has raised a few hundred alerts since midnight, and the EDR console shows suspicious PowerShell detections on three laptops in the same office.

Working one alert means the same routine: look up the host in the CMDB, check who was signed in, search the proxy logs, see whether the hash has appeared before, then decide whether it is noise. Most of it is. Each one still needs those checks before it can be closed.

By the time an analyst links the three laptops to a single phishing email from the previous afternoon, the handover note is half written, and the day shift will have to rebuild the reasoning from ticket comments.

Inside the pipeline

From raw detection to a case an analyst can sign.

Three stages run before an analyst opens the case, each leaving its working visible.

Many alerts, one incidentALERT QUEUEINCIDENT · CORRELATEDAlert lands in queueAsset tier attachedUser context addedIntel lookup doneApproveHold

Conceptual flow, not a live system or measured result.

01

Enrich on arrival

When a detection arrives from the SIEM or EDR, the agent attaches what an analyst would look up first: the asset's owner and criticality tier from the CMDB, the signed-in user's role and recent sign-in history from the identity provider, reputation results for hashes, domains and IP addresses, and earlier alerts on the same host. Every enrichment is stored with its source and timestamp, so the analyst can see where each fact came from and how fresh it is.

Many alerts, one incidentALERT QUEUEINCIDENT · CORRELATEDAlert lands in queueAsset tier attachedUser context addedIntel lookup doneApproveHold
Alert lands in queueAsset tier attachedUser context addedIntel lookup done
02

Group what belongs together

The agent looks for alerts that share a host, user, process tree, file hash or network destination within a time window your team sets, and proposes grouping them into one incident. It then runs read-only queries drawn from your playbooks, such as process lineage on the affected hosts or other mailboxes that received the same attachment, and places the results on a single timeline. Grouping is a proposal: analysts can split or merge incidents, and their corrections are recorded.

Many alerts, one incidentALERT QUEUEINCIDENT · CORRELATEDRelated alerts linkedOne incident formedRead-only queries runTimeline assembledApproveHold
Related alerts linkedOne incident formedRead-only queries runTimeline assembled
03

Hand over a case, not a pile

The agent writes a case summary: what was seen, which queries ran, what they returned and what is still unknown. It recommends a disposition, such as benign, true positive or escalate, and cites the evidence behind it. If containment looks warranted, it prepares the action, for example isolating a host through the EDR, and holds it for an analyst to approve. The analyst's decision, and any disagreement with the recommendation, is written back to the case.

Many alerts, one incidentALERT QUEUEINCIDENT · CORRELATEDSummary draftedDisposition proposedAnalyst decidesContainment on holdApproveHold
Summary draftedDisposition proposedAnalyst decidesContainment on hold

What to measure

Five numbers that show whether triage really improved.

Agree baselines before a pilot, or improvement stays anecdotal.

01Mean time to triage
Time from alert creation to a recorded disposition, measured separately for agent-prepared and unprepared alerts.
Speed only counts if the other four measures hold steady.
02False-positive closure precision
Of the alerts the agent recommended closing as benign, the share later confirmed as benign.
A wrong closure can hide a real intrusion, so this decides how much trust to extend.
03Correlation accuracy
How often proposed incident groupings are accepted unchanged rather than split or merged by an analyst.
Bad grouping either buries a separate attack in a noisy incident or scatters one attack across tickets.
04Analyst override rate
The proportion of recommended dispositions an analyst changed, by alert type and detection source.
A rising rate in one category usually points to a playbook gap or a detection that needs tuning.
05Escalation quality
Whether cases escalated to tier two or incident response carried the evidence the receiving team needed, as judged by that team.
Faster triage that pushes incomplete cases upstream only moves the bottleneck.

Guardrails

What the agent may look at, and what it never does alone.

Containment waits for a person

Isolating a host, disabling an account, blocking a domain or revoking sessions is prepared by the agent and executed only after a named analyst approves. The approver is named in the case.

Read-only by default

The agent's service accounts hold query permissions in the SIEM, EDR and identity provider, not write permissions. Any change of state goes through the approval step.

Every query is on the record

Each search is logged with its query text, data source, time and case reference, so your team can replay an investigation and auditors can see exactly what was accessed.

Playbooks set the boundaries

The investigation steps available to the agent come from playbooks your team writes and versions. It cannot invent new query types or reach data sources outside them.

Self-assessment

Is your SOC ready for an agent on the queue?

Answer honestly. Four or more yeses suggest a pilot would have enough to work with.

Is your SOC ready for an agent on the queue?

0 of 6

Build the foundations first.

An agent will repeat gaps in your inventory and playbooks at speed. Fixing asset criticality and recorded dispositions pays off whether or not you automate later.

Talk it through with us

Connected tools

Security platforms the agent works through

  • Splunk Enterprise Security
  • Microsoft Sentinel
  • Google Security Operations
  • CrowdStrike Falcon
  • Microsoft Defender for Endpoint
  • Palo Alto Networks Cortex XSOAR
  • ServiceNow Security Operations
  • Okta and Microsoft Entra ID

Not every SOC

Queues an agent will not fix.

  • Volume is low enough that analysts already investigate every alert fully within target. Detection tuning may help more.
  • Most noise comes from badly tuned rules. An agent would triage that noise faster; fixing the rules removes it.
  • You want containment to happen automatically, with nobody approving it. We do not build that.
  • Your SOC is run by a managed provider whose contract gives you no access to the underlying tooling. The work has to sit with whoever operates the SIEM and EDR.

Questions SOC leads ask

What security teams want settled early.

How is this different from a SOAR playbook?

SOAR runs fixed sequences well: for this alert type, run these lookups. The agent adds judgement between steps, choosing which playbook queries are relevant, reading what comes back and writing it up in plain language. If you run SOAR already, the agent calls your existing playbooks, and containment still uses the SOAR approval flow.

Can the agent close alerts on its own?

By default it recommends and an analyst closes. Some teams later allow automatic closure for narrow, well-understood alert types, once closure precision has been measured over a sustained period and signed off. That decision belongs to your SOC manager, is made per alert type, and can be reversed at any time.

Could a crafted alert or email manipulate it?

Alert fields, email bodies and file contents are treated as untrusted data, never as instructions. The agent's permissions are read-only and limited to playbook queries, so even a hostile payload cannot make it act. Outputs that contradict the evidence, such as a benign verdict on a known-bad hash, are flagged for review.

Where does our telemetry go?

The agent runs where you decide: in your own cloud tenancy, alongside your SIEM, or in a region that meets your residency needs. It queries your existing tools through their APIs. We do not copy log data into a separate store unless you ask for one, and case records follow your retention policy.

How is it tested before it sees live alerts?

We replay historical alerts with known outcomes through the agent in shadow mode and compare its dispositions and groupings with what your analysts decided. Live cases start only once your team accepts those results, and analysts still see every recommendation before anything is closed.

Go deeper

The pieces behind this workflow.

02Your starting point

What would you like to move forward?

Start with the outcome that feels closest. We'll help give the next step a useful shape.

04Let's find your next move

One conversation. A clearer direction.

Tell us what you want to improve. A few sentences are enough to start.

shayan@coldai.org

Last reviewed 25 September 2026.