CORTEX 論文閱讀分析：把多代理人 LLM 真正放進高風險 SOC Alert Triage 之後，會變得更可靠嗎？

論文基本資訊

• 論文標題：CORTEX: Collaborative LLM Agents for High-Stakes Alert Triage
• 作者：Bowen Wei、Yuan Shen Tay、Howard Liu、Jinhao Pan、Kun Luo、Ziwei Zhu、Chris Jordan
• 年份：2025
• 來源：arXiv:2510.00311
• 論文連結：https://arxiv.org/abs/2510.00311
• 主題：SOC、Alert Triage、LLM Agent、Multi-Agent、Incident Investigation、Tool Use、Auditability

如果最近幾篇 sectools.tw 的脈絡，已經一路從 CTIBench、CTIArena、ExCyTIn-Bench、CyberSOCEval、LLMs in the SOC 走到「模型到底懂不懂資安、會不會調查、能不能在 SOC 裡和人協作」，那這篇 CORTEX 剛好再往前推一步：不是只問模型會不會回答，而是問它能不能在高誤判成本的 alert triage 場景裡，像一支有分工的分析團隊那樣工作。

這篇論文的重要性不在於它又提出了一個新的 agent 名字，而在於它抓到一個 SOC 現場一直存在、但很多 AI demo 刻意略過的問題：alert triage 不是一般的文字問答，也不是把 log 丟進模型就讓它自己腦補 verdict。 在真實情境裡，triage 需要查工具、看上下文、驗證假設、處理跨來源證據，而且最後還得留下可稽核的判斷鏈。CORTEX 的貢獻，就是把這種工作型態映射成一個 role-specialized、tool-grounded、auditable 的 multi-agent pipeline。

這篇論文想解決什麼？

作者開場先把問題講得很直接：SOC 每天面對大量告警，其中真正對應到實際攻擊的往往只是少數。其餘大量 false positives 會造成兩種後果：

• alert fatigue：分析師被噪音淹沒，真正重要的訊號反而被埋掉
• burnout 與判斷失誤：人被迫長時間做高重複度、低訊號密度的篩選工作

論文引用的背景數字相當刺眼。作者提到既有研究曾報告 false positive rate 可接近 99%，而產業報告也常把企業告警中的 false positive 比例估在 40%–45% 左右。這個前提很重要，因為它說明 SOC 需要的不只是「多一個懂資安的聊天機器人」，而是更精準、可驗證、能承受高風險工作流的 triage 系統。

作者對現有 LLM-based security assistant 的批評也很準：很多方法仍是 single-agent paradigm，讓單一模型同時負責讀 log、找脈絡、查外部資訊、下 verdict。這種設計在 demo 裡很方便，但一進入 noisy enterprise data 與長流程 investigation，常會同時遇到：

• 上下文太長，推理容易漂移
• 工具呼叫與證據回收不穩定
• 最終結論難以 audit
• 一旦判錯，很難回溯到底是哪一步出了問題

所以這篇 paper 要回答的核心問題是：

若要把 LLM 放進高風險 SOC alert triage 流程，我們能不能用角色分工與工具約束，把它做成更像真實分析團隊，而不是單一模型硬扛整條 investigation？

CORTEX 的核心想法：把 alert triage 拆成多角色協作

CORTEX 採用的是一個非常典型、但在這個場景裡很合理的 divide-and-conquer 思路。作者把 triage 工作拆成四個階段：

1. Orchestrator Agent：負責整體流程控制、模組切換與一致性維持
2. Behavior Analysis Agent：判斷這筆 alert 應該走哪一類 investigation workflow
3. Evidence Acquisition Agents：依 workflow 去查企業內外工具、補齊證據
4. Reasoning & Coordination Agent：整合各路證據，輸出最終 triage decision 與可稽核報告

這個設計和很多泛用 multi-agent 架構不同的地方，在於它不是抽象地說「多個 agent 討論會更好」，而是非常明確地把 SOC analyst team 的職能分工 映射進模型架構裡。也就是說，CORTEX 的意義不只是有四個 agent，而是每個 agent 都對應到 triage 現場的某種工作責任。

