AI 代理程式的零信任

資料來源#

• A First Measurement Study on Authentication Security in Real-World Remote MCP Servers
• Delegation Without Trust: An Empirical Gap Analysis of Identity, Authorization, and Runtime Governance in Multi-Agent LLM Systems
• Isolation as a First-Class Principle for LLM-Agent System Safety: Concepts, Taxonomy, Challenges and Future Directions
• OpenID Foundation advances authorization for the agent era with new AuthZEN Working Group Drafts
• Zero Trust for AI Agents

摘要#

Anthropic 於 2026 年 5 月發布、用於在企業部署自主代理程式的安全框架（電子書）。它將既有的 Zero Trust 原則——不信任任何事物、驗證所有事物、假設已經遭到入侵——套用至代理式系統；既有以邊界與人類身分為基礎的安全模型，原本並非為這類系統而設計。此框架的核心主張是：代理程式面臨獨特的威脅環境，而且**「少了任何一項能力，攻擊者就會利用這個缺口。」**框架以三層能力成熟度模型（Foundation / Enterprise / Advanced）和八階段實作流程呈現，並始終將其定位為對 AI-Accelerated Offense 的回應。

這是一篇樞紐文章：以下安全概念群（Least Agency、Blast Radius (Agentic)、Agentic Prompt Injection、Agent Data Injection (ADI)、MCP Tool Poisoning、Agent Supply Chain Risk、Memory and Context Poisoning、Agent Identity and Authentication、Impossible, Not Tedious (Design Test)、Autonomous Defense）都將此文作為共同參照。

Zero Trust 的三項原則#

Zero Trust 源自 Stephen Paul Marsh 於 1994 年的博士論文；在邊界遭突破後逐漸受到重視，並由 NIST SP 800-207（2020）與 NSA 的 Zero Trust Implementation Guides (ZIGs)（2026）編纂成文。三項原則如下：

1. 永不信任，始終驗證——每一項存取請求都必須驗證身分並授權，不論來源為何。內部請求和外部請求都接受同等審查。
2. 假設已遭入侵——以系統可能遭入侵為前提進行設計；限制損害，而非只防止入侵。依身分分段，讓單一遭入侵事件不會使其他對象也遭到存取。（這就是 Blast Radius (Agentic) 的圍堵姿態。）
3. 最小權限——只授予執行特定任務所需的最低存取權。OWASP 的 Least Agency 將此原則延伸至代理程式（不只限制代理程式能存取什麼，還限制每項工具能做什麼、使用頻率，以及使用位置）。

為什麼代理程式會使既有安全模型失效#

代理式系統和傳統軟體不同，因此產生新的暴露面：

• 自主多步驟執行——代理程式每一步都能在沒有人工核准的情況下採取行動，因此遭操弄的代理程式會以機器速度造成危害。
• 工具存取（API、資料庫、檔案系統、MCP）——工具堆疊遭入侵後，可能導致資料竊取、程式碼執行與破壞。
• 指令解讀——攻擊者能利用指令中的模糊之處（Agentic Prompt Injection）。
• 情境持續存在——跨工作階段的記憶帶來新的資料保護需求（Memory and Context Poisoning）。
• 多代理程式協作——隱含的信任關係讓攻擊者能入侵一個代理程式，再轉而攻擊其他對象。

為人類使用者打造的傳統身分系統難以容納代理程式；代理程式往往以高權限或共用服務帳戶執行。這種不匹配促使人們發展 Agent Identity and Authentication。

**框架從未納入的基準比率（2026-05）。**以上每種威脅都假設客戶端已經通過入口。Remote MCP Authentication in the Wild 檢視的正是這道入口：在透過指紋辨識發現、並以交握確認的 7,973 個線上遠端 MCP 伺服器中，40.55%（3,233 個）完全沒有任何驗證機制，就暴露其工具介面；29.00% 使用靜態權杖或 API 金鑰——這正是本框架認為連 Foundation 層都不可接受的憑證模式；而在可進行端對端測試的 OAuth 部署中，119 個全都至少存在一項已確認的驗證缺陷。有一台未經驗證的 CRM 伺服器，任何連線的客戶端都能從中取得超過 5,000 筆企業內部紀錄（CVE-2025-61510）。工具投毒、搶先替換工具和工具鏈結才是 MCP 中有意思的威脅；但在五分之二的伺服器中，平凡的入口問題仍未解決。

