VCAO 論文閱讀分析：當漏洞探索真正進入 Agent 時代，決定產出的往往先不是工具，而是資源怎麼被分配

論文基本資訊

• 論文標題：Verifier-Centered Agentic Orchestration for Strategic OS Vulnerability Discovery
• 作者：Suyash Mishra
• 年份：2026
• 來源：arXiv:2604.08291v1
• 論文連結：https://arxiv.org/abs/2604.08291
• DOI：10.48550/arXiv.2604.08291
• 主題：Agentic Security、OS Vulnerability Discovery、Kernel Security、Game Theory、LLM Orchestration、Fuzzing、Static Analysis

如果前一串 sectools.tw 的文章，大多在談 agent 的 trust boundary、tool supply chain、runtime guardrail、SOC 協作，那這篇 VCAO 值得接著讀的原因很直接：它把問題往另一個更貼近「真實進攻能力形成處」的方向推進——當 LLM 已經不是單純回答漏洞問題，而是開始主導整套漏洞探索流程時，真正決定產出的，不再只是工具強不強，而是 orchestration 到底聰不聰明。

作者的核心主張很鮮明：今天做 OS / kernel 漏洞探索，大家手上其實早就有很多強工具，像是 CodeQL、Syzkaller、KASAN、KCSAN。真正的瓶頸不一定是「少一把新槌子」，而是在有限預算下，該先敲哪裡、用哪種方法敲、敲多久、敲完之後哪些訊號值得再驗。這篇論文試圖把這件事從 heuristics 拉成一個比較正式的 decision-theoretic problem。

這篇論文想解決什麼？

作者要處理的不是單點漏洞檢測，而是整體資源分配問題。以 kernel security 來說，分析面非常大：

• 檔案多、函式多、entry points 多
• 不同漏洞型態適合的分析方法不同
• 某些區域 fuzzing 效率高，某些區域靜態分析更有價值
• 同一份工具輸出裡，真正值得送到人類 reviewer 的候選通常很少

所以作者把問題定義成一個更高層次的問題：

若你只能投入有限分析預算，如何讓一個 LRM-orchestrated system 有策略地挑選目標、分配工具、吸收 verifier evidence，並持續更新下一輪搜索方向？

這也是這篇和很多「LLM 會不會找漏洞」論文最大的差別。它不是在展示模型單點能力，而是在問：一個多工具、多輪次、會持續重新分配預算的漏洞探索系統，該怎麼被設計。

方法核心：把漏洞探索寫成 Bayesian Stackelberg 搜索遊戲

這篇最有特色的地方，是把 OS vulnerability discovery 形式化成一個 repeated Bayesian Stackelberg search game。

白話講，作者把 defender 端看成 orchestrator：它要決定分析預算怎麼分配到不同 kernel files、functions、attack paths 與 analysis methods；而 attacker 端則被建模成一個會挑最有利攻擊路徑的策略對手。系統每一輪會：

• 選目標 component
• 選分析方法
• 分配時間 / 預算
• 觀察工具輸出
• 更新 belief
• 再重新求解下一輪策略

這個 framing 的意義，不是要把漏洞研究硬包裝成 game theory，而是它真的在回答一個安全工程上的老問題：不是所有地方都值得同樣努力，也不是所有工具都該平均灑。

過去很多 pipeline 的問題就在這裡——流程看起來很多 agent、很多工具、很多 parallelism，但資源分配仍然是 heuristic-driven。VCAO 的企圖，是把這個「該優先查哪裡」的問題，拉成一個有明確 utility 與資源限制的最佳化問題。

VCAO 的六層架構

作者把整套系統拆成六層，這個拆法其實相當值得看，因為它不是在喊「multi-agent」口號，而是明確把 control plane 和 execution plane 分開。

1. Surface Mapper

第一層先找安全相關入口點，例如 syscall handlers、ioctl dispatch、filesystem parser、credential path、namespace / capability boundary。這一步的目標不是直接抓 bug，而是先建立「攻擊者可能從哪裡進來」的入口地圖。

2. Attack Graph Builder