四階段流程怎麼運作？

1. Orchestrator：先管流程，不急著下判斷

Orchestrator Agent 的責任不是做最終判定，而是維持整條 pipeline 的模組化與一致性。它確保 alert 被送進對的後續階段，也確保各 agent 之間的 handoff 清楚、不會各自亂跑。這一步在論文裡看似平淡，但其實很重要：在高風險調查流程裡，流程治理本身就是可靠性的一部分。

2. Behavior Analysis：先決定該走哪條 workflow

第二階段是 CORTEX 的一個關鍵點。Behavior Analysis Agent 不是直接回答 alert 是真是偽，而是先回答：這筆告警比較像哪種調查類型？ 作者在系統中實際實作了七類 workflow，包括：

• credential changes
• anomalous logins
• file access anomalies
• geographic impossibility
• SaaS irregularities
• user creation
• command-line execution

這表示 CORTEX 並不是先把所有資料一股腦丟給同一組 prompt，而是先做 workflow routing。這個設計的好處很明顯：每種 alert 類型需要查的證據、判讀的條件、可接受的決策規則，本來就不一樣。 例如異常登入與 PowerShell 執行，不可能用同一套調查邏輯硬套。

3. Evidence Acquisition：真正去查工具，而不是只在 prompt 裡猜

第三階段是整篇論文最實務、也最值得記住的部分。Evidence Acquisition Agents 會依 workflow 去呼叫 typed tools，補齊 triage 所需的外部證據。文中列出的代表性工具包括：

• getUserRecord
• getAssetRecord
• searchBehaviorEvents
• searchBehaviorSummaries
• runStructuredQuery
• updateIncidentRecord

這些工具抽象化了對 logs、identity records、asset context 與結構化查詢的存取。作者刻意強調使用 typed APIs 與結構化 JSON schema，原因很簡單：如果要讓調查結果可 audit、可重現，那就不能只靠自由文字描述「模型好像看過某些證據」。

換句話說，CORTEX 的 grounding 不是一般 RAG 式的「找幾段文字當 context」，而是更接近 agentic tool-grounded investigation：模型真的要去查 enterprise systems，再根據查回來的資料推進判斷。

4. Reasoning & Coordination：綜合證據、做保守判斷

最後，Reasoning & Coordination Agent 負責整合各 workflow 的輸出，形成最終的 triage decision、簡短 rationale、observables 與後續 follow-up 建議。論文提到一個很有 SOC 味道的策略：conservative decision policy。具體來說，若任一 workflow 認為應該 escalate，整體 verdict 就會偏向 actionable。

這個設計反映了真實藍隊場域裡一個很重要的偏好：在高風險 triage 裡，系統不該因為追求漂亮的 precision 而輕易壓掉可疑事件。CORTEX 想做的不是把每一件事都樂觀地判 benign，而是在 precision 提升的同時，仍保留對高風險訊號的保守態度。

資料集：這篇論文不只做系統，也補了一個 process-level dataset

很多安全 agent 論文的弱點，是只做 system demo，卻沒有能支撐 process-level evaluation 的資料。CORTEX 比較不一樣，它同時釋出了一個 fine-grained SOC workflow dataset。這個資料集的價值很高，因為它不只給 alert label，而是記錄了：

• 原始 telemetry
• 分析師的逐步行動
• 工具查詢與回傳結果
• 中間觀察與推理
• 最終 adjudication

作者強調資料來自 production environments，涵蓋十多種 scenario，且做了 pseudonymization，以保留結構但去識別。論文中的 schema 描述也相當完整：每筆 JSON trace 會包含 investigated entity、account / tenant、timestamp、riskScore，以及一個核心的 properties 物件，裡面記錄觸發的 behavioral rules 與相關 attributes。

這些 attributes 涵蓋的面向非常貼近 SOC 真實工作：

• identity：Username、ARN、UserType
• network context：ClientIP、City、Country、ISP
• system context：OS、BrowserType、Hostname、Workload
• operational semantics：Operation、EventName、CmdLine、ParentProcess
• artifacts：FileName、ExploitPath
• security annotations：MFA、Severity、Remediation、Verdict

