IRCopilot 論文閱讀分析：用大型語言模型自動化 Incident Response

論文基本資訊

• 論文標題：IRCopilot: Automated Incident Response with Large Language Models
• 作者：Xihuan Lin、Jie Zhang、Gelei Deng、Tianzhe Liu、Tianwei Zhang、Qing Guo、Riqing Chen
• 會議：ACM CCS 2025
• 年份：2025
• arXiv：https://arxiv.org/abs/2505.20945
• 主題：Incident Response、LLM、SOC Automation、Security Operations、AI for Security

如果前面幾篇 sectools.tw 的文章，比較多集中在 CTI 抽取、RAG 問答、威脅歸因、知識圖譜，那這篇 IRCopilot 值得看的地方，在於它把焦點往後推了一步：不是只幫你理解威脅，而是直接介入事件處置（incident response）流程。

這件事很重要。因為資安現場真正最缺的，通常不是「再多一個知道很多名詞的模型」，而是 在告警發生後，能不能把分析、判斷、執行建議與修復步驟串成一條實際可用的流程。IRCopilot 正是在回答這個問題。

作者先建立一個以真實 IR 任務為基礎的 benchmark，證明目前主流 LLM 直接拿來做 incident response 其實有不少問題；接著再提出一套 四個 LLM session component 協作 的框架，讓模型分工完成規劃、生成、分析與反思。這種設計的核心精神很清楚：不要把 IR 當成單輪問答，而要把它當成一個需要角色分工、迭代修正與上下文管理的動態工作流。

研究問題：這篇論文想解決什麼？

作者的問題意識其實很務實。今天大家都知道 LLM 在文字理解、摘要、知識查詢、程式輔助方面很強，但真要把它放進 IR 現場，馬上會遇到幾個問題：

• 上下文容易遺失：事件處置往往跨多步驟、多證據來源，不是單輪 prompt 能解決
• 容易產生 hallucination：若命令、判斷或處置建議錯了，代價遠高於一般問答任務
• 缺少場景化決策能力：IR 不是單純回答「是什麼」，而是要回答「下一步應該做什麼」
• 隱私與敏感資訊風險：事件處置常涉及 log、主機資訊、帳號、網段與內部細節

因此，這篇論文真正要回答的是：

大型語言模型能不能從「看起來懂資安」進一步變成「真的能協助事件應變」？如果可以，需要什麼樣的任務設計、分工架構與評測方式？

這也是為什麼 IRCopilot 不是只提出一個 system，而是同時提出兩個核心貢獻：

• 一個 incident response benchmark
• 一套可操作的 LLM-based IR framework

先做 Benchmark：為什麼這一步很關鍵？

很多「AI for Security」論文的問題，是 system demo 很炫，但評估很薄。IRCopilot 倒是先從評估做起。作者認為，若連 incident response 到底要怎麼衡量 都講不清楚，那後面任何自動化主張都很容易流於 impressionistic demo。

因此他們建立了一個 IR benchmark，涵蓋三個常見平台：

• TryHackMe
• XuanJi
• ZGSF

總共包含：

• 12 個 case machines
• 130 個 sub-tasks

這些任務被映射到 NIST 3.0 所對應的 IR 三大階段：

• Detect
• Respond
• Recover

這個 benchmark 的價值很高，因為它讓 IR 不再只是一句抽象的「幫我處理事件」，而是拆成可觀察、可比對、可量化的子任務。對研究與實務都很重要：你才能知道模型到底是卡在辨識、推理、指令生成，還是卡在多步驟上下文維持。

作者先證明一件事：直接拿 LLM 做 IR，效果其實不夠好

在提出 IRCopilot 之前，作者先做了探索性評估，直接測試多個現成 LLM 在 IR benchmark 上的表現，包括：

• GPT-4
• GPT-4o
• Claude-3.5-Sonnet
• GPT-o1
• DeepSeek-V3

結果並不意外，但很有說服力：這些模型即使語言能力很強，遇到真實的 incident response 任務仍然會出現系統性短板。 作者整理出的主要問題包括：

• 不容易制定正確的 response strategy
• 會產生不精確甚至錯誤的指令建議
• 容易忽略關鍵細節與證據鏈
• 長流程任務中的記憶保持能力不足
• 在敏感資料處理上存在風險

這個部分很值得 sectools.tw 讀者注意，因為它提醒我們：把 LLM 接進 SOC 或 IR 流程，不是 prompt 調一調就好。 問題不只在模型知不知道答案，而在它能不能穩定、連續、場景化地完成處置工作。