第二層把這些 entry points 與內部函式、權限邊界、最終 attacker goals 串成 intra-kernel attack graph。也就是說，這篇不是看一般 network attack graph，而是把 graph 視角壓到 kernel 內部 execution / privilege transition 路徑。

3. Game-Theoretic Ranker

這是整篇的核心。它會根據目前 belief 與 attack graph，計算最值得投入分析預算的 files / functions / methods 組合。重點不是單純 ranking，而是在有限 budget 下做異質工具間的最適配置。

4. Parallel Executor Agents

這層才是很多人熟悉的 agentic execution：

• Patch-Diff Miner
• CodeQL Agent
• Fuzzing Agent
• KASAN Agent
• KCSAN Agent

這個設計很關鍵，因為作者沒有把 LLM 包裝成萬能漏洞工具，而是讓模型扮演「會調度 verifier 與 execution tools 的 orchestrator」。這比單純讓模型自己硬猜 bug 實際得多。

5. Cascaded Verifier

找到 candidate 之後，不是立刻當成果，而是進入三段式驗證：

• reproducibility confirmation
• severity / CVSS assessment
• deduplication against known CVEs / prior findings

這點我很認同。近年很多自動化漏洞研究最容易失真之處，不是「找不到東西」，而是送給人看的垃圾太多。如果 false positive 沒有被控制住，agent 再聰明也只是在幫人類 reviewer 製造排隊地獄。

6. Safety Governor

最後一層是 safety governor，要求隔離容器、audit logging、mandatory human review、offline-only experimentation。這層很像近年 agentic security paper 常見的「安全聲明」，但在這篇裡它不是附錄式裝飾，而是因為整個系統本來就屬於高 dual-use 研究，必須把治理放進 architecture 裡。

這篇論文最值得記住的主線：漏洞探索的瓶頸正在從工具能力轉向 orchestration intelligence

我認為這篇最值得留下的一句話，不是任何一個數字，而是這個方向判斷：

當靜態分析、fuzzing、sanitizer 與 reasoning model 都逐漸可用時，下一個真正拉開差距的，不是某個單工具更強，而是誰比較會分配搜尋資源。

這跟最近幾篇 offensive / autonomous security 論文其實是接得上的。像 Red-MIRROR、Co-RedTeam、ARTEMIS 那條線，已經在說明 agent 的勝負點不是單次 payload，而是整條 workflow 的記憶、驗證、反思與收斂。VCAO 則把這件事進一步 formalize：不是只說 orchestration 很重要，而是直接把 orchestration 變成可求解、可比較、可做 regret analysis 的資源配置問題。

實驗怎麼做？

作者用兩種模式評估：

• Replay mode：回放 2019–2025 年的 847 個 historical Linux kernel CVEs
• Live mode：在 upstream snapshots 上跑即時發現，再做人工驗證

目標子系統包括：

• Filesystem
• Networking
• Namespace / Capability code
• Selected drivers
• io_uring 與 BPF / eBPF

基線則涵蓋：

• uniform allocation
• git churn ranking
• coverage-only fuzzing
• static-analysis-only baseline
• non-game-theoretic multi-agent pipeline

這個 baseline 設定算合理，因為它不是只拿一個很弱的對手來襯托自己，而是直接和「常見單工具路線」以及「有 agent 但沒有 game-theoretic allocation 的 pipeline」比較。

主要結果：不是多一點，而是每單位預算更會找到對的東西

論文給出的主結果相當醒目：

• 相較 coverage-only fuzzing，每單位預算的 validated vulnerabilities 提升 2.7 倍
• 相較 static-analysis-only baseline，提升 1.9 倍
• 相較 non-game-theoretic multi-agent pipeline，提升 1.4 倍
• 送到 human reviewer 的 false-positive rate 降低 68%

這幾個數字要一起看。真正有意思的不是單純「找到更多」，而是：

• 有限 budget 下找到更多 validated findings
• 同時讓人類 reviewer 面前的垃圾訊號變少

這點很重要。很多安全自動化系統的表面成績看起來不差，但真正接到人手上時就垮了，因為 triage cost 太高。VCAO 想證明的是，好的 orchestration 不只是提高 recall，還應該降低 human attention 的浪費。

Ablation 給了什麼訊息？

