AI-Assisted Investigation in the SOC: What It Does, and What It Cannot Do

AI-assisted investigation applies large language models to the interpretation layer of security operations: summarising what happened, translating analyst questions into queries, and drafting the written output an investigation produces. It does not replace detection logic, and it does not decide what is malicious. It reduces the time an analyst spends on reading, correlating and writing.

That framing matters, because this is an area where marketing claims have run some distance ahead of what the technology reliably does.

Where it genuinely helps

Timeline summarisation

A single correlated incident might involve four hundred individual log events across six systems. An analyst opening that for the first time spends fifteen to thirty minutes simply establishing the sequence. A language model can compress that into a paragraph — what happened, in what order, on which hosts, involving which accounts — in seconds.

This is the highest-value application, because it targets the genuine bottleneck. In most SOCs the constraint is not detection volume, it is the analyst hours available to understand what has been detected.

Natural language to query translation

Every SIEM has a query language, and every query language has a learning curve. An analyst who knows exactly what they want to ask may still need several attempts to express it correctly.

Language models are well suited to this translation. "Show me every failed login for service accounts outside business hours in the last week" becomes a syntactically valid query immediately. The analyst reviews and runs it. This meaningfully lowers the barrier for junior staff and for the IT generalists who run security in smaller organisations.

Alert triage support

Given an alert plus its surrounding context, a model can propose an initial assessment: what this appears to be, which MITRE ATT&CK technique it resembles, what evidence would confirm or refute it, and what to check next. Treated as a starting hypothesis rather than a verdict, this is useful — particularly for analysts who have not seen that pattern before.

Report drafting

Incident documentation is necessary, time-consuming and widely disliked. Generating a first draft from investigation data — with the analyst editing rather than composing — recovers meaningful time and improves consistency across a team.

Explaining unfamiliar artefacts

"What does this PowerShell command do?" is a question analysts ask constantly. A model that can decode obfuscation and explain intent in plain language removes a common research detour.

Where it fails, and how it fails

The failure mode of language models is specific and worth internalising: they fail confidently. A traditional tool that cannot answer returns an error. A language model that cannot answer produces something fluent and plausible that happens to be wrong.

Fabricated specifics. Models can invent CVE numbers, misattribute malware families, or cite process behaviours that do not exist. In an investigation these errors are dangerous precisely because they are well-formed and read as authoritative.

False confidence about absence. Asked whether there is evidence of lateral movement, a model may state there is none — when the relevant logs simply were not in its context window. Absence of evidence in a truncated dataset is not evidence of absence.

No real-time ground truth. A model summarising an incident is reasoning over the data it was given. If collection has a gap, the summary will be confidently incomplete.

Susceptibility to injected content. Security logs contain attacker-controlled strings — filenames, user agents, command lines. An attacker who knows an LLM will process those logs can craft input designed to manipulate the summary. This is prompt injection with a security-relevant payload, and it is an active area of concern rather than a solved problem.

Inconsistency. The same question can yield different answers on different runs. For investigative work that may end up in a regulatory filing or a court proceeding, non-determinism is a genuine problem.

The design principle: assistive, not autonomous

The practical conclusion is that AI belongs on the interpretation and drafting side of investigation, not the decision side.

Sound implementations share several properties:

• Every claim links to source events. The analyst can click through from any statement in a summary to the raw log lines behind it. A summary that cannot be traced back is not evidence.
• Generated queries are shown before execution. The analyst sees and approves the query rather than receiving unexplained results.
• Output is labelled as AI-generated. In a case file, machine-generated interpretation must be distinguishable from analyst conclusions.
• Nothing is auto-remediated on AI judgement alone. Isolating a host or disabling an account should follow deterministic rules and human approval, not a probabilistic assessment.
• The feature degrades gracefully. If the model is unavailable, the platform must remain fully usable.

Where the model runs is a compliance question

This is the consideration most often overlooked, and for organisations under data residency obligations it is decisive.

To summarise an incident, a model must receive the incident data — usernames, hostnames, internal IP addresses, file paths, command lines, and often fragments of business data caught in the logs. If the model is a hosted API in another jurisdiction, that data has crossed a border.

The questions to ask any vendor offering AI investigation features:

1. Which model is used, and who operates it?
2. In which country is inference performed?
3. Is submitted data retained, logged, or used for training?
4. Can the feature be disabled entirely without degrading the platform?
5. Can a locally hosted model be substituted?

For a Malaysian bank under BNM RMiT, an Indonesian institution under OJK rules, or any organisation subject to CERT-In's localisation directions, "our AI features call a US-hosted API" may be an immediate disqualification — regardless of how good the feature is.

Locally hosted open-weight models are a credible answer here. They generally trail the largest commercial models in raw capability, but for summarisation and query translation the gap is narrower than for open-ended reasoning, and the compliance position is far simpler. For an air-gapped deployment, a local model is the only option that exists at all.

A realistic assessment

AI-assisted investigation is a genuine efficiency gain, not a transformation. It will not let three analysts do the work of ten, and any vendor implying otherwise should be treated sceptically.

What it does reliably is compress the reading, searching and writing that surrounds investigation — which, across a year, is a substantial amount of recovered analyst time. The judgement stays with the human, and that is the correct arrangement, both operationally and for anyone who may later have to defend a decision to a regulator.

---

Details of nPro's AI integration, including model configuration and self-hosted options, are in the nPro documentation.