AI Agent 身分驗證是什麼？委派授權、OAuth 與 agent identity 標準

重點摘要

• 2026 年 6 月 14 日，具身分安全背景的研究者公開指出：AI agent 的認證與授權標準仍在制定中，但各廠商技術實作已快速鋪開，標準確立前的搶先部署正在累積碎片化風險。
• Agent 身分有兩個核心問題：agent 絕不應持有或傳遞可再認證的金鑰材料；授權範圍必須細粒度、時限化，且能依任務當下情境動態調整。
• Workload Identity Federation（工作負載身分聯合）等技術已能部分解決第一個問題；AAuth 協議與 IETF 相關工作流程正處理第二個，但兩條線同時跑的狀態對工程師的選型決策有直接影響。

2026 年 6 月 14 日，一位長期與 Microsoft Identity 團隊在標準工作群協作的身分安全研究者，在部落格發文提出警告：AI agent 的身分認證與授權標準尚未落地，但各家廠商的技術實作已快速鋪開。他指出，標準工作本來就慢，但 agent 領域如今有一種少見的緊迫感，這本身就不尋常。他的核心觀點是：agent 時代的下一個基礎設施缺口，正是身分（identity）與授權（authorization）本身，而多數工程師還沒意識到問題的結構有多深。

Agent 身分問題是什麼，為什麼現在才急迫？

OAuth 2.0 和 OIDC（OpenID Connect，開放身分連接協議）重塑了整個 web 的安全架構，解決了「人如何授權服務存取其資源」的問題。但 AI agent 帶來了一個結構上根本不同的情境：不是人在做授權決定，而是軟體在替人做事，跨多個系統、多個步驟，甚至多個子 agent 串接完成一個任務。

傳統 OAuth 授權流程的設計假設有一個人站在同意視窗前點擊「允許」，授予應用程式特定範圍的存取權。一個自主執行任務的 agent，收到使用者的原始指令之後，可能需要即時向多個 API 發請求、串接多個工具、甚至派生子 agent。每個環節的授權需求，都是動態的、情境相依的，不是可以在最初同意時完整預設的。這個差距把舊有授權模型的理論設計缺陷，拉成了具體可被攻擊的漏洞。

OAuth 本身也走了很多年才成熟，標準遲緩不是新鮮事。但這位研究者指出，agent 技術的部署速度遠快於標準制定的節奏，這種技術超前標準的非同步狀態，本身就是結構性風險。每一個今天落地的實作，都在為未來的碎片化奠基。

兩大核心挑戰：金鑰不能傳，授權不能靜態

這個缺口有兩個具體的層次，分別對應不同的技術難度。

第一個：agent 絕對不應該持有、接收或傳遞可用於後續認證的金鑰材料（key material）。如果 agent 本身能用來認證，任何充當金鑰中繼的中介服務就成了攻擊者的高價值目標。他以目前正在實作的 Entra Agent ID 作為具體對照：這個機制讓 agent ID 只能作為「被委派者」（delegate）存在，本身沒有認證能力。即使 agent ID 洩漏，攻擊者拿到的也只是無法自行認證的識別符，沒辦法直接冒充。Entra Agent ID 把「agent 不持有金鑰」從原則落地成具體機制。

第二個挑戰的難度更高：授權範圍需要細粒度、時限化，且能依任務當下情境自適應。現行的 OAuth 同意流程，授予範圍通常比 agent 實際需要的還廣。原因不複雜：在 agent 開始工作前，你幾乎不可能完全預知它的每一步需要存取什麼。研究者指出，工程師的常見解法是「給一個比較寬的範圍，之後再調整」，但「之後再說」幾乎等於「永遠不撤銷」。寬授權加上不撤銷，就是今天 agent 授權問題的基本形態。這比第一個問題更難：它需要運行時的情境感知，架構設計時無法一次解決。

現有技術能解多少？Workload Identity Federation 與 AAuth 的位置

