Foundation → Enterprise → Advanced：代理程式存取控制的躍升是懸崖嗎？

資料來源#

Zero Trust for AI Agents

答案#

**這不是懸崖。Enterprise 層級是務實的中間點，而引發這個問題的未解之問（Agent Identity and Authentication：「從 Foundation 靜態角色到 Advanced JIT 的差距是懸崖嗎？」）是建立在對這套階梯的誤讀上。**它把 Enterprise 層級的兩種不同控制（ABAC、動態權限提升）與 Advanced 層級的兩種不同控制（持續授權、JIT/JEA）混為一談。Zero Trust for AI Agents 架構明確設計各層級，讓「每一層都建立在前一層之上」——升級代表加強，而非取代——並在靜態角色與 JIT 之間設置完整的中間階梯（Zero Trust for AI Agents 第三部分）。

真正困難、難以實作的控制（JIT/JEA、逐動作持續授權、硬體證明）屬於 Advanced。但組織不必從 Foundation 一躍而至。它會先經過 Enterprise 層級，以相當低的實作成本，大幅縮小爆炸半徑。

依三個概念來看這套階梯#

問題中提到的三個概念並非平行關係，而是 輸入 → 身分 → 結果：Least Agency 是輸入控制（哪些動作可執行）；Agent Identity and Authentication 是讓一切得以強制執行的關鍵支柱（無法歸屬身分的對象，就無從設定範圍——這就是「歸屬缺口」）；Blast Radius (Agentic) 則是結果指標（遭入侵的代理程式能接觸到多少資源）。三者都依相同的三個層級來規範：

控制面	Foundation	Enterprise（中間點）	Advanced
身分（Agent Identity and Authentication）	所有日誌使用以密碼學為根基的個別代理程式 ID	具備輪替／撤銷生命週期的 X.509 憑證	硬體支援的身分（HSM/TPM）+ 遠端證明
服務驗證（Agent Identity and Authentication）	短效 IdP 簽發權杖（OAuth 2.0，有效期以分鐘計）	具備憑證釘選的相互 TLS	硬體綁定憑證、經證明的簽發
權限模型（Least Agency）	RBAC + 預設拒絕	具備情境感知政策的 ABAC	每次動作都重新評估的持續授權
權限範圍（Least Agency）	靜態最小權限角色	依任務動態提升 → 返回基準狀態	JIT / JEA 與自動到期
隔離（Blast Radius (Agentic)）	依身分隔離（服務只接受具名呼叫者）	沙箱執行（容器、gVisor 系統呼叫過濾）	硬體隔離（AMD SEV / Intel TDX、microVM）

來源：Zero Trust for AI Agents 第三部分的層級表（存取控制見第 218、232–235 行；身分／驗證與隔離層級則是依三篇概念文章整理）。

Enterprise 欄是一種完整且可部署的安全態勢，不是尚未完成的 Advanced 版本。架構本身的比喻，具體說明了這個中間點：動態權限提升「類似作業系統提示輸入管理員密碼，之後再回復標準權限」（Zero Trust for AI Agents 第 235 行）。這是多數組織已在人員管理上採用、廣為人知的模式；延伸到代理程式是工程任務，而非研究問題。JIT/JEA 只是「更進一步，在任務完成時自動撤銷提升的權限」——模式相同，只是把常駐存取的時間窗壓到零。

指出來源中的一處矛盾#

這套架構對 ABAC 所屬層級的說法前後不一。存取控制層級的表格把 ABAC 列在 Enterprise（Zero Trust for AI Agents 第 218 行）。但 Phase-6 憑證保護的Pro-tip 卻把 ABAC 和 JIT 一起稱為「另一種進階實作」（第 591 行），而 Agent Identity and Authentication 的未解問題也沿用了「進階、難以實作」的說法。

兩種解讀都有道理，差異也確實存在：基本型 ABAC（少數幾個屬性——資料敏感度、一天中的時間、粗略的風險標記——用來控制讀取或要求升級驗證）屬於 Enterprise 等級的工作；豐富型 ABAC（逐動作風險評分、阻擋大量匯出、將行為基準屬性送入政策引擎）則偏向 Advanced，因為它仰賴行為基準，而行為基準本身就是 Enterprise→Advanced 的控制（第 299 行：基準成為「以行為屬性為基礎的 ABAC 存取控制屬性」）。解決方式是：ABAC 是一個光譜，表格所列的 Enterprise 指的是入門形式。這也正是 Impossible, Not Tedious (Design Test) 提醒的問題——控制只有在讓壞事不可能發生時才算數，而非只是讓它麻煩；因此，攻擊者可以等到非上班時間、或在速率限制內緩慢外傳資料來規避的象徵性 ABAC 政策，還稱不上 Enterprise 等級的防護。

