AI-powered alert triage: how LightEDR integrates with your preferred LLM

Alert fatigue is a real problem. Not a positioning claim - an actual, daily problem for SOC analysts who spend significant time triaging alerts that turn out to be benign. The answer isn’t better detection alone; it’s faster, more confident triage. That’s where AI earns its keep.

LightEDR ships LLM-assisted triage as a first-class feature. Here’s how it works and why we built it the way we did.

How AI triage works in LightEDR

When a high or critical severity alert fires, LightEDR dispatches an async LLM analysis task alongside the alert - fire-and-forget, never blocking alert ingestion. The result arrives via a llm_analysis_ready WebSocket event and appears in the dashboard without you doing anything.

The AI does four things:

1. Explains the alert in plain English - what happened, which process triggered it, why it matched the detection rule.
2. Suggests triage steps - concrete next actions like “check parent process for unusual arguments” or “review outbound connections from this PID in the last 10 minutes”.
3. Clusters related incidents - groups alerts that share characteristics, helping you spot a multi-stage attack rather than treating each alert in isolation.
4. Answers natural language queries - you can ask your EDR “show me all processes that touched /etc/passwd in the last 24 hours” without writing a query by hand.

The feature is entirely optional. All detection, containment, and telemetry work without an LLM provider configured. You add it when and if it makes sense for your team.

Choosing your LLM provider

You pick the provider. LightEDR supports five:

Provider	Notes
Anthropic (Claude)	Strong reasoning over structured event data; good at step-by-step triage suggestions
OpenAI (GPT-4o / GPT-4.1)	Widely deployed, familiar to most teams, broad general capability
Azure OpenAI	Same models as OpenAI via a private endpoint - useful if your data must stay in your Azure tenancy
Google Gemini	Fast inference, competitive on long-context tasks
Ollama (local)	Self-hosted models on your own hardware - the right choice for air-gapped environments or teams with strict data residency requirements

The Ollama option matters more than it might seem. A lot of the organisations we talk to - MSSPs managing client environments, critical infrastructure operators, regulated industries - cannot send endpoint telemetry to a third-party cloud API. Ollama lets you run Llama 3, Mistral, or whatever model fits your hardware, entirely on-prem, with no data leaving your network. The AI triage feature works the same way; you configure a local endpoint instead of an API key.

What the AI actually produces

Here is a representative example. An endpoint fires a credential access alert:

Alert:   T1003.001 - LSASS Memory Read
Severity: Critical
Process:  mimikatz.exe (PID 4821)
Parent:   powershell.exe (PID 3994)
User:     DOMAIN\svc-backup

The LLM analysis returns something like:

What happened: mimikatz.exe, a well-known credential dumping tool, performed a memory read against LSASS. This technique (T1003.001) is used to extract NTLM hashes or plaintext credentials from memory.

Why this is likely malicious: The parent process is PowerShell, and the account is a service account (svc-backup) - an unusual context for interactive credential access. The binary name matches the public mimikatz tool exactly.

Suggested triage steps:

1. Isolate the endpoint immediately using one-click containment.
2. Check svc-backup’s recent authentication events for lateral movement indicators.
3. Identify how powershell.exe was launched - review parent PID 3994.
4. Pull the 90-day telemetry for this host and look for prior persistence indicators.

This isn’t a generic explanation - it’s contextualised to the specific event data LightEDR already collected. The analyst still makes the call; the AI reduces the time it takes to reach that call.

A note on data handling

Your alert data is sent to whichever provider you configure. If you use Anthropic, OpenAI, or Gemini, the telemetry leaves your environment. If that’s a constraint, use Azure OpenAI (private endpoint, your tenancy) or Ollama (fully local). We don’t add additional logging or caching on top of what the provider does - the data goes from LightEDR to the provider’s API and the response comes back.

That tradeoff is worth stating plainly. AI-assisted triage is genuinely useful, and the right architecture depends on your compliance posture. Both paths work.

---

If AI-assisted triage is something your team needs, get in touch - we can walk through provider setup and what to expect in practice.