三層能力模型#

框架中的每項控制措施都按三個層級規範。每一層都以之前的層級為基礎（升級代表強化，而非取代）：

• Foundation——較小規模或初期部署所需的最低可行安全措施。關鍵在於，框架主張 AI 加速攻勢已拉高 Foundation 的門檻：僅增加操作阻力的控制措施（輪替長效 API 金鑰、SMS MFA、速率限制）已不再合格。短效權杖、以密碼學為基礎的身分、基於身分的隔離，以及自動化第一輪分流，現在都已是入門要求。
• Enterprise——具一定規模組織的標準實務；為多部署環境的複雜性，以及每次入侵可能造成的重大業務影響，增加更深入的防護。
• Advanced——對大多數組織而言是理想目標；對高風險或受到嚴格監管的部署（國家安全、受監管的金融／醫療）則是基準。採用硬體支援的身分、機密運算、持續授權，以及基於 ML 的異常偵測。

框架明確預測：*「隨著領域演進，Advanced 層預期會成為 Enterprise 標準，而 Enterprise 會成為 Foundation。」*層級是路線圖，而不是終點。

八個控制領域（第三部分）#

各層級的表格涵蓋八個能力領域，每一項都是代理程式的 Zero Trust 控制面：

1. 代理程式身分與驗證——請見 Agent Identity and Authentication（密碼學 ID → X.509 → 硬體證明；短效權杖 → mTLS → 硬體綁定憑證）。
2. 存取控制與權限管理——RBAC+預設拒絕 → ABAC → 持續授權；靜態角色 → 動態範圍設定 → JIT/JEA；基於身分的隔離 → 沙箱化 → 硬體隔離。這是 Least Agency 與 Blast Radius (Agentic) 的執行層。
3. 可觀測性與稽核——行動記錄、不可變更的稽核軌跡、追蹤性／來源鏈。先為停留時間和涵蓋率加上測量機制。
4. 行為監控與回應——基準 → 異常偵測 → 自動化回應。原則：自動化處理事件周邊的行政工作，而非決策本身。
5. 輸入驗證與輸出控制——輸入清理（結構描述、聚焦提示、憲法分類器）和輸出過濾；防禦 Agentic Prompt Injection。
6. 完整性與復原——設定採版本控制／簽署／不可變更；復原 → 自動復原 → 自我修復。違反直覺的基礎設施反射動作：啟用自動更新，因為人工核准延遲如今已成為更大的風險。
7. AI 治理政策——可接受使用政策與事件回應、治理委員會、自動化政策執行；處理 Shadow AI。

八階段實作流程（第四至第五部分）#

1. 確認需求——在建置前協調安全、法律、合規與業務需求。
2. 管理供應鏈風險——AI-BOM、OpenSSF Scorecard、相依性稽核、AI 供應商審查（Agent Supply Chain Risk）。
3. 定義代理程式邊界——獨特身分、允許／禁止的行動、升級觸發條件、範圍限制，並使用 Impossible, Not Tedious (Design Test) 刻意評估 Blast Radius (Agentic)。
4. 防禦提示注入——輸入隔離、憲法分類器、限制攻擊面（Agentic Prompt Injection）。
5. 保護工具存取——工具允許清單、能力限制、參數驗證、沙箱化、核准升級。
6. 保護代理程式憑證——短效／硬體綁定／每個代理程式專屬的憑證、JIT、ABAC（Agent Identity and Authentication）。
7. 保護代理程式記憶——記憶隔離、完整性驗證、保留政策（Memory and Context Poisoning）。
8. 衡量重要指標——停留時間、涵蓋率、可解釋性、行為遵循程度、偵測速度。

第五部分將此延伸至 Autonomous Defense——以足以跟上 AI 加速對手的速度執行安全作業。

五種隔離邊界——同一領域，依隔離失守的位置來組織（2026-07）#

