Refute-or-Promote 論文閱讀分析：很多漏洞 AI 真正缺的，不是再多找幾個疑似洞，而是更狠地先把大多數假洞殺掉

本文由 AI 產生、整理與撰寫。

論文基本資訊

• 論文標題：Refute-or-Promote: Adversarial Stage-Gated Multi-Agent Review for High-Precision LLM-Assisted Defect Discovery
• 作者：Abhinav Agarwal
• 年份：2026
• 來源：arXiv:2604.19049
• 論文連結：https://arxiv.org/abs/2604.19049
• 主題：AI Security、LLM-Assisted Vulnerability Discovery、AppSec、Multi-Agent Review、False Positive Reduction、Coordinated Disclosure

這篇 Refute-or-Promote 真正值得看的，不是它又做了一條 multi-agent bug hunting pipeline，而是它把現在 LLM 做漏洞研究最尷尬、也最現實的一個問題正面攤開來講：很多團隊真正被 AI 卡住的，不是找不到疑似漏洞，而是假洞多到足以把整個 disclosure 流程拖垮。

這不是小問題。作者開頭就直接點名現況：LLM 生成的漏洞報告常常「看起來很像真的」，但實際上是 plausibility 極高、正確性不足的錯誤候選。當這種東西大量湧進 maintainer 或 bug bounty triage 流程時，AI 不只是沒幫忙，反而會變成一種 precision-side denial of service。curl bug bounty 因為 AI 生成提交把 confirmed rate 壓到 5% 以下而永久關閉，HackerOne 也在 2026 年 3 月暫停 Internet Bug Bounty，這篇 paper 就是在這個背景下提出它的核心主張：

漏洞 AI 下一步真正缺的，不是更會報，而是更會殺掉自己報錯的東西。

這篇論文想解的，不是 coverage，而是 precision 危機

Refute-or-Promote 的 framing 很清楚。作者並不是要證明「LLM 已經可以 autonomously 找到很多 0-day」，反而是反過來說：就算模型真的開始能找出一些真問題，如果你沒有一條夠狠、夠偏執、夠不信任自己的過濾流程，整個系統依然不適合拿去碰真實維護者與 disclosure pipeline。

所以這篇 paper 的重點不是 benchmark accuracy，也不是單次 demo，而是：

• 如何讓 candidate generation 和 candidate destruction 分開
• 如何避免 reviewer 被前一輪說法錨定
• 如何用不同模型家族去打掉共享偏見
• 如何把「看起來合理」逼到「必須過 empirical gate」

這個角度我很喜歡，因為它很像把漏洞研究這件事從「AI 幫你 brainstorm」拉回「AI 產線怎樣才不會害你把垃圾也當成資產」。

Refute-or-Promote 在做什麼？本質上是一條 stage-gated 的假洞屠宰線

作者提出的不是單一 agent，而是一個帶有明確 kill mandate 的 stage-gated multi-agent review methodology。關鍵不是叫多個 agent 一起討論，而是讓某些 agent 的職責從頭到尾都不是幫忙完善候選，而是想辦法證明它是錯的。

這條流程包含幾個核心設計：

• Stratified Context Hunting (SCH)：候選生成不是一股腦亂掃，而是把不同 context slice、不同 subsystem、不同 wave 分開狩獵。
• Adversarial kill mandates：每個 promotion gate 都有 reviewer 負責把候選往死裡打，而不是往「比較像樣的故事」修。
• Context asymmetry：冷啟動 reviewer 不共享完整前情，降低 anchoring cascade。
• Cross-Model Critic (CMC)：用不同 model family 去拆穿同一家模型共享的幻覺與偏見。
• Mandatory empirical validation：最後不是辯論贏就算，而是要過實測、規格差異驗證、或外部接受訊號。

如果用一句話講，這套方法的精神就是：讓 AI 先學會否定自己，再談把候選送進人類的 disclosure queue。

最聰明的地方：candidate generation 和 review 不是對稱合作，而是非對稱互打

很多 multi-agent paper 的直覺都是「多幾個 agent 一起討論，答案就會比較好」。但這篇其實在批評那種想像。因為在漏洞研究裡，多個 agent 很可能只是在共享同一種 plausibility bias，最後一起把不存在的洞講得更像真的。

作者刻意把角色設計成不對稱：

• 一邊負責找 candidate
• 另一邊負責找為什麼它不成立
• 而且 reviewer 盡量不要吃到太多前文，以免被原始敘事框住

這跟一般 cooperative debate 很不一樣。它要的不是收斂共識，而是逼出能否 survive hostile review 的候選。對 AppSec 來說，這其實比「大家都覺得合理」重要得多，因為真實世界的 disclosure 不是看故事順不順，而是看 maintainer、標準委員會、CVE 流程、實測結果會不會買單。

關鍵數字很扎實，而且不是 benchmark 分數，是外部世界真的接住了多少

這篇 paper 最有力的地方，是它把評估點放在外部 acceptance signal，而不是自己設 benchmark 自己打分。作者在 31 天 內，跨 7 個 targets（包含 security libraries、ISO C++ standard、major compilers）跑完整個 campaign，總共處理大約 171 個候選。

結果很有意思：

