主機外、綁定身分的授權

資料來源#

摘要#

Sai Varun Kodathala（SportsVision AI R&D；arXiv 2607.05518，2026 年 7 月）提出 aiAuthZ：一個授權閘道，在代理主機外、代理沒有任何憑證的獨立信任網域中，回答決定任何代理行動是否安全的兩個問題——誰在請求？以及這個呼叫者是否獲准？這個論述的前提正是本群組一再遇到的問題：使用工具的模型「根據無法驗證的文字發出工具呼叫，因此任何控制部分上下文的一方，都能偽造權限的表象」。把安全決策放在代理程序內部無法解決這件事，因為存在於遭入侵程序中的權限系統也會隨之遭入侵。aiAuthZ 的答案是把兩個問題都移出模型，並將答案綁定到加密身分，而不是代理說了什麼。

證據限制（請附在承重論述處）：這是來自小型商業研發機構的單一作者預印本，不是經過同儕審查或多供應商驗證的來源。它確實報告了可重現、開源的實證評估（15 個模型、AgentDojo、收據健壯性、釋出的程式碼與逐字記錄），因此其測量屬於 empirical——但應把這項設計視為一位研究者的提案，在採用問題上其權重低於多供應商標準工作（AIMS），並注意幾個標題數字依作者自己承認的說法其實接近必然結果（如下）。其 evidence: 層級是 empirical。

**為何值得成為獨立節點：**它是資料庫中 ScopeGate 的主機外對應方案——兩者都執行確定性的逐次呼叫授權，但位於「授權邊界在哪裡？」這條軸線的不同位置（框架內 PDP/PEP 對主機外身分綁定閘道），而且 aiAuthZ 增加了 ScopeGate 完全沒有的一層：對人類傳送者逐則訊息進行身分驗證。

將兩個問題移出主機#

每個請求都會出現三種主體。使用者是代表其採取行動的人類（或指定的系統身分）；每位使用者在註冊時取得一把每人專用的 HMAC 金鑰，以及四種角色之一（owner、member、guest、system）。服務是代理執行環境，使用永遠不代表使用者的服務權杖進行驗證。管理員操作控制平面。閘道永遠不信任執行環境對目前使用者的宣告：工作階段的目前使用者，就是最近提交 HMAC 驗證訊息的人，而執行環境必須在每個工具呼叫中回傳該訊息的識別碼。

信任邊界就是整個設計的核心。閘道、其政策資料庫，以及 nonce／速率限制儲存區，都在代理無法觸及的基礎設施上運行。另一側的所有內容——代理程序、其上下文視窗、它讀取的每份文件／訊息／工具結果、它發出的每個工具呼叫——都不受信任。「閘道把模型視為不受信任的請求發出者。」它說的是 Model Context Protocol（JSON-RPC：initialize、tool-list、tool-invoke）與一般 HTTP，因此執行環境可像連接普通工具來源一樣連接它；預設情況下，它是回傳允許／拒絕的授權決策點（拒絕會以協定錯誤傳遞，讓執行環境無法將其誤認為結果），而不是執行者。

逐則訊息身分：承重的新穎性#

每則使用者訊息都帶有 HMAC-SHA256 簽章，使用該使用者的祕密金鑰，對五個欄位的標準 JSON 編碼計算：使用者 ID、工作階段 ID、訊息內容的 SHA-256 雜湊、隨機 nonce，以及 Unix timestamp。驗證分為三個確定性步驟：timestamp 必須落在視窗內（預設 300 秒）；簽章必須通過常數時間比對；nonce 必須是未見過的（在共享儲存區中以原子性的 set-if-absent 加上到期時間寫入），如此一來，即使在視窗內，截獲的訊息也無法重播。

兩個綁定機制會把已驗證訊息轉成授權錨點：

最早的已驗證訊息會把工作階段綁定到該使用者；不同使用者提交到同一工作階段時會被拒絕（阻止跨使用者工作階段劫持）。
每則已驗證訊息都會成為工作階段的目前訊息，並具有有限生命週期，且每個工具呼叫都必須回傳目前訊息 ID——因此工具呼叫只有在已驗證人類回合後的有限時間內才會成功，且其權限源自該回合。