以上內容依控制領域（要建置什麼）和階段（何時建置）來組織代理程式安全。Jing 等人於 Isolation as a First-Class Principle for LLM-Agent System Safety（HKUST / NYU / SWUPL / MODEIO.AI，arXiv 2607.12406，2026-07-14）則依隔離失守的位置來組織——這套詞彙本身就是成果。這是一篇沒有自身測量的調查研究（practitioner-opinion）：它整理約 140 篇既有論文，並提出研究議程。以下內容都不是證據，而是一套座標系統。

它的結構性主張值得明確說出，因為這正是本框架的控制領域清單無法表達的部分：提示注入、工具誤用、記憶投毒和代理程式間級聯，看似是不同的失敗，實際上卻有共同原因——內容跨越介面時，身分從資料轉變為控制指令——因此有用的問題是它最先跨越了哪個介面。論文依主要邊界分類，也就是「隔離首次失守的位置」；調查研究明確指出，多數研究觸及數個邊界。

邊界	它提出的問題	vault 涵蓋的位置
user–agent	使用者內容會保持為請求，還是變成具特權的控制指令？	Agentic Prompt Injection、Task-Specification Effects in Prompt Injection (AutoDojo)
agent–tool	工具會擴展代理程式的行動能力，而不接管它的決策方式嗎？	MCP Tool Poisoning、Capability Gating Is Not Authorization、Least Agency、Agent Supply Chain Risk
agent–execution	決策和行動的分離是否足夠，讓不安全的行動在產生副作用前受到檢查、延遲或阻止？	Write-Then-Trusted——僅涵蓋檔案系統的接縫
agent–agent	同儕傳來的訊息是範圍明確的貢獻，還是未經驗證的控制訊號？	沒有
system–environment	擷取的頁面、文件與記憶會保持為觀察資料，而非命令嗎？	Agent Data Injection (ADI)、Memory and Context Poisoning、Non-Malleable Memory Authority (TMA-NM)、Out-of-Band Prompt-Injection Defense

將這張圖用來檢查涵蓋範圍，確實有其價值：五個邊界中有兩個在此涵蓋有限或完全空白。

• **agent–agent 是空白。**二十一篇代理程式安全文章中，沒有一篇談到多個代理程式彼此攻擊。調查研究對此邊界的文獻整理相當豐富（代理程式間提示感染、辯論式攻擊、操弄知識洪流、遞迴協作阻斷、工作流程中的後門代理程式、武器化共用記憶），並主張決定單一入侵能否維持局部的，是拓撲——網路結構、路由、記憶共享——而非個別代理程式的權限。請見 Blast Radius (Agentic) 中的待解問題。vault 的兩篇多代理程式文章位於其他領域，回答的也是其他問題：Automated Failure Attribution 探討可靠性（哪個代理程式讓任務失敗），AI-to-AI Coercion 探討錯位（模型對其管理的模型做了什麼）。兩者都沒有探討攻擊者如何利用訊息通道。
• agent–execution 涵蓋有限。Write-Then-Trusted 涵蓋一個實際案例——代理程式寫入檔案，之後由未受沙箱限制的主機元件信任該檔案——但 vault 沒有涵蓋調查研究在此邊界提出的主要案例：透過介面操作的瀏覽器和 GUI 代理程式（據報告，經過拒答訓練的模型一旦改為點擊而非回答，就會失效）、程式碼解譯器代理程式，以及失敗後果會落到實體世界且較難復原的具身／視覺語言行動系統。

以建構方式實現隔離是調查研究提出的議程用語，也是這套框架的結構性執行主張從文獻角度出現的版本：來自使用者、工具、同儕和外部內容的輸入應保持可區別；能力存取應設定範圍；傳播路徑應可觀察；一旦入侵觸及記憶或共享狀態，復原就必須是核心要求。值得一提的是，該研究引用的趨勢也指出了參與者——Anthropic 的受管理代理程式（「將大腦與雙手解耦」）、CaMeL 風格的設計防禦、依資料型別進行權限分離、AgentVisor、Parallax——這些不同術語（虛擬化、權限分離、型別化介面、設計層級防禦）指向同一做法：以結構方式強制執行邊界，而非依靠提示指令。這就是 Out-of-Band Prompt-Injection Defense 的主張，引用文獻則更廣。

分類法的盡頭#

