Agent 身分識別與驗證

資料來源#

• Zero Trust for AI Agents

摘要#

身分識別與驗證構成了 Zero Trust for AI Agents 中所有其他安全性能力的基礎：沒有可驗證的身分，就無法強制執行存取控制、維護稽核追蹤或對動作進行歸因。如果沒有獨立的身分，agent 就會運作於*「歸因缺口」之中，在此情況下，強制執行 Least Agency 將變得不可能。該框架的立場非常激進——靜態 API 金鑰和共享的服務帳戶密碼是「攻擊者利用模型輔助程式碼分析時最先發現的東西之一」*，且即便在基礎層級也已不再被接受。

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

Agent 身分驗證#

• 基礎 — 每個 agent 實例都擁有獨特的以密碼學為根的識別碼（而不僅僅是標籤——「僅有獨特識別碼只是標籤工作」）；追蹤從建立到停用的完整生命週期；所有日誌和存取請求中都包含識別碼。以密碼學為根是實現不可否認性與防身分偽造的關鍵。
• 企業 — 具備完整生命週期管理（輪替、撤銷）的 X.509 憑證。
• 進階 — 位於 HSM/TPM 中並具備 remote attestation 的硬體支援身分；對於任何可從網際網路存取的生產系統，這已日益被推薦為目標狀態。

服務驗證#

• 基礎 — 來自身分識別提供者的短期、窄範圍權杖（OAuth 2.0），在幾分鐘內過期、自動重新整理，且絕不嵌入在程式碼或設定檔中。目前使用具備輪替功能的長效 API 金鑰是已知缺口，而非合理的基礎層級姿態——輪替可被檢索的憑證並不會顯著增加攻擊成本（參見 Impossible, Not Tedious (Design Test)）。
• 企業 — 具備憑證釘選的 mutual TLS。
• 進階 — 具備 attested 核發的 hardware-bound credentials，使憑證無法從受侵害的主機中外洩；這同樣適用於服務對服務（service-to-service）的呼叫。

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

• 憑證隔離 — 每 agent 獨立的唯一憑證，如此一來，單一憑證遭竊取時，不會授予所有共享該私鑰的 agent 的合併存取權限；於執行期從機密管理器（例如 HashiCorp Vault）注入，絕不放在程式碼或設定檔中。
• Just-in-Time (JIT) 存取 — 僅在需要時授予權限，限制範圍與時間，且自動撤銷；如此一來，攻擊者就找不到可竊取的快取憑證。該框架稱 JIT 「非常強大，但不易實作」——這是一項進階但非常強的緩解措施。
• 屬性型存取控制 (ABAC) — 在授權前評估身分、資源敏感度、動作、時間、位置及風險評分；針對敏感記錄進行 step-up auth，並封鎖批次匯出。
• 硬體綁定 2FA — 只要有人類參與流程，就使用 FIDO2 / passkeys；SMS 簡碼「不符合基礎層級標準」。

為什麼這是基石#

身分是 Blast Radius (Agentic) 圍堵（以身分為基礎的隔離：服務僅接受明確命名的呼叫者）的先決條件，也是強制執行 Least Agency（你無法限制無法歸因的範圍）的先決條件，更是可觀測性／可追溯性（在事件期間依 agent 篩選稽核日誌）的先決條件。該框架指出，Claude Code 在所有遙測數據上都分配了獨特的 session.id，並帶有 account_uuid/organization.id 歸因，且針對 MCP 連線使用具備自動重新整理功能的 OAuth 2.0。

相關連結#

• Zero Trust for AI Agents — 控制網域 1；所有其他控制措施的基礎（樞紐）
• Least Agency — 若無各別獨立的每 agent 身分便無法強制執行（歸因缺口）
• Blast Radius (Agentic) — 以身分為基礎的隔離與每 agent 憑證是主要的圍堵控制措施
• Impossible, Not Tedious (Design Test) — 靜態金鑰輪替是一種會失效的摩擦控制；短期 + hardware-bound credentials 則能通過測試
• Claude Code — 引用的參考實作：每 session 身分、OAuth 2.0 MCP 驗證、作業系統憑證存放區、apiKeyHelper
• MCP and Computer Use — MCP 連線是套用由 IdP 核發的短期權杖以取代靜態金鑰的具體場景
• Autonomous Defense — 自動化事件回應（隔離、工作階段終止、憑證撤銷）是透過此處定義的以身分為基礎的隔離與短期憑證來執行的
• Foundation → Enterprise → Advanced: Is the Agent Access-Control Jump a Cliff? — 橫跨身分、least-agency 與 blast-radius 的 基礎→企業→進階 遷移路徑；回答了下方的「懸崖對決中間點」開放問題

開放問題#

• hardware-bound credentials 假設在 agent 運行的所有地方都有經證實（attested）的硬體，包括暫時性的雲端工作負載和子 agent。對於生命週期短暫、且「最高擁有與父 agent 相同權限」的產生子 agent，attestation 如何運作？
• JIT 與 ABAC 皆被標記為「進階，不易實作」。是否存在一個務實的企業層級中間點，還是從基礎層級的靜態角色到進階 JIT 之間的差距是一個懸崖？ 已解答：Foundation → Enterprise → Advanced: Is the Agent Access-Control Jump a Cliff? — 並非懸崖；企業層級（ABAC + 具返回基準點的動態權限提升 + mTLS + 沙箱化）是刻意設計的中間點，而 ABAC 被框定為「進階」是資料來源的不一致之處（它在層級表中位於企業層級）。子 agent 的 attestation 仍然懸而未決。

資料來源#

• Zero Trust for AI Agents — 第三部分身分識別與驗證 + 存取控制層級；第四部分階段 3 與 6