AI Agent 的數位身份證：為什麼我們需要為每個 Agent 設計獨立的權限邊界

企業 Agent 若共用服務帳號，權限、責任與稽核軌跡就會被混在一起，最小權限只是口號。每個可執行行動的 Agent 都應有獨立身份、短期憑證與可撤銷授權，讓系統能回答誰在何時、依何種政策存取了哪項資源。

為什麼共享服務帳號是 Agent 時代的技術債？

在過去，我們習慣為應用程式或服務建立「服務帳號」（Service Account）或「服務主體」（Service Principal），讓它們能存取必要的資源。這種模式在單體應用或微服務架構中運作尚可，但一旦套用到由大量、動態、可能由不同團隊開發的 AI Agent 組成的系統時，就會立刻捉襟見肘。

想像一下，如果我們讓所有處理訂單的 Agent 共用一個名為 order_processing_agent 的帳號，這個帳號擁有讀取客戶資料庫、寫入訂單系統、呼叫物流 API 的所有權限。當其中一個 Agent 因為程式碼漏洞或惡意提示（prompt injection）而行為異常時，我們將面臨幾個嚴峻的問題：

• 責任歸屬不清：我們無法從日誌（log）中分辨是哪一個具體的 Agent 實例（instance）執行了惡意操作。所有的行為都來自同一個身份。
• 權限過於寬鬆：某個 Agent 的任務可能只是查詢訂單狀態，但它卻繼承了整個共享帳號的寫入與修改權限，違反了最小權限原則（Principle of Least Privilege）。
• 撤銷困難：一旦金鑰洩漏，我們必須立即更新所有使用該金鑰的 Agent，這在一個動態擴展的系統中幾乎是不可能的任務，而且會造成服務中斷。

這種做法就像是發給公司所有員工同一張萬能門禁卡，不僅危險，也讓精細化的管理與審計成為空談。Agent 的自主性越高，其潛在的破壞力就越大，沿用這種粗糙的權限管理模式，是在累積未來必然會引爆的技術債。

Entra Agent ID 如何實作最小權限原則？

那麼，理想的作法是什麼？答案是：將每個 Agent 視為一個獨立的數位身份，並對其進行細粒度的權限控管。最近，日本技術顧問公司 Headwaters 發表的一篇技術驗證文章，就具體展示了如何使用 Microsoft 的 Entra Agent ID 來實現這個目標。

在這項實驗中，研究人員為一個 AI Agent 建立了一個專屬的 Entra Agent ID，並測試它在不同 Azure 角色型存取控制（RBAC）設定下，對 Azure Blob Storage 的存取權限。他們驗證了幾個關鍵場景：

1. 當 Agent ID 被授予「儲存體 Blob 資料讀取者」（Storage Blob Data Reader）角色時，它能成功讀取 Blob 內容，但任何寫入或刪除操作都會被拒絕。
2. 當角色升級為「儲存體 Blob 資料參與者」（Storage Blob Data Contributor）時，Agent 便能成功執行寫入操作。

這個看似簡單的實驗，其背後的意義十分深遠。它證明了我們可以像管理人類員工帳號一樣，精確地管理每一個 Agent 的權限。更重要的是，他們透過 DefaultAzureCredential 的方式進行認證，這意味著整個過程無需在程式碼或環境變數中儲存任何靜態的密碼或金鑰，大幅降低了憑證洩漏的風險。

將 Agent 視為一個臨時的、被賦予特定任務的「數位員工」，而不是一個永久的、高權限的「系統服務」，是思維上最大的轉變。

建立 Runtime Trust Boundary 的四個支柱

從 Entra Agent ID 的實踐延伸出來，我認為一個真正安全、可治理的企業級 Agent 系統，其權限設計必須建立在四個支柱之上，共同構成一道道在執行期間（runtime）動態生成的信任邊界（Trust Boundary）。這與傳統基於網路邊界的靜態防禦不同，它是一種更符合 零信任架構（Zero Trust Architecture）精神的作法。

• 獨立身份（Independent Identity）：每個可獨立行動的 Agent 都必須擁有一個唯一的、可識別的身份。這個身份是所有權限、審計和追蹤的錨點。
• 最小權限（Least Privilege）：每個 Agent 的身份在特定時間、特定任務中，只應被授予完成該任務所需的最小權限集合。任務結束後，權限應被回收或降級。
• 可撤銷憑證（Revocable Credentials）：身份憑證（如 token）必須是短期的、可動態簽發且可隨時撤銷的。理想情況下，應該採用像 Azure Managed Identities 這樣的機制，由平台自動管理憑證的生命週期。
• 可追溯的授權證據（Auditable Authorization Evidence）：每一次 Agent 存取資源的行為，都必須留下清晰的審計日誌。日誌中必須明確記錄是「哪個 Agent」（Who）、「在何時」（When）、「對哪個資源」（What）、「執行了什麼操作」（Action），以及「授權依據為何」（Why）。這對於事後的問題排查與合規性審查至關重要。

隨著 AI Agent 在企業內部扮演的角色越來越關鍵，我們不能再用舊時代的思維來管理這些新型態的「數位員工」。為每一個 Agent 建立獨立的數位身份，並以此為基礎設計一套細粒度的權限管理與審計機制，不僅是技術上的最佳實踐，更是企業在 AI 時代建立數位信任與治理能力的基石。這需要我們從系統設計之初就將身份與權限視為一等公民，而非事後補救的附加功能。這方面的挑戰與機會，正如許多學術研究所指出的，將是未來幾年 AI 安全領域的核心議題。

深入探索：推薦閱讀

• Entra Agent IDでAzureリソースに認証・アクセスする (Headwaters)
• NIST Special Publication 800-207: Zero Trust Architecture
• What are managed identities for Azure resources? (Microsoft Learn)
• A Survey on Large Language Model (LLM) Security and Privacy: The Good, the Bad, and the Ugly

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。