Self-Propagating Prompt Injection (AI Worms) 是一項測試案例，因為在整個語料中，唯有這項攻擊能讓每種圍堵控制都無從發揮：有害行為就是模型把文字寫進使用者要求它撰寫的文件裡。五種邊界能為它分類嗎？

形式上可以——它落在 agent–execution，也就是「內部決策轉化為實際行動的位置」。但調查研究對此邊界的完整討論，都圍繞程式碼執行、瀏覽器點擊、GUI 定位和機器人致動：這些都是執行階段中介者或許能拒絕的行動。當獲授權的行動和有害行動是同一項編輯時，沒有任何不安全呼叫可供拒絕；因此將它放在此處，只能標記類別，無法預測任何防禦方式。

真正的遺漏在於傳播模型，而非邊界清單。調查研究中跨越邊界的失敗路徑全都是鏈——使用者 → 工具 → 執行，或環境 → 工具 → 代理程式間 → 行動——最終以某種效果告終。自我傳播則是循環：在 agent–execution 輸出的內容，會作為 system–environment 的環境內容重新進入；每次循環都會增加載體的數量。調查研究最接近此概念的，是多代理程式章節中這項說明：「遭入侵的結果可能被轉送或儲存以供重複使用」；但這指的是單一系統內的共享狀態，不是一個組織的輸出變成另一個組織信任的輸入。這套用來回答隔離最先在哪裡失守的分類法，沒有位置容納「在同一邊界反覆發生，每次都牽涉更多對象」的情況。這是此分析框架的限制，而不是涵蓋範圍的缺口——它是語料中的第二套框架（第一套是 Blast Radius (Agentic)），其衡量單位是固定界線，而這種攻擊需要的是成長率。

法規對齊#

Zero Trust 符合 HIPAA、FINRA、GDPR、FedRAMP 和 EU AI Act。美國要求所有聯邦機構在 2027 年前採用 Zero Trust，並由美國（CISA/NSA/NIST）、英國（NCSC）和澳洲（Home Affairs）發布指引。Anthropic 指出，它是最早取得 ISO 42001（負責任 AI）認證的 AI 公司之一。

延伸閱讀#