這是資料庫中其他內容都沒有的特性。「訊息本文可以宣稱任何事情，包括 owner 已批准該行動，但綁定的身分是加密的，而該宣稱不會賦予任何權限。」這正是它能阻止 Agents of Chaos 語料庫中的權限冒充與遭破壞的憲法攻擊，以及（見下方 §5.4）五個僅參數式政策在結構上無法與合法 owner 使用區分的身分冒充案例。請注意範圍：當攻擊者是與目前使用者不同的主體（宣稱具 owner 權限的非 owner）時，這項綁定具有決定性；它本身不會限制在目前使用者自身權限下觸發的注入——那項殘餘風險只能由參數與速率政策限制（即 ScopeGate 和 ADI 所稱的同一種可合法變動資料遭竄改限制）。

主機外政策（三道閘門）#

政策是附加在 scope 上的 YAML（user > workspace > 保守的內建預設值），依序評估並採用失敗即關閉：

角色閘門——每個工具都會列出允許的角色；政策中不存在的工具會落入預設值，而已附帶的設定中預設值是拒絕。預設拒絕非 owner 使用 shell/file/email/env 工具。
參數限制——檔案工具的 glob 路徑拒絕／允許清單、網路工具的 URL 允許／拒絕清單、訊息工具的收件者允許清單，以及寫入資料的位元組上限。這能關閉透過已允許工具進行的提權：member 可以擷取網頁，但空白的 URL 允許清單仍會拒絕傳送到任意主機的擷取。
速率限制——每個工具使用固定視窗計數器；遭拒絕的呼叫不會計入，因此攻擊者不能用被拒絕的請求耗盡預算。

每個決策都帶有結構化原因（role_not_in_allowlist:member、path_denied:/etc/passwd），回傳給呼叫者並記錄在稽核鏈中。關鍵在於，政策存在代理沒有憑證的資料庫裡，因此「被操縱的代理無法改寫自己的授權」——這是頻道外原則「閘門不能是模型，政策必須在頻道外」的身分層回應。

防竄改稽核、可存活收據、憑證代理#

三種支援機制讓整體組合更加完整：

防竄改稽核鏈——每個驗證結果與工具決策都會在 SHA-256 雜湊鏈中新增一列（每列都綁定前一個雜湊）；驗證端點會回報第一個斷裂處。加密抹除保留策略：編輯流程會清除過期資料列的加密負載欄位，但不刪除資料列（編輯本身也會加入鏈中），因此 GDPR 風格的資料主體抹除與未斷裂的鏈可以共存。只有當鏈首雜湊在外部錨定時，才能偵測對整張表的特權改寫。
簽署的 QR 收據——在行動獲得授權時產生的證明，證明特定人士授權了特定行動；即使影像被轉寄、截圖並重新壓縮，也能由事後才看到它的第三方驗證。設計將截短的 128 位元 HMAC-SHA256 標記（涵蓋 user id、message id、內容雜湊，絕不包含明文）放入 QR code：這是一種自定位、經 Reed-Solomon（level H）錯誤校正的載體，可在旋轉／縮放／裁切後重新同步。驗證是常數時間的標記比對——沒有相似度門檻，也沒有需要調整的誤接受率。這勝過作者測量的替代方案：對檔案位元組做分離式 Ed25519 簽章確實完全不可偽造，但任何重新編碼都會使其失效；DWT／展頻浮水印能撐過 JPEG，卻會在截圖／裁切下崩潰，而最常見的函式庫沒有金鑰（可輕易偽造）。
憑證代理——祕密只存在閘道上；代理以名稱引用它們，且只有在獲得授權後才會取得存取權，因此遭入侵的代理主機不持有長期憑證——這是三種「關閉繞過路徑」緩解措施中最強的一種（合規檢查器 → 出站鎖定設定檔 → 代理）。

評估#

四個研究問題，全部在未修改的 production 程式路徑上進行，且釋出程式碼與逐字記錄。

