Agent 身分與驗證

資料來源#

• AI Agent Authentication and Authorization
• Zero Trust for AI Agents

摘要#

身分與驗證是 Zero Trust for AI Agents 中所有其他安全能力的基礎控制：沒有可驗證的身分，就無法實施存取控制、維護稽核軌跡，或將行動歸因於特定主體。沒有獨立身分時，agent 會處於*「歸因缺口」中，使 Least Agency 的實施變得不可能。這套框架的立場十分強硬——靜態 API 金鑰與共用服務帳戶密碼是「使用模型輔助的程式碼分析，攻擊者最先會找到的東西之一」*，即使在 Foundation 層級也不再可接受。

兩個半部：你是誰，以及如何證明#

Agent 身分驗證#

• Foundation — 每個 agent 實例都有獨一無二、以密碼學為根的識別碼（不只是標籤——「單獨的獨一無二識別碼只是標記工作」）；追蹤從建立→退役的生命週期；所有日誌與存取請求都包含 ID。密碼學根源正是讓不可否認性與抗身分偽造真正成立的關鍵。
• Enterprise — 使用 X.509 憑證並進行完整生命週期管理（輪替、撤銷）。
• Advanced — 在 HSM/TPM 中使用硬體支援的身分與遠端證明；對任何可從網際網路連線的 production 系統而言，這越來越被建議作為目標狀態。

服務驗證#

• Foundation — 從身分提供者取得短期、嚴格限縮範圍的 token（OAuth 2.0），有效期以分鐘計算，自動重新整理，絕不嵌入程式碼或設定檔。今天仍在使用、但會輪替的 API 金鑰是已知缺口，不是合理的 Foundation 姿態——輪替一個可被 grep 找到的憑證，並不會有意義地提高攻擊成本（見 Impossible, Not Tedious (Design Test)）。
• Enterprise — 使用具憑證釘選的雙向 TLS。
• Advanced — 使用具硬體綁定、並經證明後簽發的憑證，使憑證無法從遭入侵的主機外洩；這也適用於服務對服務呼叫。

憑證保護與範圍限制（Phase 6）#

• 憑證隔離 — 每個 agent 使用獨有憑證，因此竊取一組憑證不會授予攻擊者所有共用同一祕密之 agent 的合併存取權；在執行階段從祕密管理器（例如 HashiCorp Vault）注入，絕不放在程式碼或設定檔中。
• Just-in-Time (JIT) 存取 — 僅在需要的時刻授予權限，限制範圍並設定時間上限，自動撤銷；攻擊者找不到可快取後竊取的憑證。這套框架稱 JIT「非常強大，但不容易實作」——這是進階但非常強力的緩解措施。
• 基於屬性的存取控制（ABAC） — 在授予權限前評估身分、資源敏感度、動作、時間、位置與風險分數；對敏感記錄要求升級驗證，封鎖大量匯出。
• 硬體綁定的 2FA — 只要流程中有人類參與，就使用 FIDO2 / passkeys；SMS 驗證碼「達不到 Foundation 的門檻」。

為什麼這是關鍵基石#

身分是 Blast Radius (Agentic) 控制的前提（基於身分的隔離：服務只接受明確命名的呼叫者）、Least Agency 實施的前提（無法歸因的對象就無法限制範圍），也是可觀測性／可追蹤性的前提（事件期間依 agent 篩選稽核日誌）。這套框架指出，Claude Code 會為每個工作階段指派獨一無二的 session.id，並在所有遙測資料中以 account_uuid／organization.id 進行歸因；同時對 MCP 連線使用具自動重新整理功能的 OAuth 2.0。

第二個來源：IETF AIMS 標準提案#

以上是某家供應商的分級成熟度模型。AIMS（IETF draft-klrc-aiagent-auth-03，2026 年 7 月——Defakto/AWS/Zscaler/Ping/OpenAI/Okta）是這個基石控制的第一個標準軌、多供應商處理方式，並透過點名具體標準，讓抽象的層級變得具體。兩者都尚未批准（該電子書是供應商實務者的觀點；AIMS 是尚無 IETF WG 共識的個人提交），因此都不是已採用的標準——但它們在承重性的主張上相互一致，並在基本原語上出現具有啟發性的分歧：

共同點 — 靜態 API 金鑰不可接受／屬於反模式；憑證必須是短期的，並以密碼學方式綁定至識別碼；每個 agent 的身分是基石；最小範圍／最小權限；可觀測性是具防竄改稽核功能的安全控制。

差異 —

• *識別碼：*電子書表示「以密碼學為根的 ID → X.509 → 硬體支援」；AIMS 則點名具體原語——WIMSE 識別碼（URI），在實務上以 SPIFFE ID（spiffe://…）實現，並搭配 X.509-SVID 或 JWT/WIT-SVID 憑證。
• 硬體證明：電子書將硬體支援的身分＋遠端證明列為 Advanced 層級目標；AIMS 則讓硬體支援成為選用項——「互通性不要求硬體支援」——並將證明納入更廣泛、依部署而定的「姿態評估」**，在每次憑證簽發／輪替時執行（硬體證據只是 TEE 證據、軟體完整性量測、供應鏈來源、協調流程中繼資料等訊號之一）。
• *電子書未陳述的一項規則：*AIMS 要求LLM 絕不能持有憑證（由工作負載持有），正是為了讓提示注入無法外洩憑證——這是帶外參考監視器原則在身分層的對應版本（見 Agent Identity Management System (AIMS)）。