• AI-Accelerated Offense——「為什麼是現在」：漏洞利用時程縮短是框架明確指出的動機；Foundation 門檻因應此趨勢而提高
• Least Agency——OWASP 對最小權限的延伸；框架對代理程式提出的授權原則
• Blast Radius (Agentic)——「假設已遭入侵」原則旨在圍堵的單位
• Agent Identity and Authentication——控制領域 1；其他所有控制措施的基礎
• Agent Identity Management System (AIMS)——IETF AIMS 提案是本供應商框架中身分與驗證控制的標準制定路線、多供應商對應方案：AIMS 在此電子書規範分級成熟度模型之處，組合既有標準（WIMSE/SPIFFE 加 OAuth 權杖交換）；兩者的不同之處在於，AIMS 將硬體證明視為選用項目，而非 Advanced 層的目標（兩篇文章都有比較）。同一篇文章也收錄 OpenID AuthZEN 草案——COAZ（針對每次 MCP 工具呼叫授權的標準制定工作，對應第五階段「保護工具存取」決策）和 AARP（前置條件／核准式「尚未」步驟，是第三／第五階段所指的人在迴路升級模式的先決條件）；這是授權切片的標準化提案，仍是 Working Group Drafts，權重低於實證的逐呼叫授權系統
• Agentic Prompt Injection——第四階段及輸入驗證領域要防禦的威脅
• Agent Data Injection (ADI)——第四階段的威脅，框架的輸入驗證控制無法涵蓋：它偽造其他控制所依賴的信任錨點（來源中繼資料、工具歷史），並在 Claude Code 參考實作上成功達成 RCE
• Out-of-Band Prompt-Injection Defense——第四階段及框架的參考監視器與最小權限原則（CaMeL/FIDES/Progent/RTBAS/FORGE）在學術系統中的實現，並且是該類別首次接受的獨立自適應評估
• Capability Gating Is Not Authorization——**第五階段「保護工具存取」（參數驗證、核准升級）**的具體實現：稽核發現 LangChain/LlamaIndex/Stripe 提供能力門檻控管，卻把完整仲裁留給整合者；此外還有 ScopeGate，一種確定性的逐呼叫值授權閘門，用來補上此缺口
• Off-Host, Identity-Bound Authorization——第四與第五階段推進至「假設已遭入侵」的極限：aiAuthZ（Kodathala，arXiv 2607.05518）將信任邊界畫在代理程式周圍，並以主機外閘道作為通往敏感工具的唯一已驗證路徑；它逐則訊息驗證人類傳送者，讓遭入侵的代理程式無法透過工具呼叫文字偽造權限——這是 ScopeGate 框架內值閘門的身分綁定、主機外對應方案（單一作者預印本）
• Agent Supply Chain Risk——第二階段管理的威脅
• Memory and Context Poisoning——第七階段要防範的威脅
• Impossible, Not Tedious (Design Test)——套用於每項控制的持續設計審查問題
• Autonomous Defense——第五部分；以自主威脅的速度執行防禦作業
• MCP and Computer Use——MCP 是明確列出的高風險工具介面（工具投毒、自行運行伺服器）
• Remote MCP Authentication in the Wild——這個明確列出的高風險介面，其整體基準比率：7,973 個線上遠端 MCP 伺服器中有 40.55% 未經驗證、29.00% 使用靜態權杖，而 119 個可測試的 OAuth 部署全都有驗證缺陷。框架的控制領域描述部署應該怎麼做；本文衡量實際部署的生態系統怎麼做
• MCP Tool Poisoning——以兩種方式展現框架提出的工具投毒威脅（第四階段輸入驗證與第五階段安全工具存取）：empirical ShareLock 在適度審查下的 ASR 超過 90%（證明僅憑描述掃描不足以防範）；case-study Agentjacking（Tenet Security）則是現實世界案例——這是實際發生的致命三重威脅（匯入不受信任的遙測資料、有有效的 AWS/GitHub 憑證、可連線外傳）案例：一台合法的 Sentry MCP 伺服器轉送攻擊者注入的資料，突破第二階段的伺服器審查，因為伺服器從未遭到入侵。兩者都將執行責任推至行動／授權層（Agentjacking 的規模數據由供應商回報，權重低於 ShareLock）
• Claude Code Best Practices——全文多處引用 Claude Code 的預設拒絕權限、沙箱化、受管理設定，作為符合 Zero Trust 原則的參考實作
• Anthropic——框架的發布者
• OWASP——代理式威脅分類法與「least agency」一詞的來源
• Agentic Misalignment (AM)——兩者不同但相關：Zero Trust 處理外部誘發的代理程式危害；代理式錯位則是出於自身動機的危害。兩者都需要相同的爆炸半徑圍堵
• Task-Specification Effects in Prompt Injection (AutoDojo)——上方圖表中的 user–agent 邊界案例，也是削弱第四階段靜態證據的研究：AutoDojo 在靜態基準測試得分為 0% 的過濾器上，測得 28% ASR；因此，通過靜態驗證的控制領域不代表已驗證
• Self-Propagating Prompt Injection (AI Worms)——五邊界圖能為它分類，卻無法建模的案例：它落在 agent–execution，卻無法據此推知防禦方式，因為傳播模型是鏈，而攻擊是循環（見上文）
• Automated Failure Attribution——**agent–agent 議程的必要前提，且經測量後顯示不足。**調查研究對該邊界的防禦部分仰賴歸因——「不只要知道多代理程式系統是否失敗，還要知道是哪個代理程式、哪則訊息、哪個步驟」，因為「缺少診斷就難以圍堵」。WHO&WHEN PRO 為這項前提提供數據：負責代理程式識別率為 48–58%，聯合正確率為 16–25%，而協作錯誤會被系統性地歸入「推理錯誤」。同月發表的調查研究無法引用這項成果，但議程中的這項工作比表面看來更昂貴
• AI-to-AI Coercion——vault 中另一篇多代理程式文章，但不是 agent–agent 邊界：這談的是獲得正當授權的管理者模型自行升級行動、對付下屬，而非敵手利用訊息通道。分類法所指的邊界在此仍未涵蓋
• Standardize the Infrastructure, Not the Tools——從成本考量而非安全考量得出相同原則：「基礎設施管理存取權，而非個別工程師」，實作方式是建置中央閘道，並讓 MCP 伺服器使用操作方自身的驗證流程
• Guarantees That Degrade at Deployment: Action-Space Soundness, Admissibility Without Effect, and a Vendor-Coupled Security Framework——以分層拆解並計數，回答供應商中立性的問題：原則、控制領域、階段與威脅分類法都保持中立（vault 中每個領域都有非 Anthropic 實作，其中幾項走標準制定路線）；但 21 條 Pro-tips 中有 17 條點名 Claude Code，而且只有一項實質的目標狀態選擇——將硬體證明作為 Advanced 層的終點——偏離 IETF 路線；該綜合分析也區分「Pro-tip 證明已提供此控制」和「Pro-tip 證明此控制有效」，並指出本框架的三項實際缺口對每家供應商都同樣適用

