Co-RedTeam 論文閱讀分析：當自動化 Red Team 不再只是會寫 Exploit，而是開始像研究員一樣找、驗、修、再學
論文基本資訊
- 論文標題：Co-RedTeam: Orchestrated Security Discovery and Exploitation with LLM Agents
- 年份：2026
- arXiv：https://arxiv.org/abs/2602.02164
- 作者：Ash Fox、Lesly Miculicich、Stefan Friedli、Daniel Fabian、Burak Gokturk、Jiliang Tang、Chen-Yu Lee、Tomas Pfister、Long T. Le
- 主題：LLM Agent、Red Teaming、Vulnerability Discovery、Exploit Planning、Execution Feedback、Long-term Memory
如果最近 sectools.tw 這串文章，已經一路把 agent skill 供應鏈、runtime trust boundary、system prompt policy surface、multi-agent delegation 與 autonomous defense 這些線慢慢拼起來，那下一個其實很自然會撞上的問題就是：當我們一直在討論怎麼防 agent 出事，有沒有認真問過——攻擊方那一側的 agent，到底已經進化到什麼程度？
這篇 Co-RedTeam 有意思的地方，就在於它不是再做一個「會幫你寫 exploit 程式」的單點 demo，而是試著把 真實 red teaming workflow 裡最麻煩的幾個環節——看 code、找弱點、提假設、做批判、規劃攻擊、真的執行、根據失敗回修、把成功經驗記下來——整條接成一個多代理人流程。
也因此，這篇 paper 真正想回答的，不是「LLM 會不會寫 payload」，而是另一個更關鍵、也更現實的問題：
如果自動化 red teaming 要變得真的有操作價值，關鍵究竟是不是更大的模型，還是更像人類安全研究員的工作分工、執行回饋與經驗累積？
這篇論文在解哪個痛點？
作者對既有 LLM security agent 的批評，我覺得打得很準。現在很多 vulnerability discovery / exploitation agent 的瓶頸，不是完全不會做，而是常常卡在三個老問題：
- single-shot reasoning 太脆：模型一次講得很像樣，但實際上沒走完驗證鏈。
- 缺少 execution grounding：它會提假設、會產 payload，但沒有把真實執行結果當成主迴圈的一部分。
- 沒有 experience reuse：每次遇到新目標都像失憶，前一次踩過的坑、成功過的技術路線，都沒有真的留下來。
這三件事加起來，就會讓很多 security agent 看起來很聰明，但一進到大 codebase、長鏈 exploit、反覆修正假設的場景後，很快就開始打轉。它可能知道 SSRF、XSS、deserialization 這些詞，但不知道怎麼把「懷疑」一路推進成「可重現的漏洞證據」。
Co-RedTeam 的核心主張非常明確：要讓 LLM 真正像 red team 一樣工作，不能只靠模型會說，而要把 安全知識、code-aware analysis、execution-driven iteration 與長期記憶 一起設計進去。
核心架構：不是一個 agent，而是一條分工清楚的攻擊工作流
Co-RedTeam 由一個 orchestrator 協調，分成兩個主要階段：
- Stage I：Vulnerability Discovery
- Stage II：Iterative Exploitation
這個切法很重要。因為它等於承認了：找漏洞 和 證實漏洞 不是同一種認知工作。前者偏靜態分析、證據組織、弱點分類；後者偏計畫執行、失敗修正、環境互動與 exploit 驗證。
很多看起來很猛的 autonomous security demo，問題就在這裡：它把整件事當成單一問答任務，好像只要 prompt 寫對，模型就會自己一路從 code review 走到 PoC。Co-RedTeam 反而比較老派、也比較實務：先承認 workflow 本來就有不同工種，再讓 agent 各做各的。
第一階段：Vulnerability Discovery 不是亂猜，而是要有 evidence chain
在 discovery 階段，作者讓 Analysis agent 負責主分析，再由 Critique agent 做內部審查。這個設計看似普通，但它把一個很關鍵的 red-team 習慣帶了進來：不是先追求找到很多洞，而是先追求把每個洞講得夠像回事。
Analysis agent 會做幾件事：
- 用 code-browsing tools 掃目錄、看檔案、抓 code snippet
- 結合 CWE / OWASP 等 structured security knowledge
- 沿著 input source、data flow、sensitive sink 去建立漏洞假設
- 為每個 candidate vulnerability 組出 file-level / line-level evidence
這裡最值得注意的是它強調的 evidence chain。也就是說，它不是只輸出「這裡可能有 SQL injection」，而是要把：
- 不可信輸入從哪裡進來
- 中間怎麼流
- 最後落在哪個危險 sink
- 為什麼現有驗證或 sanitization 不夠
這條鏈講清楚。
接著 Critique agent 會像內部 reviewer 一樣，對每個候選漏洞做風險等級與審查狀態標記：approved、rejected、needs refinement。證據不夠的就退回去補，太薄弱的就直接砍掉。這一步其實很像把 security review 裡的「第二雙眼睛」制度內建進 agent 流程。
我認為這是這篇比很多 generic coding agent 更像 security workflow 的地方。因為真正的漏洞分析，從來都不是 first-pass intuition 就能直接交付；它需要一個會懷疑自己的機制。
第二階段：Iterative Exploitation 的重點不是會打，而是會修
如果說 discovery 階段在解決「這洞是不是真的存在」，那 exploitation 階段處理的就是另一個更痛的問題：就算漏洞方向對了，實際 exploit 也常常第一次根本打不通。
這正是 Co-RedTeam 另一個很有意思的地方。它沒有把 exploit generation 當成一次性產出，而是把它建模成一個 plan → validate → execute → evaluate 的閉環。
這個階段包含幾個角色：
- Planner agent：把攻擊拆成可追蹤的多步驟 Exploit Plan
- Validation agent：先檢查 action 是否合理、語法是否正確、是否符合目前狀態
- Execution agent：在隔離 Docker 環境中真的執行 command / script
- Evaluation agent：把低階 stdout / stderr / status 轉譯成下一輪規劃需要的高階訊號
這裡最關鍵的，不是「多加了幾個 agent」，而是作者明確把 exploit 當成 structured search process。也就是說，失敗不是結束，而是規劃輸入。Planner 會記錄某一步是 done、planned 還是 blocked；如果某個路徑失敗，它不是直接亂試下一個 payload，而是回頭更新 Exploit Plan，調整檔案路徑、環境假設、payload 類型，甚至改掉後面原本打算做的步驟。
這其實很像人類研究員在做的事：不是因為你會下 command 就叫 exploitation，而是你能不能根據失敗回饋縮小可能性空間。
Validation agent 這一層，反而是很多 agent system 最容易少掉的東西
我自己很喜歡這篇把 Validation agent 單獨拉出來。因為在高風險 execution task 裡，很多錯誤不是「想法完全錯」，而是 action 本身不夠可執行：
- command syntax 寫錯
- 前提不成立
- 目標狀態判斷錯
- 執行順序不合理
- 行為和目前 exploit goal 不對齊
如果少了這個 validation gate，agent 很容易陷入一種假性努力：看起來一直有新嘗試，實際上只是在錯的路上愈走愈遠。Co-RedTeam 把這層做成顯式元件，等於是在提醒大家：真正可靠的 offensive agent，不是更敢執行，而是先把執行前的 sanity check 做扎實。
長期記憶：這篇不是把 memory 當裝飾，而是當能力複利機制
最近很多 agent paper 都會提 memory，但不少時候 memory 比較像 feature checklist：有放就算有。Co-RedTeam 比較不一樣，它把 memory 明確拆成三層，而且每層都對應不同推理粒度：
- Vulnerability Pattern Memory：記漏洞結構與常見 false lead
- Strategy Memory：記高層 exploitation strategy 與成功 / 失敗套路
- Technical Action Memory：記具體 command、script、tool invocation 與修正技巧
這個分層很合理，因為安全工作本來就同時存在三種學習：
- 你會認出某類漏洞長什麼樣
- 你會知道某種 attack surface 該先從哪裡下手
- 你還會記得某條 command 到底怎麼下才不會踩坑
把這三種東西全塞進同一種 memory object，其實很難真的幫助 agent。作者等於是在說：經驗不是只有「記住成功案例」這麼簡單，而是要記住概念、策略與技術動作這三層。
這也讓這篇 paper 跟近期一些只談 prompt hardening 或單輪 guardrail 的工作形成很鮮明對比。因為它關心的不是如何讓 agent 每一輪都乖，而是如何讓 agent 在跨任務、跨目標、跨長鏈執行中變得更老練。
實驗結果：真正拉開差距的，是 execution feedback 與 memory
作者在 CyBench、BountyBench、CyberGym 三個 benchmark 上做評估，拿 Co-RedTeam 去和 Vanilla、OpenHands、C-Agent、VulTrail、RepoAudit 等方法比較。
主結果裡最醒目的數字，是用 Gemini-3-Pro 當 backbone 時：
- CyBench：63.7% exploitation success rate
- BountyBench：65.0% exploit success、20.0% detection
- CyberGym：37.3% success rate
如果用 Gemini-2.5-Pro，也有：
- CyBench：59.1%
- BountyBench exploit：60.0%
- BountyBench detect：12.5%
- CyberGym：31.5%
這裡不能只看絕對數字，更值得看的其實是 ablation。因為它把這篇 paper 的真正結論講得很清楚：
- 拿掉 execution，CyBench 從 59.1% 掉到 17.5%
- 拿掉 memory，BountyBench exploit 從 60.0% 掉到 40.0%
- 拿掉 code browser，BountyBench exploit 從 60.0% 掉到 42.5%
- 拿掉 validation，BountyBench exploit 從 60.0% 掉到 42.5%
這組結果其實把一件事講得非常直白：agent 的勝負點不在於它是不是 multi-agent，而在於它是不是 execution-grounded、code-grounded，而且會累積經驗。
尤其是 No Execution 那個掉幅很殘酷。它幾乎等於在告訴你：沒有真實執行回饋的安全 agent，再會講也只是高級靜態猜測器。
這篇真正重要的，不是 benchmark 分數，而是它對「offensive agent」重新下了比較像樣的定義
我覺得 Co-RedTeam 最值得記住的，不是它某個 benchmark 第一名，而是它把 offensive LLM agent 從「會生成 exploit 的模型」重新拉回「會做 security work 的系統」。
這個差異很大。
前者比較像炫技：給你一段程式碼，吐出一個 payload，看起來很厲害。後者比較像真實 red teaming：看 codebase、找可疑點、交叉比對安全知識、提出可驗證假設、真的打、失敗後修正、最後留下可重用經驗。
也因為這樣，這篇和近期的 CyberExplorer、CVE-Bench、Red-MIRROR 其實可以互相拼成一條更完整的 offensive security 脈絡：
- CVE-Bench 比較像在量 agent 碰真實 web CVE 的上限有多遠
- CyberExplorer 在問 open-environment offensive benchmark 該怎麼做得更像現實
- Red-MIRROR 強調 reflection、shared memory 與 exploitation refinement
- Co-RedTeam 則把 discovery + exploitation + memory reuse 串成更完整的 red-team production loop
也就是說，這篇 paper 的位置不只是「又一個 offensive benchmark paper」，而是更接近：我們終於開始比較認真地把 autonomous red teaming 當成 workflow engineering 問題，而不是 prompt demo 問題。
它的限制也很明顯：強是強了，但離真實世界還有幾道牆
當然，這篇不是沒有侷限。
第一，雖然它已經比很多工作更重 execution，但 benchmark 仍然是 benchmark。真實企業環境裡的 red teaming，還有更多它沒完全碰到的東西：
- 跨系統橫向移動
- 權限與憑證管理
- 非程式碼層 attack surface
- 更混亂的環境依賴與 operational noise
第二，它的 detection precision 雖然相對 baseline 好很多，但絕對值其實還不算高。這很正常，也很誠實：找漏洞本來就比重放已知利用路線更難。
第三，這種系統一旦真的更強，風險討論就不能再只停在「模型會不會 hallucinate」。因為當它已經具備 code browsing、execution、memory accumulation 與 iterative planning，整個系統的安全治理問題就會直接升級成：
- 誰能啟動它？
- 它能碰哪些 target？
- memory 裡累積的 exploit knowledge 怎麼控？
- validation 與 sandbox 到底夠不夠硬？
這也是這篇 paper 讓人不太舒服、但又很值得看的地方：它不是在講一個遙遠的風險，而是在展示 offensive agent 真的開始有系統化長出來了。
怎麼把它放回近期 sectools.tw 的主線裡？
如果把這篇放回最近 sectools.tw 追的脈絡，我會把它看成是對前面那串 agentic security 文章的一次反向補完。
前面很多 paper 在問的是：
- agent 容易被怎麼攻擊
- system prompt 怎麼變 attack surface
- skills / tools / routers / memory 怎麼變供應鏈風險
- multi-agent delegation 與 runtime boundary 該怎麼治理
而 Co-RedTeam 反過來讓你看到：如果把這些保護都先放一邊，真正有野心的 offensive agent 其實會朝什麼方向長。 它不會只是更會說，而是更會：
- 分工
- 查 code
- 連接安全知識
- 做 execution-grounded revision
- 把成功與失敗都變成下一輪資產
從這個角度看，這篇 paper 的警訊非常直接：未來要防的，不只是單一模型輸出錯誤，而是會持續規劃、執行、修正、記憶的 offensive workflow。
總結
Co-RedTeam 值得讀，不是因為它又證明了一次「LLM 能做資安」，而是因為它把這件事往更成熟、也更麻煩的一步推了出去。
它真正重要的訊息是：自動化 red teaming 的能力，正在從「模型會不會生成 exploit」轉向「系統能不能像研究員一樣有紀律地找、批判、執行、修正、再學會」。
這也意味著，未來 offensive agent 的競爭力，很可能不再主要來自單次生成品質，而是來自整體 workflow 設計——誰的系統更會用 security knowledge、誰更會看 code、誰更能從 execution feedback 中收斂、誰更能把經驗變成複利。
如果你問我這篇 paper 最值得記的一句話是什麼，我會選這句：真正危險的 autonomous security agent，不是會打一個漂亮 payload 的 agent，而是會在失敗後越打越準的 agent。
本文由 AI 產生、整理與撰寫。