Agentic Alert Investigation 論文閱讀分析：很多 SOC 真正缺的，不是再多一個會判案的模型，而是先把 alert 查成有證據的案子

本文由 AI 產生、整理與撰寫。

論文基本資訊

• 論文標題：Towards Agentic Investigation of Security Alerts
• 作者：Even Eilertsen、Vasileios Mavroeidis、Gudmund Grov
• 年份：2026
• 來源：arXiv:2604.25846
• 論文連結：https://arxiv.org/abs/2604.25846
• DOI：10.48550/arXiv.2604.25846
• 會議：2025 IEEE International Conference on Big Data (BigData)
• 主題：Security Operations Center、Alert Investigation、LLM Agents、SOC Automation、Suricata、Incident Triage

如果你最近聽太多「讓 agent 進 SOC 就能自動 triage alert」這種口號，這篇 Towards Agentic Investigation of Security Alerts 的價值，在於它沒有直接把夢做滿，而是老老實實承認一件事：真正卡住 SOC 的，常常不是模型不會下 verdict，而是它在下 verdict 前根本沒把該看的 log 看完。

作者想處理的是很實際的 early-stage investigation 問題。很多 detection system 只丟一條很空泛的 alert，像是「Suspicious behaviour」，但 analyst 接下來卻得自己去翻 Suricata、auth log、syslog，把 source、destination、HTTP path、login failure、可疑字串一段一段拼起來。這件事很花時間，也正是 alert fatigue 的養成機制之一。

所以這篇 paper 沒有把 LLM 當成一個直接看 alert 就能通靈的裁判，而是把它包成一條有工具、有步驟、有約束的 investigation workflow：先看 overview，再挑 query，再抽 evidence，再寫 summary，最後才下 verdict。

這篇論文最重要的主張：不要直接問模型「這是不是攻擊」，先讓它學會怎麼查

作者提出的 workflow 很像把一位初階 SOC analyst 的前半段工作流程拆成幾個角色：

• Investigator LLM：根據 alert 與 overview 決定接下來該查哪些資料
• Execution layer：真的去跑 SQL query 與 grep，把資料抓回來
• Summary LLM：把 evidence 整理成 executive summary、IoC 與行為判讀
• Incident Verdict LLM：最後才決定 malicious、benign 或 uncertain

這個設計的核心不是「多叫幾次模型比較厲害」，而是把判斷和取證分開。模型先負責決定「要看什麼」，系統再用受限工具真的把資料拿回來，最後另一個模型才根據已知證據作結論。

換句話說，作者在修正一個很常見的 AI 誤用：你不能期待 LLM 在沒查到資料前就先有調查結論。

它怎麼查？其實很樸素，甚至有點故意樸素

這篇 paper 用的工具不花俏，反而因此很有參考價值。結構化資料主要是 Suricata logs，透過 SQL 查詢；非結構化資料則用很克制的 grep 去掃 auth log 和 syslog。Investigator LLM 可選的查詢也不是無限自由發揮，而是從幾種 predefined query 裡挑，例如：

• 時間窗內最常見的 alert signatures
• 產生最多 alert 的 source IP
• 被打最多次的 destination IP
• 告警 HTTP path 與 sample status
• 針對 alert message 的 regex 篩選
• 有限度的 freeform SQL

這種設計看似保守，實際上很聰明。因為作者很清楚：真的要把 LLM 放進 investigation pipeline，最先該限制的不是模型文筆，而是它碰資料和工具的方式。

所以 execution step 裡還加了不少 guardrails：

• SQL 必須是單一 SELECT
• 查詢必須有時間範圍限制
• 結果數量有 hard limit
• regex 要先驗證
• grep 與 free SQL 都有成功與否的 artifact 可追

這很值得實務團隊抄作業。因為很多人一想到 agentic SOC，就先腦補成「讓模型自己亂翻 SIEM」。但這篇的訊息剛好相反：真正能落地的，不是最大自由度，而是最小但夠用的查詢自由。

實驗其實很簡單，但已經足夠打臉 baseline

作者的資料集與情境不算大。他們從 AIT Log Data Set V1.1 抽出兩個 30 分鐘視窗：

1. malicious subset：包含真實攻擊時段
2. benign subset：同一台 web server 在非攻擊時段的正常流量

兩組資料都假設一個 context 很弱的 anomaly-based alert 當起點，也就是 alert 本身不會告訴你是哪個 CVE、哪條 signature、哪個 kill chain，只是提醒你「這裡怪怪的」。這其實很貼近很多現場告警的痛點：alert 很多，但上下文很少。

baseline 也因此設得很合理：直接把 alert + overview 丟給 Verdict LLM，看它能不能自己猜對。結果很殘酷——在 malicious subset 上，baseline accuracy 是 0%。

也就是說，如果你只是把一條貧血 alert 丟給模型問「這是不是惡意」，它大概率不是在判斷，而是在猜。

加上 workflow 之後，差距不是小修小補，是整個像換系統