作者做的 ablation 也有意思。最有影響的三個元件是：

• Bayesian belief update
• Stackelberg optimization
• attack-graph structure

這代表整篇 paper 的價值，確實不在單一 executor agent，而是在 control plane。換句話說，真正讓系統變強的不是「多加一個 CodeQL agent」，而是讓整體流程知道哪些證據應該怎麼改變下一輪資源配置。

我認為這點比表面數字更重要，因為它指出未來漏洞探索 agent 的發展方向：不是無限堆工具，而是把 verification feedback 變成可回灌的 decision signal。

我怎麼看這篇論文？

我對這篇的整體評價是：有野心，而且方向大致對，但要對結果保持成熟保留。

我喜歡它的地方主要有三個：

• 它沒有把 LLM 神化成萬能 finder，而是把它放在 orchestrator 位置。
• 它承認 verifier 才是高風險工作流裡真正的信任來源之一，所以題目才叫 verifier-centered。
• 它把「從工具能力到 orchestration intelligence」這個轉折講得很清楚。

但我也有幾個明顯保留。

1. 這篇很強，但也很像一篇「理想型 architecture paper」

它的數學定義、MILP、regret bound、六層架構都很完整，但也因此有一種典型風險：理論形式很漂亮，落地校準成本卻可能非常高。例如：

• belief update 需要方法別 observation model 校準
• attack graph 需要品質不差的 privilege-boundary 建模
• 不同 kernel version 的工具行為會漂移

也就是說，這篇比較像是在定義「下一代漏洞探索 orchestrator 應該長怎樣」，而不是已經證明這條路能輕鬆產品化。

2. Rational attacker 假設很有用，但也很乾淨

作者自己有承認，整個 Stackelberg framing 預設 attacker 是策略性的。這在理論上很好用，但真實世界裡很多 exploit path 的形成，不見得符合這麼乾淨的效用模型。它比較適合當 allocation prior，而不是當真實對手的完整代理。

3. 歷史 CVE replay 仍然有「已知世界」偏差

847 個 historical CVEs 很有份量，但 replay mode 永遠還是 replay mode。真正困難的，是在 upstream snapshots 裡面面對未知 root cause、未知 exploitability、未知 noise 時，這套 orchestration 還能不能穩定維持優勢。

對實務界的啟示

如果你在做的是：

• agentic AppSec
• LLM-assisted vulnerability research
• autonomous fuzzing / static analysis pipeline
• 安全研究工作流編排

那這篇有幾個很實際的提醒：

• 別再把 agent 只想成「會不會找 bug」，更該問的是它怎麼分配時間、工具與 reviewer attention。
• verification 不該是最後補丁，而該是架構中心。沒有 verifier-centered design，agent 只會更快製造噪音。
• attack graph / reachability / historical defect prior 這類結構化訊號，仍然很重要；不是換成 LLM 就可以全部丟掉。
• multi-agent 不代表成熟。沒有好的 control plane，多 agent 只是多工地，而不是更好的 research team。
• 真正可擴張的方向是把 evidence 回灌成 allocation policy，而不是每輪都從頭盲找。

總結

VCAO 不是一篇單純在秀「LLM 多會找漏洞」的論文。它更像是一篇試圖替下一代 autonomous vulnerability discovery systems 定義控制平面的文章。它最重要的訊息不是某個 agent 又多聰明，而是：

在漏洞探索進入 agentic era 之後，真正稀缺的能力不再只是分析工具本身，而是知道該把哪種分析資源，放到哪個最值得懷疑的位置上。

如果把它放進最近 sectools.tw 的脈絡，這篇剛好把近幾篇 runtime guardrail、agent protocol、multi-agent governance、offensive workflow 的討論，再往前推到更底層的「探索策略」：不是 agent 會不會做事，而是 agent 是否知道下一步該查哪裡，並且能把 verifier evidence 轉成下一輪更準的行動。

我會把這篇看成一個很有代表性的信號：資安 agent 的競爭，正在從單次任務能力，逐漸轉向長程資源配置與驗證閉環能力。 而這通常也是一個領域開始變得真正危險、也真正有用的前兆。

免責聲明

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