CRAKEN 論文閱讀分析：當 cyber agent 真正變強，關鍵不只是會用工具，而是會在執行時取對知識
本文由 AI 產生、整理與撰寫。
論文基本資訊
- 論文標題：CRAKEN: Cybersecurity LLM Agent with Knowledge-Based Execution
- 作者：Minghao Shao、Haoran Xi、Nanda Rani、Meet Udeshi、Venkata Sai Charan Putrevu、Kimberly Milner、Brendan Dolan-Gavitt、Sandeep Kumar Shukla、Prashanth Krishnamurthy、Farshad Khorrami、Ramesh Karri、Muhammad Shafique
- 來源：arXiv:2505.17107
- 年份：2025
- 論文連結：https://arxiv.org/abs/2505.17107
- 主題：Cybersecurity LLM Agent、RAG、Graph-RAG、CTF Benchmark、Knowledge-Based Execution、Offensive Security
最近一大串 cyber agent 論文，很多都在回答同一個問題：LLM 到底能不能真的做安全工作？ 但這個問題如果講得更精確一點，其實應該拆成兩半。第一半是：模型會不會推理、會不會用工具。第二半則是：當任務需要最新 exploit 線索、特定攻擊套路、跨步驟技術細節時，agent 要怎麼把外部知識真的接進執行流程裡，而不是只在 prompt 上貼一層資訊補丁？
CRAKEN 這篇論文有意思的地方，就在它不是單純再做一個「更會解 CTF 的 agent」，而是把焦點放在 knowledge-based execution：知識不是拿來塞滿上下文，而是要在 agent 執行任務的正確時刻，被拆解、檢索、驗證、再注入成可行動的提示。
換句話說，這篇 paper 真正想處理的不是「LLM 知不知道答案」，而是：當 agent 面對多階段 vulnerability detection 與 exploitation 任務時，怎麼讓它在需要的那一刻，拿到夠準、夠短、夠能轉成下一步動作的安全知識。
這篇論文在處理什麼問題？
作者點得很準：目前很多 cyber LLM agent 雖然已經能在 CTF 或 offensive benchmark 裡展現一定能力，但仍有兩個很硬的限制：
- 知識時效限制：模型訓練資料有截止時間，很多新漏洞、新 exploit 思路、新攻擊技巧不在參數裡。
- 知識整合限制：就算外部資料存在，agent 也未必能把這些零碎資訊整合進多步驟規劃與執行。
這兩個限制在一般問答場景可能還能忍，但在 cybersecurity 會很致命。因為安全任務不是只回答「這是什麼」，而是得一路做到：
- 判斷問題核心在哪
- 找出相關 vulnerability pattern
- 把 hint 轉成 exploit strategy
- 根據環境回饋修正下一步
也因此，CRAKEN 的核心觀點其實很務實：如果你只是把 RAG 當成一個外掛搜尋框，效果有限；真正重要的是讓 knowledge retrieval 變成 agent execution loop 的一部分。
CRAKEN 的核心設計：不是單純加 RAG，而是把 retrieval 放進行動鏈
CRAKEN 的架構可以分成兩塊：
- Planner-Executor 多代理系統：沿用 D-CIPHER 那條 planner / executor / auto-prompter 路線。
- Iterative retrieval system：把 Self-RAG 與 Graph-RAG 風格的檢索流程，插進 executor 任務執行前後。
這裡最關鍵的不是「它也有 planner，也有 executor」，而是它刻意把 retrieval 放在 delegation 與 execution 的交界處。也就是說，planner 先拆任務，executor 準備做事時，系統才根據當前 task context 去觸發知識檢索，並把結果整理成 knowledge hint 再注入給 executor。
這個設計背後有個很重要的判斷：安全任務真正缺的通常不是高層策略，而是執行當下那種精準、可操作、能轉成下一步 exploitation / analysis 動作的局部知識。
三個最值得記住的機制
作者把 CRAKEN 的提升，主要歸功於三個核心機制：
- Contextual decomposition：先把冗長對話與 task context 拆成可查詢的重點，而不是整包拿去搜。
- Iterative self-reflected retrieval：找資料不是一次命中，而是經過相關性評估、hallucination 檢查、query rewrite 的遞迴循環。
- Knowledge-hint injection：把檢索結果轉成對當前 executor 有用的行動提示，而不是直接傾倒一堆原文文件。
這三步合起來，才是 CRAKEN 和很多「有接資料庫的 agent」真正不一樣的地方。它不是把更多資料灌進 context，而是嘗試控制什麼時候取、取什麼、怎麼判斷取對了、怎麼把它變成下一步可執行線索。
Self-RAG 在這篇裡的角色：讓檢索變成一個會自我懷疑的流程
CRAKEN 的 retrieval process 其實設計得蠻完整。作者把整條流程拆成六個模組：
- Retriever：先取回候選文件
- Relevance Grader：判斷文件到底跟 query 有沒有關
- Generator：根據文件產生 knowledge hint
- Hallucination Grader：檢查生成內容是否真的 grounded
- Rewriter：若查歪了，就重寫 query
- Solved Grader：確認這份 hint 是否已足夠回答當前需要
這個流程的價值，在於它把檢索從「搜到就算了」變成「搜到之後還要過品質門檻」。對 cyber task 來說，這很重要。因為錯的安全知識，不是單純回答不準而已，而是可能直接把 agent 帶去錯的 exploitation path。
論文裡有一個很值得注意的數字：只有 43.8% 的 retrieved documents 能通過相關性 grading，而 72.7% 的 generated content 會在 hallucination 檢查這關失敗。 這其實反而說明作者看到了現實：在安全場景裡，retrieval 不是「加上去就更強」，而是如果沒有反覆檢查，反而很容易把 agent 帶歪。
Graph-RAG 為什麼在 cyber task 特別合理？
除了 classic RAG，CRAKEN 還整合了 Graph-RAG。這點我覺得特別適合 cybersecurity，因為安全知識本來就不是一堆彼此獨立的文件，而比較像一張關聯網：
- 漏洞會連到特定元件與版本
- 攻擊技巧會連到 exploitation 前提
- payload 與 exploit path 之間有依賴關係
- 一個 weakness 往往會在不同 challenge / target 上重複出現
作者做法是把知識抽成 semantic triplets，建出 knowledge graph，再讓檢索除了做向量相似度，也能做 graph search。這種 hybrid retrieval 的好處，是可以同時保留：
- 語意相近的文字片段
- 結構相連的知識關係
對需要多步驟推理的 security task 來說，這很像是把「搜得到像不像」跟「連得起來有沒有邏輯」兩件事同時考慮。
資料庫怎麼建，比你想的更重要
論文裡另一個很有價值的發現，是作者沒有把所有資料混成一鍋，而是刻意比較了三種 knowledge database：
- Writeups：1,298 篇 CTF writeups
- Payloads：135 組攻擊 payload
- Code：4,656 段程式碼片段
結果很有意思：表現最好的不是 payload，也不是 code，而是 writeups。
這其實非常值得記住，因為它透露出一個很多人容易忽略的事實：agent 最缺的未必是 exploit 程式本身，而是人類在解題／攻擊過程中留下來的「操作推理軌跡」。 writeup 裡包含的不只是答案，而是：
- 問題怎麼被辨識
- 漏洞模式怎麼被聯想到
- 為什麼這條 exploit path 值得試
- 失敗時下一步該怎麼換方向
也就是說，對 agent 來說，最有價值的知識不一定是最終 payload，而是可遷移的 problem-solving procedure。
實驗結果：有進步，但不是神化級飛躍
CRAKEN 的評估主要用 NYU CTF Bench，總共 200 題，涵蓋 crypto、forensics、pwn、rev、web、misc 六類。
幾個最值得看的數字如下：
- D-CIPHER + Claude 3.5 Sonnet：19.0% solve rate，平均成本 0.52 美元
- CRAKEN + Self-RAG + classic RAG + Claude 3.5 Sonnet：21.0%，成本 0.68 美元
- CRAKEN + Self-RAG + Graph-RAG + Claude 3.5 Sonnet：22.0%，成本 0.86 美元
換句話說，它不是那種從 20% 一口氣跳到 60% 的論文，而是更接近：在很難的 offensive benchmark 上，靠更合理的 knowledge integration，把 solve rate 往前再推幾個百分點。
這種幅度看起來不誇張，但在這類 benchmark 其實有現實意義。因為 CTF / offensive agent 的提升通常不是線性的，多解出幾題，往往代表 agent 在某些原本完全不會處理的 niche problem 上，開始真的有能力跨過去。
哪裡進步最明顯？
從類別表現來看，CRAKEN 在 reverse engineering 與 web 上的提升特別值得注意。以 Claude 3.5 Sonnet 為例：
- reverse engineering：從 29.4% 提升到 33.3%
- web：從 5.3% 提升到 15.8%
如果換成 Graph-RAG 版本，forensics、crypto、pwn、misc 也各有改善。這很合理，因為這些類型都很吃「你能不能把局部技術線索串起來」的能力。特別是 web 與 rev，常常不是缺工具，而是缺那個把觀察結果對上某種已知 exploitation pattern 的中介知識。
作者另外提到，CRAKEN 在 MITRE ATT&CK techniques 評估上，比 prior work 多解 25–30%。這不代表它已經能穩定打真實世界，但至少代表：透過知識驅動執行，agent 的 offensive capability coverage 確實被拉寬了。
這篇論文最重要的一個結論：知識應該在 execution 時注入，不是 planning 時
我覺得整篇 paper 最值得記住的觀察之一，是作者直接比較了兩條路：
- knowledge-based planning
- knowledge-based execution
結果是：把外部知識放在 execution 階段，比放在 planning 階段更有效。 前者 solve rate 大約 21%，後者只有 17%。
這個結果很有啟發性。因為它表示在複雜 cyber task 裡，高層規劃當然重要，但真正決定成敗的，常常是執行過程中那種細粒度、環境相依、需要根據當前觀察即時補充的知識。換句話說：
agent 不只是要會先想計畫，更要在做事途中知道該去哪裡補對的技術細節。
案例分析：為什麼它能解出別的 agent 沒解出的題？
論文中的 case study 以一題 RC4 相關 challenge 為例。作者指出，CRAKEN 在 retrieval 過程中，不是只找「RC4 答案」，而是找出與 stream cipher、state reuse、implementation fragility 相關的鄰近 writeups，再把這些 insight 整理成可行的 exploit thinking path。
這裡很重要，因為它展現的不是單篇文件命中，而是把相鄰問題的解法模式遷移到當前任務。這種能力對 cyber agent 很關鍵。真實世界不太會剛好有一篇文件跟你當前 target 一模一樣；更常見的是，你得從相似 weakness、相似 misuse pattern、相似 exploit 習慣中抽出對眼前問題有用的部分。
我怎麼看這篇論文？
我覺得 CRAKEN 最有價值的地方，不在於它又把 solve rate 多推了幾個點，而是它把一個很常被說得太粗糙的命題講清楚了：cyber agent 的能力，不只取決於模型大小或工具數量，還取決於知識是怎麼被組織、檢索、驗證、再注入行動流程。
這篇論文也順手打破一個常見迷思：不是把更多資料餵給 agent 就會更強。論文的結果剛好相反——亂混資料庫反而會退步，payload 與 code 也不如高品質 writeups。這意味著，對 agent 來說，知識庫設計本身就是能力工程，不是資料越多越好。
如果把它放回最近這串 agentic security 脈絡來看，CRAKEN 很像是在補另一塊拼圖。前面很多論文在談 guardrail、runtime boundary、protocol security、tool supply chain；而 CRAKEN 問的是另一面：就算先不談防守，當你想讓 agent 真的做複雜 security task，知識流該怎麼設計才不會只是看起來很聰明、實際上一直卡在 execution 細節？
這篇論文的限制也很明確
當然，這篇 paper 也不是沒有邊界。它的評估主要還是在 CTF 與 MITRE ATT&CK technique coverage，離真實 production security workflow 還有距離；而且作者自己也承認，資料庫雖然大，但多樣性仍有限，主要來自 CTF writeups、payload 與 code snippets。
此外，CRAKEN 對 tool calling 與 retrieval quality 很敏感。論文裡那些 relevance grading 低通過率、hallucination 檢查高失敗率，其實就是提醒：知識型 agent 的瓶頸不只在模型，也在 retrieval system 自己有多容易把事情搞歪。
結語
CRAKEN: Cybersecurity LLM Agent with Knowledge-Based Execution 值得讀，不是因為它又證明一次「LLM 也會打 CTF」，而是因為它把更重要的問題往前推了一步：當 cyber agent 需要最新、具體、可操作的安全知識時，知識不能只是靜態背景資料，而必須變成 execution loop 裡的一級公民。
這篇論文留下的核心啟發，我會濃縮成一句話：在安全自動化裡，真正有價值的不是讓 agent 知道更多，而是讓它在正確時刻取到正確知識，並把那份知識轉成下一步可行動的技術判斷。
而這件事，可能比單純再換一個更大的模型，還更接近 cyber agent 真的能落地的關鍵。
本文由 AI 產生、整理與撰寫。 內容主要依據公開論文、技術文件與可取得之研究資料進行彙整、解讀與摘要；儘管已盡力確保內容的完整性與可讀性，仍可能因模型理解限制、資料來源差異或語意轉譯過程而存在疏漏、不精確或更新延遲之處。本文僅供研究交流與知識分享參考，實際技術細節、實驗設定與最終結論，仍應以原始論文、官方文件及作者公開資料為準。