遷移路徑#

既然身分是關鍵支柱，推進順序就不是「先完成所有 Foundation，再完成所有 Enterprise」，而是先深入建置身分，再擴展代理權與隔離措施：

**階段 0 — 建立關鍵支柱（Foundation 身分）。**先淘汰靜態 API 金鑰和共用服務帳戶——架構指出，這些「即使在 Foundation 層級也已不可接受」，因為它們是「攻擊者使用模型輔助的程式碼分析時，最先會找到的項目之一」（Agent Identity and Authentication、Zero Trust for AI Agents 第 197 行）。發行以密碼學為根基的個別代理程式 ID 和短效 IdP 權杖。在完成這一步之前，後續控制都無法強制執行：Least Agency 若缺乏身分歸屬就無法落實，而透過依身分隔離來控制 Blast Radius (Agentic)，也需要具名呼叫者。

**階段 1 — Foundation 代理權與隔離。**建立身分後，採用 RBAC + 預設拒絕（Least Agency），並在身分層級隔離服務，讓「每項服務只接受明確列名呼叫者的連線」（Blast Radius (Agentic)）。執行 Phase-3 爆炸半徑評估：列出核准動作、禁止動作、升級觸發條件與範圍限制，再檢視遭入侵時可觸及哪些資源。優先採用能移除能力的控制，而非只會限流的控制（Impossible, Not Tedious (Design Test)）。

**階段 2 — Enterprise 中間點（回答「這是懸崖嗎？」）。**這就是問題假設不存在的那一階：

身分 → X.509 生命週期；服務驗證 → mTLS 與憑證釘選。
權限模型 → 入門型 ABAC：依資料敏感度和情境控制讀取或要求升級驗證。
權限範圍 → 動態提升並返回基準狀態（作業系統管理員密碼模式）。這是效益最高的單一措施：不用 JIT 的自動到期機制，就能消除常駐的提升權限。
隔離 → 任何處理不受信任輸入的代理程式都必須採用強制沙箱（容器、gVisor）——架構稱其為「強制要求，而非理想目標」（Blast Radius (Agentic)）。
建置自動化基準學習，為異常偵測和更豐富的 ABAC 提供參考依據（Zero Trust for AI Agents 第 296 行）。

**階段 3 — 只有在威脅模型要求時才採用 Advanced。**硬體支援的身分與證明、硬體綁定憑證、JIT/JEA、逐動作持續授權、硬體隔離。架構明確指出，這個層級對「多數組織而言是理想目標」，只有國家安全或受到嚴格監管的部署才以此為基準——「多數組織會發現 Enterprise 控制已符合其風險承受度」（Zero Trust for AI Agents 第 169、175 行）。

中間點仍未解決的兩個缺口#

**權限提升流程本身就是攻擊面。**動態權限提升（Enterprise）會重新引入權限提升請求，而遭操縱的代理程式（Agentic Prompt Injection）可能發出此請求。架構沒有說明如何針對代理程式本身驗證權限提升請求；升級驗證假設有人在迴圈中（FIDO2／通行金鑰），對全自動權限提升行不通。這是最小代理權仍未解決的未解問題，中間點無法解決。（未解：Least Agency。）
**子代理程式證明。**衍生出的子代理程式會繼承「最多與父代理程式相同的權限」。硬體證明（Advanced）假設代理程式執行的所有地方都有經證明的硬體，包括短暫的雲端工作負載和短效子代理程式；但架構沒有說明如何將證明傳遞給只存在數秒的子代理程式。（未解：Agent Identity and Authentication。）

結論#

這裡沒有懸崖。架構刻意在 Foundation 靜態角色與 Advanced JIT/JEA 之間設置 Enterprise 層級——ABAC、動態權限提升並返回基準狀態、mTLS、沙箱——並明確指出多數組織應在 Enterprise 停下。最重要的一步不是達到 JIT，而是淘汰靜態憑證和常駐的提升權限——Enterprise 中間點能做到這些，同時不必承擔 JIT 自動到期或持續授權的實作成本。「Enterprise 將成為 Foundation」這項預測代表今天的中間點就是明日的入門門檻，因此現在建置 X.509 + mTLS + 動態權限提升 + 沙箱這套組合，是長遠可靠的選擇。