真正有意思的是 workflow 加進來後的結果。作者測了 GPT-5-mini、Claude 3 Haiku、Qwen3:30B、Gemma 3:27B。雖然不同模型行為差異很大，但在 malicious subset 上，workflow 的表現整體明顯提升：

• GPT-5-mini：100% 正確判成 malicious
• Qwen3:30B：95%
• Claude 3 Haiku：94%
• Gemma 3:27B：81%

更關鍵的是 benign subset 幾乎沒有亂報成 malicious。作者明講，他們寧可讓模型多給一些 uncertain，也不要輕易把 benign 誤判成 malicious，或更糟，把 malicious 誤判成 benign。

這其實碰到 SOC automation 裡一個很成熟、但在 AI 場景常被忘掉的設計原則：

如果你的目標是幫 analyst 節省時間，而不是完全取代 analyst，那降低錯判風險通常比追求百分之百自動結案更重要。

這篇 paper 的 workflow 正是在做這件事：先把一部分明顯案件處理掉，把真正需要人盯的 uncertainty 留給 analyst。

它最值得學的，不只是 accuracy，而是整個 reasoning 形狀

我覺得這篇最值錢的地方，不只是「有 query 的 agent 比沒 query 的 LLM 準」，而是它把 investigation 做成一種比較對的 reasoning shape。

傳統 prompt-only 的錯法通常是這樣：

• 模型太早下結論
• 把缺失的 context 腦補成 evidence
• 對高 volume logs 沒有真正可操作的搜尋路徑

這篇 workflow 則強迫模型走另一條路：

• 先看 overview，知道有哪些 signal 可以追
• 再挑查詢，縮小資料面
• 再抽證據，確認 source、path、failure pattern
• 最後才給 verdict

這背後的思想很像在對 LLM 說：你不是先知，你是值班分析員；先查，再說。

當然，它離 production-ready 還很遠

作者自己也很誠實。這不是一篇把 agentic SOC 已經做完的論文，而是一個 proof of concept。限制不少：

• 資料集規模有限，只測單一攻擊情境
• alert 是研究者假設出來的，不是完整真實告警流
• 可用 query 種類偏少
• 只做 early-stage alert investigation，不是整個 incident lifecycle
• 還沒正面處理 prompt injection 與對抗操弄問題

尤其最後一點非常重要。把 LLM 放進 SOC 流程，不代表只要 query guardrails 做好就沒事。只要它要讀 logs、summary、external artifacts，就要考慮：

• 資料內容本身會不會成為 prompt injection 載體
• summary 與 evidence 萃取有沒有 laundering 風險
• 不同 LLM component 之間的結論會不會互相放大偏誤

所以這篇不是在告訴你「SOC 可以放心交給 agent」；它比較像是在說：如果你真的想做這件事，至少該從有 evidence path、有限工具、可追 artifact 的 workflow 開始，而不是直接讓一顆模型坐上判官位子。

對 sectools.tw 讀者最值得帶走的幾個實務點

1. 別把 alert triage 當成純分類題。 很多真正有價值的改善，不是換更大模型，而是讓模型會查資料。
2. 工具使用要先收斂。 SOC agent 最危險的不是不會查，而是查太自由、查到不可控。
3. uncertain 不一定是壞事。 在高風險場景，保守地把模糊案件留給 analyst，通常比自信亂判更健康。
4. artifact 很重要。 你若想調 prompt、追錯誤、驗證流程，就不能只看最後 verdict，還要保留 query success、rows、grep results、summary 等中間產物。
5. query design 本身就是安全控制。 預先定義高訊號查詢，比讓模型無限制自由探索更接近可治理的 automation。

我的看法：這篇真正補到的是「證據建構」這一層

很多 AI for SOC 的論文與產品，最容易讓人誤會的地方，就是把 investigation 說得像問答系統升級版：丟問題，拿答案。但這篇 paper 比較像回到現場常識：資安調查本來就不是先有答案，再去找理由；而是先把資料脈絡建起來，答案才慢慢浮出來。

所以它真正補到的，不只是 agentic workflow，而是LLM 在安全營運裡應該扮演什麼角色：不是替代所有分析，而是幫你把原本散在多個 log source 的初步證據先收斂成可判讀的形狀。

結語

如果要把這篇論文濃縮成一句話，我會寫成這樣：

很多 SOC automation 真正缺的，不是再多一個會下 verdict 的模型，而是先有一條能把薄弱 alert 慢慢查成有證據結論的 investigation path。

Towards Agentic Investigation of Security Alerts 值得看的地方，不在於它已經把 agentic SOC 做到完美，而在於它把一個很容易被講成魔法的題目，硬是拉回到比較樸素、也比較可靠的工程問題：查什麼、怎麼查、查完怎麼收斂、什麼時候才配下結論。

如果你正在做 SOC copilot、alert enrichment、SIEM assistant、IR triage agent，這篇 paper 最實用的提醒可能是：先不要急著讓模型像分析師那樣下判斷，先讓它像分析師那樣找證據。