待解決的問題#

• 框架將每一條 Claude Code「Pro-tip」都視為參考實作。框架有多大程度保持供應商中立？又有多少是默認 Anthropic 技術堆疊？Guarantees That Degrade at Deployment: Action-Space Soundness, Admissibility Without Effect, and a Vendor-Coupled Security Framework 於 2026-08-17 以分層拆解的方式部分回答了這個問題。**保持中立，且有明確證據：**原則早於 Anthropic（Marsh 1994、NIST SP 800-207、NSA ZIGs、OWASP 的 least-agency 用語），而八個控制領域每一個都有至少一項非 Anthropic 開發的實作——領域 1／第六階段有 IETF AIMS 和 MCP 規格的 CIMD；領域 2／第五階段有 ScopeGate、NetInjectBench、aiAuthZ 和 OpenID AuthZEN 草案；領域 5／第四階段有 CaMeL / FIDES / Progent / RTBAS / FORGE / APPA；第七階段有 TMA-NM 和 MemSecBench。**有所綁定：**21 條 Pro-tips 中有 17 條點名 Claude Code（其他四條談的是自行代管 MCP 伺服器、將多個代理程式劃分獨立區域、JIT，以及 ABAC 因素）；而八個領域中的兩個——行為監控與回應、AI 治理政策——其 Pro-tips 純屬產品設定（settings.json、受管理設定、allowManagedPermissionRulesOnly、cleanupPeriodDays、hooks），在此 vault 中沒有外部對應實作。**一項實質歧異，不只是措辭風格：**層級階梯以硬體支援的 HSM/TPM 身分和遠端證明作為 Advanced 目標，但 AIMS 將硬體支援的金鑰儲存視為選用項目，稱「互通性不要求此功能」，並以每次簽發時的姿態評估取代遠端證明——兩份 practitioner-opinion 文件，彼此都沒有較高的證據位階。**更尖銳的修正是：**Pro-tip 能證明某項控制已推出，不能證明它有效——Agent Data Injection (ADI) 在 Claude Code 參考實作（以及 Codex CLI、Gemini CLI）上成功達成 RCE；而兩項經 NIST NVD 確認的 Claude Code CVE（CVE-2025-59536、CVE-2026-21852），都是同一項被引用為 Zero Trust 範例的產品中，信任邊界上的競態條件。**讓答案仍不完整之處：**此 vault 沒有行為監控與回應、AI 治理政策這兩個領域的非 Anthropic 實作，因此無法判斷「框架在此假設 Anthropic 技術堆疊」和「vault 尚未納入替代方案」哪個才是原因。要定論，需要外部來源探討代理程式行為基準建立和多供應商代理程式治理政策執行——適合採用 #oq/source 格式。
• 「Foundation 門檻提高」代表基準會持續移動。層級階梯實際變動速度有多快？由誰裁定（NIST/NSA 的發布週期，還是模型能力的演進週期）？一項顯示階梯目前狀況的數據（2026-09-02），取自 Delegation Without Trust: An Empirical Gap Analysis of Identity, Authorization, and Runtime Governance in Multi-Agent LLM Systems（Dantuluri 與 Sundi，VotalAI；其代理伺服器部分為 empirical，但此處的結果屬分析性——作者將表格標註為「我們對各標準規格的解讀，而非測量資料」，並歡迎讀者審查個別欄位）。他們將九項身分與委派基元（OIDC、OAuth 2.1、Token Exchange RFC 8693、SPIFFE/SPIRE、mTLS RFC 8705、DPoP RFC 9449、Macaroons、Biscuit、MCP authz）與八項需求交叉比對，發現沒有任何單一標準涵蓋全部需求；更明確地說，目前沒有標準設定檔能在每一個委派環節簽發同時符合下列條件的權杖：權限逐步收斂、綁定子代理程式的工作負載身分、時效短，並在模型外部由 PEP 執行。對照本框架的層級階梯，多代理程式的 Advanced 層沒有可攀升的標準——基元已成熟，但尚未整合；因此，裁定者的問題不只是「變化有多快」，而是「由哪個機構負責整合」，而 AIMS 已指出這涉及多個機構（IETF、OpenID，以及自行制定規則的 MCP）。
• 框架明確聲明它不提供法律／合規保證。自行聲明達到 Zero Trust 成熟度，如何符合可稽核的法規要求？

