n8n ile otonom MDR ajanı: EDR alarmlarını LLM ile triyaj etmek

60+ müşteriye hizmet veren bir MDR operasyonunda alarm triyajı, analist zamanının en büyük kalemidir — ve bu alarmların önemli bir bölümü, deneyimli bir analistin 30 saniyede "false positive" diyeceği vakalardır. Bu yazıda, tam da o 30 saniyelik kararı bir LLM'e devreden, ama kritik aksiyonları insan onayına bağlayan n8n workflow'ümüzün (MDR Autonomous Agent v2) tasarımını anlatacağım.

Genel akış

Schedule (5 dk)
  → FortiEDR: açık alarmları listele
  → PostgreSQL: daha önce işlendi mi? (dedup)
  → Limit: koşu başına max 10 yeni alarm
  → Alt-workflow: forensic detayları topla
  → LLM analizi → FP / TP / SUSPICIOUS + güven skoru
  ├─ FP  → exception oluştur → alarmı kapat → logla
  ├─ TP  → WhatsApp ile müdüre sor (4 saat) 
  │        ├─ onay  → SOAR ile müşteriye bildir → kapat
  │        └─ ret / zaman aşımı → alarm AÇIK kalır
  └─ SUSPICIOUS → hiçbir aksiyon alma, incelemeye düşür

Tasarımın taşıyıcı kolonları

1. Dedup ve debilite koruması

Her alarm önce PostgreSQL'deki alarm_log tablosuna karşı kontrol edilir; daha önce işlenen event tekrar LLM'e gitmez. Ayrıca koşu başına en fazla 10 yeni alarm işlenir — bir alarm fırtınasında ajanın EDR API'sini ve LLM'i boğmasını engelleyen basit ama etkili bir sigorta.

2. LLM'e net karar kriterleri ver, serbest bırakma

Prompt, "kıdemli MDR analisti" rolüne üç sonuçtan birini seçtirir ve kriterleri açıkça sayar:

• FP — imzalı üretici yazılımı, doğru parent/path ile çalışan standart Windows servisleri.
• TP — şüpheli parent zinciri (Word → PowerShell), Temp/Downloads'tan çalışan imzasız exe, LOLBin kötüye kullanımı (certutil -urlcache, mshta, regsvr32), encoded PowerShell gibi belirtiler.
• SUSPICIOUS — emin olunamayan her şey.

Model ayrıca 0.0–1.0 arası güven skoru döndürmek zorunda. Kritik kural şu: güveni 0.75'in altındaki FP kararları otomatik kapatılmaz, insan incelemesine düşer. LLM'in "emin değilim" deme hakkı var — ve bunu söylemesi ödüllendiriliyor.

3. LLM çıktısına asla körü körüne güvenme

Model bazen JSON'ı kod bloğu içinde, bazen dizi olarak döndürür. Parse eden Code node'u her formatı tolere eder; parse edilemeyen her yanıt otomatik olarak SUSPICIOUS sayılır. Yani sistemin arıza modu "yanlış aksiyon almak" değil, "insana sormak" — fail-safe tasarımın özü bu.

4. Geri dönüşü olmayan aksiyonlar insan onayından geçer

FP kapatmak düşük riskli bir aksiyondur (exception + arşiv), o yüzden otomatiktir. Ama bir TP için müşteriye bildirim göndermek öyle değil. Bu yüzden TP kararları WhatsApp'a düşer: n8n'in Wait node'u execution'ı askıya alır, mesajın içinde resumeUrl tabanlı iki link vardır — "müşteriye bildir ve kapat" ya da "alarmı açık bırak". 4 saat içinde onay gelmezse varsayılan davranış alarmı açık bırakmaktır. Sessizlik hiçbir zaman "evet" anlamına gelmez.

5. Her karar denetlenebilir olmalı

FP, TP, SUSPICIOUS — her sonuç alarm_log tablosuna kararı, gerekçeyi, güven skorunu, severity'yi ve alınan aksiyonu yazar. "LLM neden böyle karar verdi?" sorusunun cevabı her vaka için sorgulanabilir durumda; bu hem müşteri raporlaması hem de modelin kalibrasyonunu ölçmek için gerekli.

Öğrendiklerimiz

1. LLM'i analistin yerine değil, ilk seviye filtrenin yerine koyun. Gri alan (SUSPICIOUS) hâlâ insana ait — ve öyle kalmalı.
2. Güven eşiği, otomasyonun gaz pedalıdır. 0.75 eşiğini logdaki gerçek sonuçlara bakarak zamanla ayarlıyoruz; başlangıçta muhafazakâr olmak maliyetsiz, tersi ise değil.
3. Onay mekanizmasını insanların zaten yaşadığı yere koyun. Ayrı bir panel değil, WhatsApp — çünkü vardiya müdürünün 4 saat içinde göreceği garanti olan tek ekran o.

Workflow n8n üzerinde self-hosted çalışıyor; müşteri verisi ortamdan çıkmıyor. Sorusu olan olursa iletişim bölümünden yazabilir.