RQ1——模型層級拒絕不均，且與價格無關。 15 個當代模型 × 8 個攻擊情境（改編自 Agents of Chaos 紅隊測試語料庫——Shapira 等人，以純文字引用），每個情境在不同溫度下執行 5 次；若危險呼叫在至少 1 次執行中觸發，該情境就算作一次嘗試（最壞情況的易受攻擊程度）。在完整評估的模型中，拒絕率從 100%（Fable 5）降至 38%（Qwen3 Max 在受速率限制的 4 情境子集達到 25%）。最昂貴的模型（Opus 4.8，每案例約 $0.0095）只拒絕 50%；最便宜的模型（DeepSeek V4 Pro，每案例約 $0.0004）在可比條件下拒絕 38%——價格相差約 20 倍，但安全性沒有排序關係。內容分類器（Llama Guard）只標記出 8 個攻擊中的 4 個，因為這些是以普通請求措辭表達的未授權行動，而不是有害文字——因此 guardrail 與此閘道是互補的。
RQ2——閘道以低成本歸零殘餘風險。 當呼叫者綁定為非 owner 時，政策會拒絕每個情境所需的僅限 owner 工具類別，因此抵達工具的殘餘攻擊成功率，在 ≤0.03 ms 額外延遲下，對 15 個模型全部為 0%（0.006–0.030 ms；模型呼叫本身花費 1.1–12.5 秒，長了五個數量級）。作者坦率承認這項特定結果接近必然（「預設拒絕政策拒絕一個遭拒的工具……是立即的」）；重點是每個模型都相同的確定性，因此模型層級的巨大分散不會傳播到工具。逐則訊息身分的獨特貢獻——固定角色以對抗冒充者——在 RQ3 中隔離，而不是在這個實驗中測量。
RQ3——與先前確定性設計比較（身分收益）。 在 9 個納入範圍的 Agents-of-Chaos 案例中，完整設計阻擋 9/9；仿照 Open Agent Passport 的僅參數式政策阻擋 4/9；仿照 Agent Identity Protocol 的委派權杖設計單獨只能阻擋 0/9（範圍不匹配——委派不攜帶參數政策）。僅參數式設計漏掉的五個案例，正是身分冒充案例：攻擊者使用通常允許的工具；僅行動政策「無法區分非 owner 與 owner」，因此必須對所有人允許該工具（冒充者通過），或對所有人禁止（破壞 owner 使用）。逐則訊息身分透過拒絕非 owner、允許 owner 解決此問題。區域決策延遲為 0.008–0.026 ms，相較之下僅參數系統回報的雲端登錄查詢為 53 ms（約 3000 倍）。
AgentDojo 銀行測試套件（important_instructions，20 對，Fable 5 + Gemini 3 Flash）。兩個模型在模型層級已具抵抗力（無防禦 ASR 為 0%），因此幾乎沒有殘餘風險可移除；spotlighting 沒有幫助，在 Gemini 上反而讓 ASR 升至 2/20，因誘發了注入所尋求的確切付款；而 aiAuthZ 維持 ASR 為 0%，並確定性地阻擋模型發出的 7 個攻擊者導向呼叫（付款、重新導向排程交易、2 次變更密碼）。誠實代價是：嚴格的已知收款人允許清單讓乾淨效用從 100% 降至 80%（阻擋一次向新收款人的合法首次付款），因此對基線 ASR 已為 0% 的模型而言，閘道在此是淨效用成本——作者選擇報告而非隱藏。這個套件中的阻擋來自參數限制，而非逐則訊息身分（注入與使用者共用同一主體），因此任何採用相同允許清單的確定性價值閘門都能達到同樣效果。
健壯性補充。 長上下文：在 500→48,000 token 記錄中埋入資料外洩指令，隨上下文增長，部分模型反而更常遵從；閘道阻擋全部 12 次嘗試（判決不受上下文長度影響）。收據：簽署 QR 在八種通道上的平均驗證率為 94%（調整大小／截圖／裁切為 97%），錯誤金鑰偽造 0/25；分離式 Ed25519 簽章只有在原始檔案上能驗證，而所有浮水印在截圖／裁切下都降至 0%。端到端：透過即時 JSON-RPC 阻擋 4/4 個危險 MCP 呼叫；真實的 OpenClaw 執行環境部署確認了拒絕路徑與合規檢查器（當重疊的內建工具仍啟用時，會讓 CI 失敗）。58/58 個單元測試通過。

aiAuthZ 與 ScopeGate：授權邊界軸線上的兩個位置#

它與姊妹頁面 Capability Gating Is Not Authorization（ScopeGate）的精確關係如下：

