今日總覽
今天三篇論文從不同角度戳破同一個假設:只要有人審核、有模型判斷、或是按下一個「取消」按鈕,Agent 的授權就算收回了。第一篇 Loopjacking 在真實釋出的 agent 產品裡重現了一種審核失效模式——人審核的是操作 A,系統執行的卻是操作 B,而且在 Agno AgentOS、LangGraph Agent Server 與 OpenClaw 三個實際專案裡都能重現。第二篇 APort Vault 用一場真實奪旗賽收集到的攻擊,逼近 22.6 萬次評測,證明擋下 Agent 亂轉帳的關鍵不是換一個更安全的模型,而是工具呼叫前有沒有一層確定性的政策檢查。第三篇 Authorization Revocation 往回退一步,問一個更根本的問題:當一個長時間執行、有委派任務、非同步操作的 Agent「取消」了,你憑什麼說它的授權真的結束了?三篇證據成熟度不齊——Loopjacking 與 APort Vault 都有規模具體、可重現的實測數字,Authorization Revocation 則是形式化證明搭配一組規模不大的自建測試集——但合起來清楚指出同一件事:Agent 的「授權邊界」不是一個開關,而是要在架構的每一層被明確檢查、明確定義「何時真的結束」的工程問題。
讀這篇前該知道的詞
| 詞 | 白話解釋 |
|---|---|
| Human-in-the-loop(人工審核關卡) | 讓人在 Agent 執行關鍵操作前做最後把關的機制,常被當成安全的最後一道防線 |
| 授權邊界(Authorization boundary) | Agent 被允許做某件事的範圍與期限——今天三篇論文分別戳破「審核=安全」「取消=結束」「模型夠聰明=夠安全」三種對這條邊界的誤解 |
| 確定性政策引擎(Deterministic policy engine) | 不靠模型自己判斷、而是用明確規則在工具呼叫前擋下不合規操作的檢查層,APort Vault 證明這層才是真正擋下亂轉帳的關鍵 |
| 委派(Delegation) | Agent 把任務、憑證或操作權轉交給其他流程、佇列或第三方服務執行,一旦轉交出去,原本的「取消」動作不一定追得回來 |
| 奪旗賽(CTF,Capture The Flag) | 資安圈常見的攻防競賽形式,APort Vault 直接用一場公開 CTF 收集到的真人攻擊當測試材料,而不是研究者自己編的題目 |
| 負面控制組(Negative control) | 特意找一個「理論上不該中招」的對照案例,如果它真的沒中招,才能證明測出來的問題是真實存在、不是測試方法本身的瑕疵 |
論文一｜Loopjacking:人審核的操作,系統執行的可能是另一個
Loopjacking: Hijacking Human-in-the-Loop Approval Adithyan Arun Kumar(獨立資安研究者) · arxiv: 2609.21081
TL;DR
定義並在真實釋出的 agent 產品中重現一種審核失效模式——人以為批准的是操作 A,系統實際執行的卻是操作 B:在 7 個版本的 Agno AgentOS 與 12 個版本的 LangGraph Agent Server 組合裡重現「事後竄改」攻擊,在 OpenClaw 2026.2.23 重現「審核畫面表達不一致」攻擊(2026.2.24 已修復),而 OpenAI Agents SDK 完整擋下同樣的攻擊,作為負面控制組。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | arXiv preprint(未經同行審查,cs.CR 主分類、cs.MA 跨列,2026-09-17 提交) |
| 引用速度 | 未查得(Semantic Scholar 本輪全程限流,429) |
| 機構 | 獨立資安研究者(Adithyan Arun Kumar) |
| 社群反應 | 未查得 HF Daily Papers / Papers with Code 收錄;作者釋出公開證據庫(github.com/adithyan-ak/loopjacking) |
| 可信度 | 通過 — 在具名真實版本的產品上重現,並附負面控制組 |
| 證據成熟度 | 初步 — 具體且可重現,但作者明確說明樣本是刻意挑選來測試不同審核路徑,不是對生態系的普查 |
| 可復現性 | 完整產物 — 公開證據庫附精確版本與重現步驟 |
| 為什麼選這篇 | 直接 — 揭穿「有人審核=安全」的假設,是今天授權邊界主題裡最貼近開發者日常的一篇 |
| 方向新意 | 實質增量 — 給「審核被劫持」這個模糊直覺一個可測試的形式定義,並和既有的誤導性對話框、session smuggling 研究做出區隔 |
| 今日重要性 | 高 — 任何正在用 human-in-the-loop 當安全機制的團隊都該讀 |
| 實務連結 | 明確 — 論文直接指出兩種修法:完整重繪待審操作 + 使用時精確比對,或阻止未授權方竄改待審狀態 |
| 編輯信心 | 高 — 主張範圍(這些具名版本存在這個失效模式)完全由重現證據支撐 |
| 閱讀建議 | 必讀 — 用 Agno、LangGraph,或任何 human-in-the-loop 審核機制的團隊 |
| 主要限制 | 樣本是刻意挑選的比較性研究,作者明確聲明不能拿來估計整個生態系的盛行率 |
領域背景
human-in-the-loop 審核常被當成 Agent 執行前的最後一道防線,但過去對「這道防線會不會失效」的討論多半停留在誤導性對話框或 prompt injection 層次,較少系統性檢驗「審核當下看到的操作」與「執行時真正發生的操作」這兩者之間的繫結本身會不會斷裂。
中階導讀
- 問題:想像一個低權限使用者申請把 20 塊錢轉給一個核准過的廠商,管理員審核後按下同意——但如果使用者能在管理員同意「之後」把待審的金額偷偷改成 2000 塊轉給自己控制的帳戶,而系統直接沿用管理員的同意去執行這筆新交易,人確實參與了審核,但這道防線已經失效。
- 方法:Loopjacking 把這種失效拆成兩種:一種是「事後竄改」——人看到的是正確的操作 A,但可變的工作流程狀態在批准後被換成操作 B;另一種是「表達不一致」——操作 B 其實已經編碼在系統裡,只是審核畫面沒有完整呈現。作者把這定義成一個可測試的準則:必須有真實的人類決策、實際執行的操作與人理解的不同、攻擊者能影響那個差異、系統把人的決策用在了不同的操作上,而且攻擊者原本沒有更直接的路徑達成同樣效果——這排除了單純的話術說服、一般的可變狀態、沒有人類決策的偽造確認,以及從未重複使用審核結果的 prompt injection。
- 為什麼重要:這代表「有沒有人在審核」跟「這個審核機制到底安不安全」是兩件事——如果系統沒有在執行當下重新比對操作的完整內容,審核按鈕本身可能只是心理安慰,而不是真正的安全邊界。
深入要點
- 在 7 個測試版本的 Agno AgentOS(到 3.0.9 為止)與 12 個版本的 LangGraph Agent Server(到 0.14.0 為止)重現「事後狀態竄改」攻擊
- 在 OpenClaw 2026.2.23 重現「審核畫面表達不一致」攻擊,同一產品的 2026.2.24 版本已經修復並拒絕這個攻擊
- OpenAI Agents SDK 0.22.0 與 0.22.2 作為負面控制組:序列化的執行續傳精確保留了每次呼叫的繫結,拒絕接受被竄改過的操作 B
- 作者明確排除四種容易混淆的情況:人明知故犯批准了可見的操作 B、一般性的可變狀態、沒有真實人類決策的偽造確認、從未重複使用審核結果的 prompt injection
- 落地門檻:兩個可行的修法是「完整且規範化地重繪待審操作 + 使用時精確比對」,或是「阻止未授權的一方竄改待審核的狀態」——兩者都不需要重新設計整個審核流程
- Limitation(作者自述):研究是比較性質而非普查性質,樣本刻意選來測試機制不同的審核路徑,不能拿來推算整個 agent 生態系有多少比例存在這個問題;證據截止日為 2026-09-10
Reviewer 一句話評
用具名、可重現、有負面控制組的方式把一個原本模糊的直覺變成可測試的安全研究,是這篇最扎實的地方;但樣本刻意挑選、且只涵蓋少數幾個產品,讀者不該把這幾個案例讀成「human-in-the-loop 普遍不安全」的結論。
給你的 take-away
- 如果你的產品有 human-in-the-loop 審核關卡:對照論文的準則自問一句——你的系統在「執行的當下」有沒有重新比對操作的完整內容,還是只在審核畫面顯示過一次就假設它不會變?
- 如果你在用 Agno AgentOS 或 LangGraph 建置審核流程:直接去看論文附的重現步驟與受影響版本,確認自己的部署是否落在受影響範圍內
論文二｜APort Vault:擋下 Agent 亂轉帳的,不是換一個更聰明的模型
APort Vault: Benchmarking AI Agent Payment Authorization with the Open Agent Passport Uchi Uchibeke(APort Technologies Inc.) · arxiv: 2609.22076
TL;DR
用一場真實奪旗賽收集到的 4,371 筆人類攻擊,在 14 個模型、5 個政策等級、22.6 萬次評測裡重播:模型單獨作答時,合規等級(Level 2 到 4)的 76,842 次評測中有 140 次把錢轉給政策不允許的對象;同一批攻擊在工具呼叫前多加一層確定性授權檢查(Open Agent Passport)後,69,297 次評測裡是 0 次——而且這個 0 不是靠拒絕付款換來的,政策層底下仍執行了 25,370 筆正常付款。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | arXiv preprint(未經同行審查,cs.CR 主分類、cs.AI 次分類,2026-09-18 提交) |
| 引用速度 | 未查得(Semantic Scholar 本輪全程限流,429) |
| 機構 | APort Technologies Inc.(加拿大多倫多) |
| 社群反應 | HuggingFace Daily Papers 2026-09-21 批次收錄;同時登上 paperswithcode.co 與獨立論文機器審閱站 pith.science;完整 22.6 萬筆評測資料、評分程式碼與預註冊已釋出於 huggingface.co/datasets/aporthq/vault-benchmark-v1(CC BY 4.0) |
| 可信度 | 通過 — 攻擊來自真人而非研究者自編題目,結果指標讀取實際執行的工具呼叫而非模型或裁判的自我評分,並附統計方法與預註冊 |
| 證據成熟度 | 較完整 — 大規模、跨 14 個模型的一致結果,附五階段拆解與配對統計檢定,但仍侷限於單一模擬銀行、單一工具 schema |
| 可復現性 | 完整產物 — 完整評測資料、政策設定、評分程式碼與分析腳本皆公開釋出 |
| 為什麼選這篇 | 直接 — 用大規模實測直接回答「授權邊界該擺在哪裡」:擺在工具呼叫前的政策層,而不是賭模型不會被騙 |
| 方向新意 | 實質增量 — 把「模型會不會被騙」與「系統會不會真的執行」這兩個過去常被混在一起的問題,用同一批攻擊、同一個模型分開測量 |
| 今日重要性 | 高 — 任何在建置會動用金流或高風險工具的 Agent 團隊都該看這篇的方法論 |
| 實務連結 | 明確 — 直接示範「工具呼叫前的確定性檢查層」這個架構模式,可套用在任何有金流或高風險操作的 Agent 系統 |
| 編輯信心 | 高 — 論文自己劃清「這證明了什麼」與「這沒有證明什麼」的邊界,主張範圍內的數字有完整資料支撐 |
| 閱讀建議 | 必讀 — 正在幫 Agent 系統設計授權或金流控管機制的團隊 |
| 主要限制 | 範圍侷限在付款這一種工具、一個模擬銀行環境,論文自己強調「0 次違規」是政策引擎設定正確前提下的結果,不是「授權層不會被設錯」的保證 |
領域背景
過去多數 agent 安全評測回答的是「哪個模型比較安全」,但這個答案會隨模型換版本而過期,也沒告訴部署者選了目前最安全的模型之後,剩下的風險要靠什麼接住。這篇把研究問題換成「在同一批攻擊、同一個模型之下,工具呼叫前有沒有一層獨立的授權檢查,會不會造成差異」。
中階導讀
- 問題:想像一個可以幫你轉帳的 Agent,你設了規則說「只能轉給允許清單上的人」。攻擊者跟這個 Agent 對話,想辦法騙它把錢轉給清單外的帳戶——過去的研究大多只問「這個模型會不會被說服去試著轉帳」,但沒問「就算模型被說服了,錢真的轉得出去嗎」。
- 方法:作者辦了一場真實的公開奪旗賽,讓真人攻擊者對一個有金流的 Agent 下手,收集到 4,371 筆實際攻擊,再把同一批攻擊、同一個模型、同一套提示,分別跑在「模型單獨執行」與「工具呼叫前多一層確定性政策檢查」兩種架構下,唯一的變因就是有沒有這層檢查。
- 為什麼重要:這代表「選一個更聰明的模型」不是解法,「在工具呼叫這一層擋一次」才是實際上有效的解法——而且這個結論是用同一批真實攻擊直接測出來的,不是理論推演。
深入要點
- 合規等級(Level 2 到 4)下,模型單獨執行有 76,842 次評測、140 次把錢轉給政策不允許的對象;加上授權層後 69,297 次評測、0 次違規,以工作階段為單位換算的單次工作階段上限是 0.38%
- 這個 0 不是靠拒絕付款換來的:授權層底下仍執行了 25,370 筆正常付款,政策只擋下 25,640 次轉帳呼叫中的 187 次(其中 148 次是因為收款人不在允許清單)
- 兩種架構的請求發生率很接近,68,970 組配對比較的差異只有 +0.084 個百分點(95% 信賴區間 -0.020 到 +0.189),但作者也揭露其中 1,220 組配對彼此不一致,並未把這個接近值講成「兩種架構完全等價」
- 附帶的雙裁判審核小組信度並不高(整體 Cohen's kappa 0.772,在 Level 3 掉到 0.167),其中一位裁判漏掉 35.6% 已用確定性方式確認過的違規——這正是論文選擇用「實際執行的工具呼叫」而非裁判評分當主要指標的原因
- 落地門檻:需要一個能在工具呼叫與實際執行之間插入確定性檢查的架構位置(論文稱為 Open Agent Passport),對已經有 API gateway 或工具路由層的系統,加裝這層檢查的工程成本相對明確
- Limitation(作者自述):結果侷限於付款這一種工具、一個模擬銀行,不代表資料外洩、程式碼執行或多 Agent 委派場景下也會有一樣的結果;Level 5 刻意設計成模型完全沒有付款能力卻被提示嘗試轉帳,用來測「檢查層擋不擋得住」而非模型會不會被騙,論文明確說不把 Level 5 併入任何 headline 數字
Reviewer 一句話評
用真人攻擊、大規模配對比較、外加誠實揭露自己裁判小組信度不足的作法,是這類 agent 安全 benchmark 少見的自我審視;但整個結論仍侷限在單一金流場景,還沒有跨到資料外洩或多 Agent 委派這類論文自己都提醒讀者不要外推的領域。
給你的 take-away
- 如果你的 Agent 系統會動用金流或執行高風險操作:別把安全預算全押在「換更貴、更聰明的模型」上,優先確認工具呼叫前有沒有一層獨立於模型判斷的確定性授權檢查
- 如果你在設計自己的 agent 安全評測:參考這篇把「請求」「執行成功」「授權決策」「收款人身分」「越權轉帳」拆成五個獨立事件分開統計的做法,而不是把它們塌縮成一個容易失真的成功率
論文三｜Agent 的「取消」按鈕按下去,授權真的結束了嗎?
Authorization Revocation for Long-Running AI Agents: Root-Scoped Quiescence under Delegation and Asynchronous Execution Genliang Zhu, Chu Wang(Accentrust；Georgia Institute of Technology；University of Illinois Urbana-Champaign) · arxiv: 2609.21284
TL;DR
長時間執行的 Agent 會透過憑證、委派任務、佇列、回呼、預約與供應商端操作活得比啟動它的流程還久,單純取消、結束流程或撤銷憑證都無法保證關掉每一條在撤銷前就已經存在的執行路徑;論文提出一套「根範疇授權靜默」的形式化協定與證書,在自建的 17 條測試軌跡上全數通過、且獨立實作的檢查器同時擋下 44 個刻意製造的語意迴歸案例。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | arXiv preprint(未經同行審查,cs.PL 主分類、cs.AI 與 cs.CR 次分類,2026-09-18 提交) |
| 引用速度 | 未查得(Semantic Scholar 本輪全程限流,429) |
| 機構 | Accentrust(加拿大溫哥華)、Georgia Institute of Technology、University of Illinois Urbana-Champaign |
| 社群反應 | 未查得 HF Daily Papers / Papers with Code 收錄 |
| 可信度 | 有條件通過 — 形式化定義與六項證明性質完整且範圍聲明清楚,但實測驗證只有一組規模不大的自建測試集 |
| 證據成熟度 | 初步 — 證明本身在論文自訂的模型下是完整的,但 17 條測試軌跡是作者自行實作,尚未整合進 MCP、A2A 或 OAuth 這類既有的真實委派協定裡驗證 |
| 可復現性 | 部分產物 — 論文內報告了精確的測試結果與計數,但摘要與引言段落中沒有找到公開程式碼連結 |
| 為什麼選這篇 | 直接 — 補上另外兩篇論文都沒回答的問題:當你說一個 Agent 的授權「結束了」,這句話在委派與非同步執行下到底該怎麼定義 |
| 方向新意 | 實質增量 — 把「取消」「憑證撤銷」「流程結束」這幾種各自獨立、都不完整的訊號,統一成一個可證明、以根授權為範疇的靜默證書 |
| 今日重要性 | 高 — 對正在設計長時間執行、跨供應商委派的 Agent 系統的團隊,提供了目前少見的形式化詞彙 |
| 實務連結 | 明確 — 論文明確把自己和 MCP 任務取消、A2A 取消、OAuth token 撤銷這些既有機制做了區隔,指出它們分別能證明什麼、不能證明什麼 |
| 編輯信心 | 中 — 形式化性質本身的敘述範圍很清楚,但「這解決了實務上的委派撤銷問題」這句話的證據強度,還停留在自建測試集,尚未被更廣的實務驗證 |
| 閱讀建議 | 略讀 — 需要先接受一定的形式化語言才能真正吸收,對正在設計相關系統的工程師特別有參考價值,一般讀者可以只看第一節的反例 |
| 主要限制 | 測試套件規模不大(17 條軌跡)且為自建案例,論文本身也沒有展示與現有 agent 執行環境的實際整合 |
領域背景
MCP 的任務取消與 A2A 的取消都被明確定義成「盡力而為的請求」,不是「保證底層執行都已停止」的證明;OAuth token 撤銷只讓一個具名的憑證在授權伺服器端失效,不處理撤銷前就已經被接受的委派工作或跨供應商的操作。這三者各自提供有用但不完整的觀察,卻沒有一個能回答「這個授權根源下,未來還有沒有可能出現新的受保護動作」這個問題。
中階導讀
- 問題:想像一個共用的遠端工作程序同時受兩個授權來源 A 與 B 支撐。在關閉授權來源 A 之前,A 底下的工作已經送出一則訊息到佇列裡、也預約好了一個供應商端的操作。你收到「取消成功」的回應、撤銷了啟動用的憑證、也看到本地流程已經結束——但佇列早就接受了那則訊息,遠端工作程序隨時可能把預約轉成一個真正的受保護動作。三個訊號都顯示「已經取消」,但實際上這個宣稱是錯的。
- 方法:論文定義「根範疇授權靜默」:針對每一個可能出現受保護動作的節點,證書要能證明「在撤銷生效前已經被接受的動作都被準確算清楚」「撤銷生效後不會再有依賴被撤銷授權來源的動作」,同時允許「還有其他獨立授權來源支撐的工作繼續合法執行」。協定用一次授權根的切點來啟動,凍結該根的擴張與受保護節點,把多重授權關係表示成「極小充分根集合」的組合結構,再把跨供應商的證書組合成一張切點證明,精確核算跨介面轉移的通道權杖。
- 為什麼重要:這代表「我按了取消」「我撤銷了 token」「我的流程結束了」這幾件事,沒有一件單獨能回答「這個 Agent 之後還有沒有可能做出新的受保護動作」——如果你的系統有委派、有非同步執行、有跨供應商操作,現有的取消機制給你的保證,可能比你以為的更薄弱。
深入要點
- 論文在自建的模型下證明六項性質:切點後發行方不再擴張、支持關係的投影正確、跨供應商組合下的可靠性、獨立授權支持的保留、合併順序無關性、當機重播後的穩定性
- 一套不依賴特定供應商的「延遲效應」測試套件在 17 條登記過的執行軌跡上全數符合預期結果:兩個只做取消、一個只做切點的執行接受了同一類已排程的延遲效應;兩個切點加凍結、一次重啟、一次過期程序的執行則拒絕了它
- 另一個獨立實作的檢查器驗證了同樣的 17 條軌跡,並拒絕了 44 個刻意製造的語意迴歸案例
- 論文明確劃出證書涵蓋範圍的邊界:這個證書證明的是「這個授權根範疇內的靜默」,不是全系統的閒置、不是回滾、也不是業務層面的任務真的完成
- Limitation(作者自述):證書的可靠性依賴於「所有相關端點都被完整或保守地涵蓋」這個前提;一個不提供任何可靠查詢、切點、到期或終端回條的不透明端點,無法對靜默證明貢獻任何正面的證據
Reviewer 一句話評
把「授權真的結束了嗎」這個模糊的實務問題,轉成有六項證明性質支撐的形式化定義,是這篇最有價值的貢獻;但驗證停留在一組不大的自建測試集,離「這套協定能不能整進 MCP、A2A 這些現有委派協定的真實部署」還有一段距離,讀者不該把形式化證明的完整性,誤讀成落地整合已經被驗證過。
給你的 take-away
- 如果你在設計會做跨供應商委派、有非同步任務佇列的 Agent 系統:讀論文的反例(1.1 節)確認自己現在的「取消」機制,是不是也只能回答「本地流程結束了」而回答不了「所有跨供應商的執行路徑都真的關掉了」
- 如果你在評估要不要導入這套形式化協定:先把它當成一套用來檢查現有委派撤銷設計哪裡有漏洞的思考框架,而不是可以直接整合進生產環境的現成元件
今日收穫
之前以為「有人審核」「模型夠聰明」「按下取消」就代表 Agent 的授權邊界是安全的,今天三篇論文分別戳破這三個假設:審核的意義完全取決於系統有沒有在執行當下重新核對操作內容,擋下風險的關鍵是工具呼叫前的確定性檢查層而不是換模型,而「取消」在委派與非同步執行下甚至還沒有一個嚴謹到可以證明的定義。三篇合起來說的是同一件事:Agent 的授權邊界不是一個你打開就能安心的開關,是要在架構的每一層——審核畫面、工具呼叫、委派協定——分別用工程手段核實過,才算真的存在的東西。
參考資料
- Loopjacking: Hijacking Human-in-the-Loop Approval
- Loopjacking — alphaxiv
- Loopjacking — evidence archive
- APort Vault: Benchmarking AI Agent Payment Authorization with the Open Agent Passport
- APort Vault — alphaxiv
- APort Vault — evaluation dataset
- Authorization Revocation for Long-Running AI Agents
- Authorization Revocation — alphaxiv
- arXiv cs.AI new listings
- HuggingFace Daily Papers
Loading...