相關連結#

• Zero Trust for AI Agents — 控制領域 1；所有其他控制的基礎（樞紐）
• Agent Identity Management System (AIMS) — IETF AIMS 提案：同一基石的標準軌、多供應商第二來源，點名具體原語（WIMSE/SPIFFE 身分、短期姿態評估憑證、OAuth token 交換委派鏈）——上文詳述其與電子書的共同點與差異；該頁現在也涵蓋OpenID AuthZEN 授權草案（COAZ/AARP），這是補足本頁身分／驗證基石的授權切片（authn = 你是誰；AuthZEN authz = 是否允許呼叫）——由不同於 AIMS IETF 身分工作的組織（OpenID）標準化
• Least Agency — 沒有每個 agent 的獨立身分就無法實施（歸因缺口）
• Blast Radius (Agentic) — 基於身分的隔離與每個 agent 的憑證是主要控制措施
• Impossible, Not Tedious (Design Test) — 靜態金鑰輪替是失效的摩擦控制；短期＋硬體綁定憑證則通過測試
• Claude Code — 引用的參考：每個工作階段的身分、OAuth 2.0 MCP 驗證、作業系統憑證儲存區、apiKeyHelper
• MCP and Computer Use — MCP 連線是將身分提供者簽發的短期 token 應用於靜態金鑰之上的明確位置
• Autonomous Defense — 自動化事件回應（隔離、工作階段終止、憑證撤銷）透過此處定義的基於身分隔離與短期憑證來執行
• Capability Gating Is Not Authorization — 互補層：身分／驗證回答agent 是誰，每次呼叫的授權回答在該主體／工作階段情境中是否允許這次呼叫。ScopeGate 的 authz 階段會根據帶外政策，在「該主體與工作階段情境中」檢查引數值——這預設了本控制領域所建立的可歸因身分（無法歸因主體，就無法授權其呼叫）
• Off-Host, Identity-Bound Authorization — 身分綁定的粒度不同於本頁的基石：本控制將身分綁定至agent／工作負載，而 aiAuthZ（Kodathala，arXiv 2607.05518）則將每則人類訊息綁定至一個逐訊息的 HMAC-SHA256 簽章（nonce＋timestamp），並讓工具呼叫的權限來源於最近一次驗證的人類回合，「而不是模型讀過的文字，或長期存在的工作階段憑證」。這是讓權限無法由 agent 文字偽造的具體離機制——也是「如何針對遭操弄的 agent 驗證升權請求」的答案（Least Agency 的開放問題）：將其綁定至獨立信任領域中的密碼學身分，而非 agent 所聲稱的內容
• Foundation → Enterprise → Advanced: Is the Agent Access-Control Jump a Cliff? — 跨越身分、最小代理與爆炸半徑的 Foundation→Enterprise→Advanced 遷移路徑；回答下方的懸崖與中點開放問題

開放問題#

• 硬體綁定憑證假設 agent 執行的所有地方都有經證明的硬體，包括短暫的雲端工作負載與子 agent。對於「最多可擁有與父 agent 相同權限」的短期產生子 agent，證明如何運作？部分回答：AIMS 指定了憑證化與委派機制——產生的 agent 就是另一個取得自身 WIMSE/SPIFFE 識別碼與短期憑證的工作負載（SPIFFE 會為每張憑證配置短暫金鑰材料），在每次簽發時進行姿態評估，並透過 OAuth Token Exchange + Transaction Tokens + 跨網域身分鏈結，以縮減範圍的方式取得父 agent 的權限——也就是委派、以交易綁定的 token，而不是直接繼承父 agent 的憑證（比「與父 agent 相同權限」更強的答案）。然而，AIMS 對具體的硬體證明問題採取的是化解而非解決：它讓硬體支援成為選用項，並以依部署而定的姿態訊號取代每個子 agent 的硬體證明，因此硬體遠端證明如何流向只存活數秒的子 agent 仍未獲解答（AIMS 認為不需要這麼做）。

已解決問題#

• JIT＋ABAC 都被標為「進階、不容易實作」。Foundation 的靜態角色與 Advanced 的 JIT 之間，是否存在務實的 Enterprise 層級中點，還是這個落差如懸崖般陡峭？已回答：Foundation → Enterprise → Advanced: Is the Agent Access-Control Jump a Cliff? — 不是懸崖；Enterprise 層級（ABAC＋帶回基準權限的動態權限提升＋mTLS＋沙箱）就是刻意設計的中點，而將 ABAC 描述為「進階」是來源中的不一致（在層級表中它位於 Enterprise）。子 agent 的證明仍是開放問題。

資料來源#

• Zero Trust for AI Agents — 第 III 部分身分／驗證＋存取控制層級；第 IV 部分 Phase 3 與 6
• AI Agent Authentication and Authorization — IETF draft-klrc-aiagent-auth-03（個人提交，無 WG 共識）：WIMSE/SPIFFE 識別碼（§6）、短期姿態評估憑證＋LLM 永不持有憑證（§7–8）、mTLS／應用程式層驗證（§9）、OAuth 委派＋交易 token／跨網域委派鏈（§10）