Who Tests the Testers? 論文閱讀分析：當 Agent Safety Benchmark 看起來都過關，真正沒被測到的風險才剛開始
本文由 AI 產生、整理與撰寫。
論文基本資訊
- 論文標題：Who Tests the Testers? Systematic Enumeration and Coverage Audit of LLM Agent Tool Call Safety
- 作者：Xuan Chen、Lu Yan、Ruqi Zhang、Xiangyu Zhang
- 年份：2026
- 來源：arXiv:2603.18245
- 論文連結：https://arxiv.org/abs/2603.18245
- 主題：LLM Agent Safety、Benchmark Coverage、Tool-Calling、Meta-Audit、SafeAudit、Rule-Resistance
如果說前幾波 agent safety 論文多半在問「模型會不會中招」「guardrail 擋不擋得住」「benchmark 分數有沒有上去」，那這篇 Who Tests the Testers? 真正往前補上的，是一個更不舒服、但也更關鍵的問題：如果今天一個 agent 已經通過了安全 benchmark，我們到底憑什麼相信它真的夠安全？
這篇 paper 的核心觀察很狠：很多既有 benchmark 很會測「有沒有碰到我們想得到的危險情境」，但不一定真的知道自己漏掉了多少沒想到的危險情境。 換句話說，問題可能不是 agent 通不通過測試，而是測試集本身到底有多完整。對會呼叫 email、calendar、banking、search、web action 這類外部工具的 LLM agent 來說，這件事尤其致命，因為真實世界的傷害往往不是模型多講了一句毒話，而是它真的下了一個錯的 tool call。
作者提出的 SafeAudit，本質上不是又做一個新 benchmark，而是做一個「benchmark 的 benchmark」：它要檢查既有安全測試集到底有多少盲區，並把那些沒被測到、但仍可能造成真實傷害的 interaction pattern 系統性挖出來。
這篇論文在打哪個痛點？
近年的 agent safety 評測已經很熱鬧：有些測 prompt injection、有些測 harmful tool use、有些測長鏈攻擊、有些測 multi-turn environment。表面上看起來，環境越做越真、工具越接越多、風險類型越列越完整，好像 coverage 已經夠廣了。
但這篇論文指出一個很容易被忽略的現實：「環境很多」不等於「危險模式測得完整」。 同一組工具、同一個環境，只要使用者指令的模糊程度、委任方式、上下文限制稍微改一下，agent 就可能從原本會先確認，變成直接執行危險操作。
例如：
- 查詢步驟回來多個相似結果，agent 是否會默默替你挑一個？
- 前一步取得的是過時資訊，後一步是否會直接拿去執行高風險操作？
- 需要 verification 的地方，agent 會不會因為語境中的急迫感而跳過確認？
- 使用者說「你自己決定就好」時，agent 會不會把這句話理解成可直接放棄所有安全檢查？
這些都不是傳統 content safety 可以輕鬆攔下來的問題，因為傷害不是出在回答文字，而是出在工具呼叫的結構與參數決策。作者的意思很清楚：如果 benchmark 沒有系統性枚舉這類 workflow-level failure，你看到的 pass rate 很可能只是對既有題庫熟，不是真的對現實安全。
SafeAudit 在做什麼：不是再多出幾道題，而是先把危險 workflow 的空間整理出來
我覺得這篇 paper 最聰明的地方，是它沒有直接暴力生成一堆測試題，而是先承認：agent safety 的搜索空間太大，真正該先枚舉的不是文字題目，而是抽象的 unsafe interaction pattern。
SafeAudit 的做法分成兩步：
- 先列出有效的 tool-call workflow：在特定 environment 與 tool set 下，哪些多步操作鏈是真實使用者可能會觸發的？
- 再把 workflow 實例化成不同 user scenario：同樣一條操作鏈，在不同角色、商業情境、授權語氣、時間壓力下，可能誘發不同型態的 unsafe behavior。
這個拆法很重要。因為它把問題從「直接亂生成測試題」改成「先理解工具鏈哪幾步最容易出事」。作者點出三個很常出問題的位置：
- Lookup step：搜尋結果有歧義，但 agent 自行消解
- Execution step：執行時沿用了前面錯的或過期的參數
- Verification step：本來應該確認，但 agent 直接略過
這讓 SafeAudit 看起來不像在蒐集「更刁鑽的 prompt」，而比較像是在畫一張 tool-use failure map。對實務來說，這個角度比單純多灌一些 adversarial examples 有用，因為它更接近真實產品團隊會遇到的問題：不是每次出事都有人在惡意攻擊你，很多時候只是正常使用者給了模糊委任，系統卻把模糊當授權。
這篇論文真正有料的核心：rule-resistance
如果只有 enumerator，這篇 paper 還只是「另一種自動生題法」。真正讓它站起來的是作者提出的 rule-resistance。
這個概念想解的問題是：你怎麼知道 SafeAudit 找到的是新風險，而不是只是把 benchmark 裡本來就有的題目換個說法重寫一次？
作者的答案不是用 semantic similarity，也不是靠人工主觀分群，而是走一個更工程化的方向：先從既有 benchmark 蒸餾出一組緊湊的安全規則，再把這些規則套到 agent 上，看看哪些新情境下 agent 仍然會做出不安全的 tool-call trajectory。
也就是說，rule-resistance 在問的不是「這題看起來像不像舊題」，而是：
- 如果 agent 已經學會 benchmark 所代表的那些安全規則
- 那它面對新測例時，還會不會出現新的 unsafe behavior？
若答案是會，那這些情境就比較有資格被視為 benchmark 尚未覆蓋到的殘餘風險。這個想法很漂亮，因為它把 coverage 問題從模糊的「像不像」轉成更可驗證的「在 benchmark 規則保護下還會不會出事」。
這也呼應了 agent security 一個越來越明顯的現實：很多安全失敗不是因為系統完全沒有規則，而是因為規則只覆蓋了最典型的危險形式，沒覆蓋到那些同樣危險、但結構稍微不同的 interaction pattern。
結果代表什麼？
根據摘要與本文前段說明，SafeAudit 在 3 個 benchmarks、12 個 environments、8 個 backbone LLMs 上做 meta-audit，得到幾個非常值得記的訊號：
- 既有 benchmark 之外，仍可額外挖出超過 20% 的 residual unsafe behaviors
- 在相同工具與環境下，仍能識別出約 11% 的 novel unsafe interaction patterns
- 隨著測試 budget 增加，coverage 是持續上升的，表示這不是偶然撞到幾個邊角案例，而是真的有系統性盲區
這些數字的意義很直接：agent safety benchmark 的高分，可能遠比我們想像中更容易讓人產生虛假的安全感。 如果通過一套 benchmark 之後，還能穩定再挖出 20% 以上的殘餘危險行為，那代表現在很多評測更像是「測你有沒有見過這批題」，而不是「測你在這個工具生態裡到底安不安全」。
這對任何想把 LLM 接到高權限 workflow 的人都該是一記警鐘。因為產品團隊常見的心態是：
- 我們有 sandbox
- 我們有 benchmark
- 我們也做了 alignment
- 分數看起來不錯，所以應該差不多可以上
SafeAudit 的結論基本上是在說：先別急。你可能只是把系統訓練得很會避開你已知的坑，但對那些你沒系統性枚舉過的 workflow，它還是一樣會摔。
我怎麼看這篇論文？
我自己很喜歡這篇，因為它不是在喊一個很抽象的口號，而是很具體地把 agent safety 評測往更成熟的方向推了一步：從「做 benchmark」走到「審 benchmark 的 completeness」。
最近很多 agent security 論文都在談 attack surface、runtime guardrail、tool poisoning、memory persistence、long-horizon attack。這些都很重要，但它們多半在回答「哪裡危險」或「怎麼防」。SafeAudit 補的則是另一塊基礎建設：你拿來驗證安全的那把尺，本身有沒有缺口？
這件事在資安其實非常老派、也非常經典。弱點掃描器本身要被驗證、偵測規則要看 coverage、red team playbook 要避免題庫化。到了 LLM agent 時代，這個老問題只是換了新外觀：今天不只 agent 要被測，連測 agent 的測試集也得被測。
而且作者有個判斷我很認同：很多高風險失誤並不需要惡意使用者。只要環境結構夠複雜、授權語句夠含糊、工具鏈剛好有幾個歧義節點，系統就可能自己滑進危險區。這讓 SafeAudit 的價值不只在 red teaming，也在 product QA 與 pre-deployment audit。
如果要挑可能的限制，我會說這類方法仍然很依賴 enumerator 與 rule distillation 本身的品質；換句話說，它不是終點，而是更好的第二層檢查。但這不構成否定，反而更像一個成熟訊號：agent safety 不會靠單一 benchmark 一勞永逸，未來更合理的作法本來就該是 benchmark、meta-audit、runtime control 三層一起上。
如果要用一句話收這篇，我會這樣說：SafeAudit 真正提醒我們的，不是現在的 agent benchmark 沒價值，而是「只會測已知題型的安全評測，最後最危險的往往正是那些沒被出成題目的地方」。
對正在把 LLM agent 接進真實流程的人來說，這篇很值得看。因為它逼你承認一件事：安全不是通過一次考試，而是你有沒有能力持續發現自己題庫外的失敗模式。