一個偵測標準,可信度就等於它背後那些數字——而自己發布的數字,是最容易灌水的一種。 所以我們反過來做:拿 Agent Threat Rules(ATR)去跑兩個我們沒有參與製作的獨立開放 benchmark,用它們自己的 harness,把結果原樣公開——包括 ATR 表現差的地方。
用兩個 benchmark,是因為它們量的是兩件不同的事。
OpenGuardrails:runtime 偵測
OpenGuardrails 的 benchmark 用一批共用的 agent runtime 事件語料——prompt injection、 惡意命令、資料外洩、憑證洩漏——替偵測器打分,以 macro-F1 排名並帶 p95 延遲預算。這是 ATR 的主場:它是一套偵測 agent 即時輸入、輸出、工具呼叫與 MCP 交換中攻擊的規則標準。
把現行 ATR 規則集丟進 OpenGuardrails 的 harness,ATR 在 seed suite 的七個參考偵測器裡排第一——贏過 config 加 LLM 的組合偵測器——而且對 benign 語料零誤報。它在惡意命令與資料外洩最強; 最弱的一條是改寫過的自然語言注入,那正是純 pattern 層的已知極限,也正是語意層能補的地方。
OASB:靜態 skill 與套件掃描
Open Agent Security Benchmark(OASB)量的是另一件事:對一批標記過的 skill 與套件 工件——agent 會安裝的靜態原始碼——做偵測,裡面有三千八百多個良性樣本、數百個惡意樣本。
這裡的結果是兩面的,值得直說。對全部 3,881 個良性 skill,ATR 觸發了零誤報——是那張榜上所有掃描器裡誤報率最低的, 比專門做靜態掃描的工具還低。但它的 recall 很低:惡意 skill 工件大約每五個抓到一個。
這個落差不是 bug,我們也不會替它擦脂抹粉。ATR 偵測的是 runtime 的 agent 行為,它不是 原始碼掃描器或套件掃描器,而 OASB 裡多數惡意工件是靜態的供應鏈 pattern——寫死在 manifest 裡的持久化、埋在程式碼中稍後才執行的外洩邏輯——這些是一個 runtime 偵測器在 執行前本來就看不到的。在這個語料上,AST 型的靜態掃描器 recall 贏 ATR 是應該的,因為那 就是它們生來要做的。
我們的結論
ATR 是一個精準的 runtime 偵測層,不是靜態套件掃描器,而這兩個 benchmark 從相反方向 都這麼說。它被設計來運作的地方——即時 agent 流量——它領先;它不擅長的地方——靜態供應鏈 原始碼——它誠實、安靜、覆蓋低。貫穿兩者的那條線是精準度:跨兩個 benchmark、數千個 良性輸入,它一次都沒亂叫。
對任何在做 agent 安全的人,實務上的讀法是:runtime 發生的事,用一個 runtime 偵測標準; 供應鏈裡出貨的東西,配一個原始碼與套件掃描器;不要相信任何宣稱一個層就把兩件事都做掉 的東西。縱深防禦在這裡不是口號,是 benchmark 量得出來的。
我們公開的是我們跑到的數字,不是我們希望看到的數字。只有這種數字,值得站在後面。