An autonomous MDR agent with n8n: triaging EDR alerts with an LLM

In an MDR operation serving 60+ customers, alert triage is the single biggest consumer of analyst time — and a large share of those alerts are cases a seasoned analyst would call a false positive in 30 seconds. This post walks through the design of our n8n workflow (MDR Autonomous Agent v2) that hands that 30-second decision to an LLM, while keeping critical actions behind human approval.

The flow at a glance

Schedule (every 5 min)
  → FortiEDR: list open alerts
  → PostgreSQL: seen before? (dedup)
  → Limit: max 10 new alerts per run
  → Sub-workflow: collect forensic details
  → LLM analysis → FP / TP / SUSPICIOUS + confidence score
  ├─ FP  → create exception → close alert → log
  ├─ TP  → ask the manager on WhatsApp (4h window)
  │        ├─ approved → notify customer via SOAR → close
  │        └─ rejected / timeout → alert STAYS OPEN
  └─ SUSPICIOUS → take no action, queue for human review

The load-bearing design decisions

1. Dedup and blast-radius control

Every alert is first checked against an alarm_log table in PostgreSQL; previously processed events never reach the LLM again. Each run also processes at most 10 new alerts — a simple fuse that stops the agent from hammering the EDR API and the LLM during an alert storm.

2. Give the LLM explicit decision criteria — don't freelance it

The prompt puts the model in a "senior MDR analyst" role and forces one of three outcomes, with the criteria spelled out:

• FP — signed vendor software, standard Windows services running with the correct parent and path.
• TP — suspicious parent chains (Word → PowerShell), unsigned executables in Temp/Downloads, LOLBin abuse (certutil -urlcache, mshta, regsvr32), encoded PowerShell and similar indicators.
• SUSPICIOUS — anything it cannot decide with confidence.

The model must also return a confidence score between 0.0 and 1.0. The critical rule: FP verdicts below 0.75 confidence are never auto-closed — they fall through to human review. The LLM is allowed to say "I'm not sure", and the system rewards it for doing so.

3. Never trust LLM output blindly

The model sometimes wraps JSON in code fences, sometimes returns an array. The parsing Code node tolerates every format it has produced so far — and any response that cannot be parsed is automatically treated as SUSPICIOUS. The failure mode of the system is "ask a human", never "take the wrong action". That is the essence of fail-safe design.

4. Irreversible actions go through a human

Closing an FP is low-risk (exception + archive), so it is automated. Notifying a customer about a TP is not. TP verdicts land on WhatsApp: n8n's Wait node suspends the execution, and the message contains two resumeUrl-based links — "notify the customer and close" or "leave the alert open". If no approval arrives within 4 hours, the default is to leave the alert open. Silence never means yes.

5. Every decision must be auditable

FP, TP or SUSPICIOUS — every outcome writes the verdict, reasoning, confidence, severity and action taken to alarm_log. "Why did the LLM decide that?" is answerable for every single case — which we need both for customer reporting and for measuring how well the model is calibrated.

What we learned

1. Use the LLM as the first-level filter, not as the analyst. The grey zone (SUSPICIOUS) still belongs to humans — and should stay that way.
2. The confidence threshold is the throttle of your automation. We tune the 0.75 cutoff over time against real outcomes in the log; starting conservative costs nothing, the opposite does.
3. Put the approval step where people already live. Not another dashboard — WhatsApp, because that is the one screen the shift manager is guaranteed to see within 4 hours.

The workflow runs on self-hosted n8n; customer data never leaves the environment. Questions welcome via the contact section.