好消息是，第一個問題今天已有技術路徑可以處理。Workload Identity Federation（工作負載身分聯合，WIF）是其中主要的一條。Anthropic 在其技術文件中記載了對 WIF 的支援，但這位研究者指出，Anthropic 在《Zero Trust for AI Agents》白皮書中沒有明確提到這項技術。他認為白皮書整體方向值得肯定，但在這類技術細節上有落差，是可惜的。

Dick Hardt 也對這份白皮書提出了公開批評，這位研究者強烈推薦 Hardt 的文章，視之為理解 AI 開發者與身分安全領域之間認知落差的最佳入門。這個落差並非修辭上的說法：兩個社群對「agent 需要什麼樣的授權機制」的理解，起點就不同，而這份起點差異，正是碎片化的深層成因之一。Hardt 目前也在推動 AAuth 協議的制定，這個協議與 IETF（Internet Engineering Task Force，網際網路工程任務組）多個工作流程有相當程度的重疊，核心關切正是第二個挑戰：如何把授權從靜態的允許或拒絕，推進到能依任務情境動態調整、細粒度、有時限的設計。

這些努力目前仍在制定階段，AAuth 和 IETF 相關草案都還未完成。技術比標準跑得快，這是整個問題當前最核心的張力。

標準未定、技術先行：碎片化風險有多真實？

當一個基礎設施層的標準還沒確立，而技術已快速落地，最直接的結果通常是：各家廠商發展出自己的解法，等標準出來才發現互不相容，然後開始清理歷史債。Web 安全的歷史裡這個模式並不陌生。

OAuth 2.0 確立之前，各平台的授權機制各行其是，「讓第三方應用存取你的帳號」這件事在不同服務上有完全不同的做法，安全品質也參差不齊。OAuth 2.0 和後續的 OIDC 確立之後，整個 web 在授權這件事上有了共通的底層語言，安全品質隨之大幅提升。這位研究者明確表達的判斷是：在身分安全領域，沒有比 OAuth 2.0 和 OIDC 的出現對 web 安全改善更大的事了。

agent identity 標準有機會扮演同等角色，但這個機會窗口是有時限的。每一個搶先落地的廠商自訂實作，都在為未來的碎片化添磚。對正在構建 agent 產品的創業者，這是雙向的風險：選錯了基礎授權架構，在標準確立後可能面臨大幅重構；但如果現在就對齊正確方向，例如優先採用 WIF 而非廠商自訂的金鑰傳遞機制，提前對齊正確方向本身就是安全架構投資，不必等碎片化後果出現才回頭重構。

agent identity 標準的制定現在是 IETF 和業界技術社群的活躍議題，但還沒有進入主流工程師的日常關注。AAuth 協議的進展、IETF 相關工作群的草案動向，是值得提早追蹤的切入點。OAuth 2.0 當年的教訓很清楚：等到標準普及再學習，通常已經是在修補選型錯誤的舊債。

常見問題

• Agent 為什麼不能直接持有 API 金鑰做認證？

如果 agent 持有可再認證的金鑰材料，任何充當中繼的中介服務就成為攻擊者的高價值目標，一旦金鑰洩漏，攻擊範圍可以直接擴展到所有 agent 有權存取的服務。正確的設計方向：agent 只作為被委派者，本身沒有自行認證的能力。Entra Agent ID 朝這個方向設計。

• Anthropic 的 Zero Trust 白皮書被批評在哪？

根據這位研究者的觀察，Anthropic 在其他技術文件中有記載對 Workload Identity Federation 的支援，但在《Zero Trust for AI Agents》白皮書中未明確提及，他認為這是一個具體的技術落差。Dick Hardt 也對白皮書提出公開批評，研究者強烈推薦 Hardt 的文章，認為它能清楚呈現 AI 開發者與身分安全領域之間的認知差距，而這個差距正是碎片化問題的根源之一。

• AAuth 和 OAuth 2.0 是替代還是延伸關係？

從這位研究者的描述來看，AAuth 針對 OAuth 2.0 無法處理的動態授權需求，與 IETF 多個工作流程高度重疊，兩者並非替代關係。不過 AAuth 仍在制定中，它與 OAuth 2.0 的確切關係需要持續追蹤 IETF 工作群的最新草案才能確認。