IRCopilot 的核心想法：把 IR 拆成角色分工，而不是單一 Agent 硬幹到底

IRCopilot 最值得看的地方，就是它沒有把所有責任丟給同一個 LLM。作者提出的是一個 四角色協作式架構：

• Planner：負責整體規劃與任務拆解
• Generator：負責根據規劃生成具體操作與執行方案
• Analyst：負責分析執行結果、判斷目前狀態與後續方向
• Reflector：負責整體回顧與修正，形成持續優化閉環

整體上，它對應三種思考階段：

Reasoning → Action → Reflection

這個設計背後的邏輯其實很像真正的 incident response 團隊：不是一個人從判斷、下命令、驗證結果、修正策略全部一口氣做完，而是透過不同角色分工，降低失誤、減少上下文混亂，並提升多步驟任務的一致性。

換句話說，IRCopilot 的真正貢獻不是「又一個 multi-agent」，而是它把 IR workflow 的組織邏輯 映射進 LLM system design。這比單純喊 agentic AI 更有內容。

四個角色各自做什麼？

1. Planner：先決定方向，不急著下指令

Planner 的工作，是在面對 incident 時先回答：這個事件目前最該處理的是什麼？整體任務要怎麼拆？先後順序為何？

這一步很重要，因為很多 LLM 失敗，不是因為不懂單一步驟，而是從一開始就把整個事件理解錯、順序排錯、優先級判錯。作者等於是先把「策略規劃」從「命令生成」中抽離，避免模型一看到問題就直接開始亂下指令。

2. Generator：把抽象策略轉成可執行操作

當 Planner 已經把任務拆開，Generator 才負責輸出更具體的執行方案，例如要看哪些 artefacts、要蒐集哪些證據、應採取哪些調查或處置步驟。

這種分工的優勢是：每次 Generator 處理的是局部子任務，而不是整包 incident context。作者認為這能有效降低 attention / memory 壓力，也減少模型在長流程中越走越偏的問題。

3. Analyst：看結果，不只是產生下一句

Analyst 不是單純摘要輸出，而是負責分析執行後得到的資訊，判斷目前證據支持什麼結論、還缺什麼、後續要回饋 Planner 哪些新判斷。

這個角色的存在，讓 system 不會變成單向流水線，而是能根據新資訊修正策略。這很符合真實 IR：很多時候你不是照著 runbook 一路到底，而是邊查邊調整。

4. Reflector：避免錯誤一路滾大

Reflector 則比較像品質控制與後設檢查。它會回顧整體執行過程、整合多來源資訊，提出可能的改進方向與修正建議。

從工程角度看，這等於是把「self-correction」顯式模組化。對 IR 這種高風險任務來說，這比一般聊天任務更有必要，因為錯的建議不只是答非所問，而可能真的影響調查與修復節奏。

這種架構到底改善了什麼？

作者的主張是，透過職責切分與不同 prompt 設計，IRCopilot 可以更好地處理以下問題：

• 降低 hallucination：因為每個角色處理的責任範圍更清楚
• 減少 context loss：因為整體流程被拆成更小、更可控的步驟
• 提升決策合理性：Planner 與 Analyst 形成策略規劃與結果分析閉環
• 改善多步驟任務成功率：不再讓模型直接 zero-shot 整條 incident response sequence

這背後其實反映一個很關鍵的觀點：IR 不是純知識問答，而是有狀態轉移、有優先級、有風險控管的動態決策過程。 所以系統設計必須針對 workflow，而不只是針對文本生成。

實驗結果：IRCopilot 比直接用 baseline LLM 好多少？

根據論文摘要與內文，IRCopilot 在 benchmark 上相對於直接使用 baseline LLM，有很明顯的提升。作者報告的 sub-task completion rate 改善幅度包括：

• 相對 GPT-4：150%
• 相對 DeepSeek-V3：138%
• 相對 GPT-4o：136%
• 相對 Claude-3.5-Sonnet：119%
• 相對 GPT-o1：114%

這些數字要怎麼解讀？我認為重點不是「誰贏幾個百分點」而已，而是：只靠換更強的模型，改善有限；但把流程設計與角色分工做好，改善幅度反而更顯著。

這也是這篇論文對產業界最有價值的提醒：未來 SOC/IR 自動化的競爭力，很可能不只是模型本身，而是 workflow orchestration + task decomposition + validation loop。

不只在 benchmark 上測，還拿去真實情境驗證

作者沒有只停在 benchmark score。論文還提到，IRCopilot 進一步在公開 incident response 平台與真實攻擊案例中做驗證，包含：