這裡最值得注意的是：作者不是只蒐集 outcome labels，而是蒐集完整 investigation traces。 這讓未來研究不只能學「結果」，還能學「過程」，也比較有可能去評估 step accuracy、tool-policy match、grounding consistency 這類更接近實務可靠性的指標。

實驗設定：拿誰來比？怎麼比？

論文把 CORTEX 與兩種 single-agent baseline 比較：

• Prompt-only：單一 LLM 直接吃 alert JSON，輸出 triage report，不呼叫工具
• ReAct-style tool use：單一 LLM 可使用與 CORTEX 相同的 typed tools，但仍由同一模型規劃與執行整個流程

這個 baseline 設計是合理的，因為它不是拿 CORTEX 去欺負沒有工具能力的簡單模型，而是直接對比「同樣可用工具，但單一 agent vs. 多角色 agent」的差異。作者也明確說明，兩者都建立在同一套 OpenAI Agents SDK 與 MCP 工具介面上，盡量維持公平。

評估指標則分成兩大類：

• Decision quality：actionable / non-actionable macro-F1、non-actionable subclass macro-F1、false-positive rate、recall
• Efficiency：output tokens、tool calls、end-to-end latency

這個設計很好，因為在 SOC triage 場景裡，只看 F1 不夠；只看 latency 更不夠。你必須同時知道：它到底有沒有更準？少了多少 false positive？又為此付出了多少成本？

主要結果：CORTEX 真的有把 false positive 壓下來

這篇論文最重要的結果可以直接記三個數字：

• Actionable F1：從最佳 single-agent baseline 的 0.66 提升到 0.78
• False-positive rate：從 24.9% 降到 14.2%
• Macro-F1：達到 0.82

作者也提到 non-actionable subclasses 的 macro-F1 有大約 +0.15 的提升，表示系統不只比較會分辨「要不要 escalate」，也比較能區分 benign positive、logic-driven false positive、data-driven false positive 與 undetermined 這些不同類型的 non-actionable 案件。

這組結果的意義很大。因為很多 SOC AI 系統只要一談到 accuracy 提升，常常伴隨著 recall 犧牲或判斷邏輯變得更黑箱；但 CORTEX 的賣點在於，它把 precision 與 auditability 一起往前推。特別是在 triage 這種大量處理 benign noise 的工作裡，把 false positive 壓下來本身就非常有 operational value。

效率代價：更準，但真的更慢

不過這篇論文沒有假裝 multi-agent 沒成本。CORTEX 的效率代價其實寫得很誠實。相對於 single-agent baselines：

• Median end-to-end latency：152.4 秒，約 2.54 分鐘
• ReAct-style baseline：約 44.6 秒
• Prompt-only baseline：約 28 秒

換句話說，CORTEX 比 tool-using single-agent 慢了大約 3.42 倍，比 prompt-only 慢了大約 5.44 倍。作者也指出主要原因不是 tool call 次數暴增，而是 token footprint 與 inter-agent message passing 顯著變大：CORTEX 平均處理大約 23,600 tokens，而 tool-using baseline 約為 4,152 tokens。

這個結果非常值得記，因為它提醒我們：multi-agent 架構帶來的提升，很多時候不是免費午餐。 在實務上，你得真的衡量這些準確度改善，值不值得換來 2–5 倍的延遲與 token 成本。作者的回答是：對高風險 alert triage 而言，若整體仍能維持在 SOC triage SLO 約 3 分鐘以內，這種 trade-off 是合理的。

這篇論文真正有價值的地方，不只是分數

如果只看 headline，可能會把 CORTEX 當成又一篇「multi-agent 比 single-agent 好」的 paper。但我認為它真正有內容的地方至少有四個：

1. 它把 SOC triage 視為 workflow，不是 chat task
2. 它把 tool use 做成 typed、可 audit 的實體，而不是模糊的 function calling demo
3. 它補了一個 process-level dataset，讓後續研究可以評估過程而不只看結果
4. 它誠實面對效率成本，沒有把 multi-agent 神化成免費提升