共享核心。 兩者都是確定性、失敗即關閉、逐次呼叫的授權閘門，具備參數層級允許清單、模型既無法讀取也無法修改的頻道外政策、微秒級延遲，且決策中沒有 LLM。兩者共享相同的兩種殘餘風險：一連串個別獲准的呼叫組合成不想要的結果，以及可合法變動的參數遭竄改，而價值政策無法限制。aiAuthZ 自身的僅參數消融基線基本上就是 ScopeGate 的形狀（沒有身分層的參數閘門）。
邊界所在位置。 ScopeGate 是框架內 PDP/PEP，其作者主張，只要每個具有副作用的呼叫都通過 PEP，且政策在頻道外，安全性就與部署位置無關（SDK 中介軟體、迴路側車或出站閘道皆可）。aiAuthZ 正好以一項測量結果反駁這點：當執行環境保留自身重疊的內建 shell/file/web 工具時，「模型透過內建工具執行了敏感行動，完全沒有諮詢閘道」——程序內 PEP 與攻擊者透過模型影響的信任網域相同。因此 aiAuthZ 讓獨立信任網域成為承重部分，並以合規檢查器、出站鎖定設定檔與憑證代理予以強制。
身分層。 ScopeGate 沒有呼叫者驗證步驟——它根據操作員政策授權 (tool, args)，但將主體／工作階段視為既定。aiAuthZ 增加了對人類傳送者逐則訊息進行 HMAC 身分驗證；其相較僅參數基線的 9/9 對 4/9 優勢，正是該層的測量價值：它能阻擋純參數政策看不見的身分冒充（非 owner 宣稱具 owner 權限）。合併閱讀這兩個頁面，可以框住設計空間——ScopeGate = 參數層級授權、框架內；aiAuthZ = 參數層級授權 + 逐則訊息身分、主機外。

標準化路線上的對應方案（OpenID AuthZEN / COAZ）#

aiAuthZ 是已部署的研究閘道；OpenID Foundation 的 AuthZEN Working Group 正將相同的逐次授權邊界標準化為可互通的設定檔。AuthZEN 的 Authorization API 1.0 定義了 Subject-Action-Resource-Context（SARC） 允許／拒絕決策介面，aiAuthZ 的主機外閘道目前以臨時方式實作了這個介面；新近核准的 COAZ Working Group Draft（2026-06-15）則將 MCP 工具呼叫映射到 SARC，使任何相容的 PDP——例如和 aiAuthZ 完全相同的 API／AI 閘道——都能在呼叫點授權工具呼叫。雙方重疊之處是參數層級政策；AuthZEN/COAZ 沒有標準化 aiAuthZ 的獨特部分：對人類傳送者逐則訊息進行 HMAC 身分驗證（也沒有標準化主機外的獨立信任網域要求）——這些仍是 aiAuthZ 自身的貢獻。AARP 草案是可恢復核准步驟的標準對應方案：它不是對超過門檻的行動終止拒絕，而是定義「還不行——這是必要前置條件」的交握（泛化 CIBA），由人或自動化治理系統在政策重新決策前滿足條件。以上都是提議中的互通性標準（practitioner-opinion、Working Group Drafts），在重疊部分其權重低於 aiAuthZ 的 empirical 測量；完整討論請見 AIMS。

它做不到的事（限制）#

作者明確說明、值得延續注意的事項：

它不是提示注入偵測器或內容防護欄。 注入文字按設計會通過輸入；防禦在於注入文字無法改變與工作階段綁定的身分。它與 Llama Guard／Constitutional Classifiers 互補，而不是替代品。
繞過問題是部署義務，而非系統屬性。 保留重疊內建工具的執行環境會在未諮詢閘道的情況下行動；合規檢查器／出站鎖定／代理可以關閉這條路徑，但每一項都是操作員的選擇。
不可否認性的取捨。 逐則訊息身分使用對稱式 HMAC（快速、微秒級），因此稽核能向操作員證明真實性，卻不能向第三方證明——閘道持有金鑰，原則上可以鑄造有效標記。對需要防止操作員否認的部署，作者提出非對稱簽署模式作為擴充。
沒有與程序內防禦進行正面比較。 比較對象是兩個最接近的同期設計（OAP、AIP）的縮減設定，不是針對 CaMeL 或 Progent 的效用匹配基準測試。主機外信任邊界是否能在兩種設計共享的參數政策之外帶來可測量的安全差異，明確留作下一步——這正是來源場域限制應持續提醒我們的缺口。