• TryHackMe
• XuanJi
• ZGSF
• 5 個 real-world network attack cases

結果顯示，IRCopilot 能在多數任務中有效完成事件處置相關工作，並從真實攻擊案例中辨識與提取關鍵痕跡與資訊。這點很關鍵，因為它代表系統不是只在 toy problem 上成功，而是至少開始接近實戰驗證。

當然，我會保守看待「接近實戰」這幾個字。因為真正企業現場的 IR，比賽平台或研究案例還多了：

• 組態差異
• 權限限制
• 誤判成本
• 合規要求
• 跨團隊協作摩擦

不過就研究論文來說，IRCopilot 已經比很多只做單點任務的 paper 更接近 operational reality。

這篇論文真正有意思的地方，不只是「自動化」兩個字

我認為 IRCopilot 最有價值的地方，是它把 incident response 問題重新定義成一種 有角色、有階段、有反饋迴路的 AI 協作系統，而不是把 LLM 當成一個單純生成器。

這個方向為什麼重要？因為在資安領域，很多工作都不是單步分類題。它們更像：

• 收集證據
• 建立假設
• 驗證假設
• 選擇風險最低但有效的處置方案
• 持續修正策略

這種工作天生就比較適合 workflow-based AI，而不是 one-shot AI。IRCopilot 正好提供了一個具體範例：如何把 LLM 系統設計得更像一支 incident response team，而不是一個會說話的搜尋框。

限制與風險：這篇論文還沒解決什麼？

雖然這篇論文很值得看，但也不能把它想得太完美。至少有幾個限制值得記住：

• 仍高度依賴 backbone LLM 能力：分工可以緩解問題，但不會把弱模型變成強模型
• 評估仍以研究環境為主：真實企業 IR 的合規、權限、流程約束更複雜
• 錯誤建議的風險仍存在：尤其在命令生成與場景判斷上，需要人類審核
• 敏感資料處理仍是關鍵議題：IR 場景天然涉及大量內部資訊，不是每個組織都能放心把 context 丟進外部模型

換句話說，IRCopilot 並不是在說「AI 已經可以完全接管 incident response」，而是在說：若要讓 LLM 真正進入 IR 流程，系統設計必須比一般問答應用嚴謹得多。

對 SOC / CSIRT 實務的啟示

如果從實務角度看，這篇論文至少提供了幾個值得帶回去思考的方向：

• 不要把 IR 助理做成單一聊天介面，而要有規劃、執行、驗證、反思等模組
• 先定義可量化的 IR 子任務，再談自動化，不然很難知道 AI 到底幫了什麼
• 人類 analyst 仍應保留最終裁決權，尤其在 containment、eradication、recovery 等高風險步驟
• 模型能力之外，流程治理更重要：包含資料治理、審計、權限、回溯與安全防護

如果你正在設計 SOC Copilot、IR assistant、或任何安全自動化代理系統，IRCopilot 的價值就在這裡：它提供的不是一句「用 agent 就好」，而是比較接近一套可以被拆解、被討論、被落地的設計框架。

重點整理

• IRCopilot 聚焦的是 automated incident response，不是單純 CTI 問答或威脅摘要。
• 作者先建立一個涵蓋 3 個平台、12 個 case machines、130 個 sub-tasks 的 IR benchmark。
• 研究顯示，直接使用現成 LLM 做 IR，會遭遇 context loss、hallucination、策略錯誤與隱私風險。
• IRCopilot 採用 Planner、Generator、Analyst、Reflector 四角色協作架構。
• 這套系統把 IR 流程拆成 reasoning、action、reflection 三大階段，降低單一模型承擔全部工作的壓力。
• 在 benchmark 上，IRCopilot 相對多個 baseline LLM 都有明顯提升，最高達 150% 的 sub-task completion rate 改善。
• 它的真正價值在於：把 LLM 應用從「會回答」推進到「能協助處置」。

Takeaway

如果要用一句話總結這篇論文，我會這樣寫：

IRCopilot 的重點，不是證明 LLM 已經能全面取代 incident responder，而是證明：當你把事件應變視為一個需要規劃、執行、驗證與反思的工作流時，LLM 才開始真正接近可用。

對 sectools.tw 這類讀者來說，這篇 paper 很值得關注，因為它比很多泛泛而談的「AI for SOC」內容更踏實。它沒有假裝所有問題都解決了，而是很清楚地指出：要讓 AI 進入資安實戰流程，關鍵不只是模型更大，而是 system design 要更像真正的安全團隊。

免責聲明

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