尤其第一點最值得強調。SOC triage 的本質從來不是「模型會不會說出一個像樣的答案」，而是：它有沒有沿著正確 workflow 去查證據、做出可回溯的保守判斷，並把決策留下可以被 analyst 檢查的痕跡。 CORTEX 的架構設計，基本上就是在圍繞這件事。

限制與風險

論文最後也沒有把自己包裝成萬能解法。作者坦白列出幾個限制：

• dataset coverage 仍有限：目前雖涵蓋十多種 scenario，但不代表已覆蓋企業 SOC 的全貌
• 依賴上游 telemetry 品質：若工具回傳不完整或資料本身有缺口，後續推理一樣會受影響
• agentic systems 仍面臨 distribution shift、prompt injection、incomplete context 等典型風險
• 成本與延遲仍偏高：若要大規模落地，還需要進一步做 distillation 或 tool budgeting

作者提出的後續方向也很合理，包括更強的 termination / verification protocol、adaptive tool budgeting、把 multi-agent traces distill 成更小的 single-model policy，以及從 analyst feedback 持續學習。這些都表示作者很清楚：CORTEX 比較像一個可靠架構模板，而不是已經最終定型的量產答案。

和近期幾篇 SOC / CTI 論文怎麼接？

如果把這篇放進最近的閱讀序列，可以大概這樣定位：

• CyberSOCEval：問模型在 malware analysis 與 TI reasoning 上到底行不行
• LLMs in the SOC：看真實分析師到底怎麼把 LLM 當成工作輔助
• ExCyTIn-Bench：評估 agent 能不能沿 investigation graph 在安全日誌裡查資料
• CORTEX：把 role-specialized multi-agent 與 tool-grounded workflow 放進 high-stakes alert triage，直接碰實際 SOC noise 問題

也就是說，這篇不只是 benchmark paper，也不只是 usage study，而是比較接近 operational architecture paper。它試圖回答的是：如果真的要把 LLM agent 放到告警分流第一線，系統應該長什麼樣子？

重點整理

• CORTEX 針對的是 high-stakes SOC alert triage，不是一般資安問答。
• 核心架構由 Orchestrator、Behavior Analysis、Evidence Acquisition、Reasoning & Coordination 四類角色組成。
• 系統實際落地成 七類 workflow，並透過 typed tools 去查使用者、資產、行為事件與結構化查詢。
• 論文同時釋出 fine-grained SOC workflow dataset，保留 tool queries、intermediate observations 與 final adjudication。
• 實驗顯示 CORTEX 把 actionable F1 從 0.66 提升到 0.78，並把 false-positive rate 從 24.9% 降到 14.2%。
• 代價是 latency 與 token 成本顯著增加：中位數處理時間約 152.4 秒。
• 這篇論文最大的價值，在於它把 SOC triage 從單一模型判斷題，重新定義成 可 audit、可 grounding、可流程化的 agent collaboration problem。

Takeaway

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

CORTEX 真正證明的，不是「多個 agent 比一個 agent 酷」，而是：在 SOC 這種高風險場景裡，只有當 LLM 被放進一條有角色分工、有工具約束、有證據鏈與可稽核輸出的工作流時，它才比較像一個可以被信任的 triage 系統。

這對 sectools.tw 的讀者很有意思，因為它讓我們看到下一階段的 SOC AI 論文，焦點不再只是 benchmark 分數或 prompt 技巧，而是流程設計、證據治理、auditability 與 operational trade-off。從這個角度看，CORTEX 是一篇很值得補進「SOC × LLM × Agent」閱讀地圖裡的 paper。

免責聲明

本文由 AI 產生、整理與撰寫，內容主要依據公開論文、技術文件與可取得之研究資料進行彙整、解讀與摘要。儘管已盡力確保內容之完整性與可讀性，仍可能因模型理解限制、資料來源差異或語意轉譯過程而存在疏漏、不精確或更新延遲之處。本文內容僅供研究交流與知識分享參考，實際技術細節、實驗設定與最終結論，仍應以原始論文、官方文件及作者公開資料為準。