開放問題#

信任邊界溢價尚未測量。 aiAuthZ 主張主機外優於程序內，但其自身比較只針對僅參數／委派權杖消融，而非與 CaMeL 或 Progent 進行效用匹配的正面比較。獨立信任網域是否能在共享參數政策之外帶來可測量的安全性——作者點名的下一步，也是單一作者預印本限制應保留開放的核心問題？
大規模政策由誰撰寫？ 如同 ScopeGate，主機外政策（角色允許清單、路徑／URL／收件者限制、上限）由操作員撰寫並在頻道外運作。同一個撰寫負擔問題也適用：為大型工具表面維護已驗證集合，是否會使控制只能適用於高風險工具？
不可否認性缺口。 對稱式 HMAC 能提供面向操作員的真實性，卻不能提供第三方不可否認性；若要部署提議中的非對稱模式，是否仍能維持使閘道具吸引力的微秒級延遲，或金鑰管理會侵蝕成本優勢？
目前使用者的殘餘風險。 逐則訊息身分只有在攻擊者是不同主體時才具決定性。在目前 owner 自身權限下觸發的注入，只能由參數／速率政策限制——與每個價值閘門相同的限制。除了來源／資料流追蹤（CaMeL Strict）之外，什麼能關閉這一半的風險？

資料來源#

OpenID Foundation advances authorization for the agent era with new AuthZEN Working Group Drafts — OpenID Foundation，…advances authorization for the agent era with new AuthZEN Working Group Drafts，2026 年 6 月 15 日，practitioner-opinion（提議中的 Working Group Drafts，不是已批准的規格；權重低於 aiAuthZ 的 empirical 測量）。aiAuthZ 主機外逐次呼叫閘門的標準化對應方案：AuthZEN Authorization API 1.0（SARC 允許／拒絕）、COAZ（MCP 呼叫 → SARC 設定檔）、AARP（泛化 CIBA 的必要條件／核准模式）；不標準化 aiAuthZ 的逐則訊息人類身分或主機外信任邊界
aiAuthZ: Off-Host, Identity-Bound Authorization for AI Agents — Sai Varun Kodathala，aiAuthZ: Off-Host, Identity-Bound Authorization for AI Agents，arXiv 2607.05518，2026 年 7 月，empirical（單一作者預印本，SportsVision AI）。§1（問題：使用工具的模型依據不受信任文字行動；程序內權限系統會與程序一起遭入侵；Agents of Chaos 動機——7/11 案例是身分／授權失敗）、§2（三種主體；信任邊界；範圍內／外威脅；表 1 標準對應）、§3（逐則訊息 HMAC 身分 + 兩個綁定；三道閘門的主機外政策；雜湊鏈稽核 + 加密抹除；簽署 QR 收據；關閉繞過路徑）、§4（FastAPI/MCP 實作，58 個測試）、§5（評估：表 2 的 15 模型拒絕率 100%→38% + 殘餘率在 ≤0.03 ms 時降至 0%；表 3 Agents-of-Chaos 案例；§5.4 RQ3 的 9/9 對 4/9 對 0/9；表 4 AgentDojo 銀行；表 5 長上下文；表 6 收據 94%／0 偽造；表 7 即時 MCP）、§6（限制：繞過、組合、不可否認性取捨、沒有 CaMeL/Progent 正面比較）、§7（相關工作：OAP/AIP 同期研究、程序內 CaMeL/Progent/IsolateGPT、SPIFFE/OAuth/ETDI 工作負載身分、guardrail、浮水印）。依照影像兩遍規則檢視圖 1、4、5、6；docling 的連在一起的圖說只是外觀問題，且與表格一致。

主機外、綁定身分的授權

資料來源#

摘要#

將兩個問題移出主機#

逐則訊息身分：承重的新穎性#

主機外政策（三道閘門）#

防竄改稽核、可存活收據、憑證代理#

評估#

aiAuthZ 與 ScopeGate：授權邊界軸線上的兩個位置#

標準化路線上的對應方案（OpenID AuthZEN / COAZ）#

它做不到的事（限制）#

相關連結#

開放問題#

資料來源#