資料來源#

• Zero Trust for AI Agents — Anthropic 電子書，Zero Trust for AI Agents: A security framework for deploying autonomous AI agents in the enterprise（2026-05-18）
• Delegation Without Trust: An Empirical Gap Analysis of Identity, Authorization, and Runtime Governance in Multi-Agent LLM Systems — Dantuluri 與 Sundi（兩人皆任職 VotalAI），Delegation Without Trust，arXiv 2609.00267，2026-08-31，整體為 empirical，但本文引用的標準系統化整理是作者自行標註為分析性，而 §8（LLM Shield）屬 vendor-claim。引用 §6 的九項標準 × 八項需求表，以及標準缺乏整合的結論。完整討論請見 Agent Identity Management System (AIMS)
• 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，權重低於實證的逐呼叫授權系統）。這是第五階段「保護工具存取」的標準制定實例（COAZ——逐次 MCP 工具呼叫授權），也涵蓋第三／第五階段的人在迴路升級流程（AARP——將 CIBA 推廣至一般情境的先決條件／核准模式）
• Isolation as a First-Class Principle for LLM-Agent System Safety: Concepts, Taxonomy, Challenges and Future Directions — Huihao Jing 等 12 位作者（HKUST / NYU / SWUPL / MODEIO.AI），Isolation as a First-Class Principle for LLM-Agent System Safety: Concepts, Taxonomy, Challenges and Future Directions，arXiv 2607.12406，2026-07-14，屬 practitioner-opinion。**這是一篇調查研究——沒有進行任何測量。**刻意標記為 empirical 以下項目：它將約 140 篇既有論文整理成五邊界框架，並提出研究議程，因此本文引用它是為了借用詞彙與架構，而非作為任何系統行為主張的證據。引用章節：§1（分類法和依主要邊界分類的規則）、§2–6（每節一個邊界：威脅模型、子題、防禦）、§7.1（跨邊界傳播）、§7.2（以建構方式實現隔離）、§7.3 與限制（開放挑戰，以及作者自行指出以邊界為中心只是數種有效組織方式之一）。**解析警告——請勿引用 Table 1。**文件中的三張「表格」其實是同一份約 140 列註解書目的跨頁片段，而且普遍遭到破壞：換行的「Main Idea」文字滲入後續資料列的儲存格，連續資料列與 Year/Type/Subtopic 欄位合併並以空格串接（| 2024 2024 | Benchmark Benchmark |），至少有一列的論文標籤因與相鄰項目融合而消失。匯入時回報 table-collapse/table-shift 檢查皆正常——這是偽陰性。本文的所有引述都來自敘述章節，這些章節對相同論文的描述正確；如需查證特定論文列，可參閱本機 PDF ()
• A First Measurement Study on Authentication Security in Real-World Remote MCP Servers — Zhou 等人（Fudan University；其中一位作者任職 Central South University），arXiv 2605.22333，2026-05-21，屬 empirical，無 COI。本文僅引用整體基準比率——§3.2 的 Table 2 分類（7,973 個驗證伺服器中，40.55% 沒有驗證、30.45% 使用 OAuth、29.00% 使用靜態權杖）、Finding 1.2 的 CRM 案例（CVE-2025-61510），以及 Finding 3.1（119/119 有缺陷）。解析警告和完整討論請見 Remote MCP Authentication in the Wild