• 約 79% 的候選在進入 disclosure 前就被 pipeline 殺掉
• 在較統一協定的 subset（lcms2、wolfSSL，n = 30）中，prospective kill rate 為 83%
• 最終成果不是「某 benchmark 過幾題」，而是外部世界真的接受的結果，包括：
• 4 個 CVE（3 public、1 embargoed）
• LWG 4549 被納入 ISO C++ working paper
• 5 個 merged C++ editorial PRs
• 3 個 compiler conformance bugs
• 8 個 merged security-related fixes without CVE
• 1 個 RFC 9000 errata under review
• 1+ FIPS 140-3 normative compliance issues under coordinated disclosure

這組數字真正有意思的不是「AI 幫忙找出很多成果」，而是它把大量本來會污染 triage queue 的錯誤候選，在更早期就消掉了。這比較像 production-minded 的成果，不是 demo-minded 的成果。

整篇最值得記住的故事：80+ agents 一起看錯，最後是一個實測把大家打醒

這篇最精彩、也最誠實的段落，是作者沒有把 failure 藏起來。文中最經典的案例，是一個關於 OpenSSL CMS module 的 Bleichenbacher padding oracle 假洞。

可怕的地方不是單一 agent 看錯，而是：

• 80+ agents 一路參與
• 10 位 dedicated reviewers 一致背書
• 整個團隊差點把它當成真的漏洞往前推
• 最後居然是一個 empirical test 把它直接擊殺

這件事非常有代表性。它說明了兩件殘酷的事：

1. 多代理一致同意，不等於真。
2. 語言上的說服力，真的會壓過工程上的驗證慣性。

所以作者最後把 empirical gate 提升成 mandatory requirement，這個決定我覺得非常對。因為在漏洞研究裡，真正會害人的不是模型完全瞎扯，而是它把錯誤包裝成一個足以讓很多聰明人暫時點頭的 plausible exploit story。

這篇對 AI 漏洞研究最大的提醒：不要把 reviewer 變成同一個 hallucination 的回音室

Refute-or-Promote 背後的安全工程觀，其實比論文本身還重要。作者等於在提醒大家：如果 generator 和 evaluator 共用太多上下文、共用同模型家族、共用同一種敘事脈絡，那你看到的可能不是 verification，而是 hallucination reinforcement。

這也是為什麼 paper 特別強調：

• cross-family review 比單純多抽幾次同模型更重要
• fresh-context review 比同 session 裡繼續 debate 更重要
• stage-gated kill pressure 比 consensus aggregation 更適合 high-precision defect discovery

對實務團隊來說，這等於是在說：不要把 LLM 審核流程設計成一場越聊越相信的會議。 真正像樣的漏洞 AI pipeline，應該更像法醫流程或 hostile code review：你要故意讓不同視角互相拆，而不是彼此補完。

這篇 paper 也很誠實：沒有任何漏洞是 autonomous 發現的

這篇另一個值得肯定的地方，是作者沒有用誇張口吻賣「全自動漏洞獵人」。paper 明說：No vulnerability was discovered autonomously.

也就是說，真正的貢獻不是 AI 已經會自己端到端找出漏洞，而是作者把一套外部結構做出來，去過濾 LLM agent 持續冒出的 false positives。這點非常重要，因為它把產業討論從「agent 到底多像天才研究員」拉回「怎樣讓 agent 產出比較不會傷害真實 triage 生態」。

我反而覺得這樣更成熟。因為現在這個階段，安全團隊真正需要的不是另一個會衝 headline 的 autonomous hacker 故事，而是一套能讓 AI 參與真實 AppSec 流程、又不把維護者炸爛的操作結構。

對 AppSec / 漏洞研究團隊的直接啟示

如果把這篇 paper 轉成比較實務的教訓，我會整理成五點：

1. 把 precision 當成一級公民，不要只追 coverage。
   如果假洞成本高到足以傷害 triage 能力，coverage 再高也可能是負資產。
2. 讓 reviewer 帶著 kill mandate，而不是 polishing mandate。
   很多 review agent 最大的問題，是太想把候選修成更合理，而不是證明它不成立。
3. 避免同模型回音室。
   cross-family critique 與 context isolation，不是花俏設計，而是拿來對抗 shared bias 的結構性控制。
4. 強制 empirical gate。
   只要牽涉 exploitability、oracle、memory corruption 或 cryptographic side effect，沒有實測就不該升級成 disclosure-ready finding。
5. 用 external acceptance 當 success metric。
   maintainer merge、CVE assignment、standards-body acceptance，比 paper 裡自己設的 judge 分數更能代表 pipeline 真值。

我的看法

我認為這篇 paper 非常值得放進 2026 年 AI × AppSec 必讀清單，尤其是如果你已經對「AI 可以幫忙找洞」這種說法有點疲乏。因為它不再停留在 capability demo，而是開始碰漏洞研究系統怎樣才不會因為 AI 而整體退化這件更關鍵的事。

很多人以為 AI 漏洞研究下一步是把更多候選吐出來，但這篇其實在講另一件更成熟、也更殘酷的事：

真正讓漏洞 AI 開始有產線味的，通常不是它更會報新洞，而是它終於比較會在送出之前，先把大多數假洞自己殺掉。

對今天的 AppSec 團隊來說，這比任何一個單點 CVE demo 都更有參考價值。