背景
隨著企業開始讓 AI Agent（人工智慧代理）在內部系統中執行任務，身分與存取管理（Identity and Access Management，IAM）面臨了一個全新類型的管理對象。根據 The Hacker News 刊載的技術分析文章，AI Agent 會以被委派的權限進行身分驗證、呼叫工具，並在多個企業系統之間執行動作，因此必須被視為一種「非人類身分」來治理：每個 Agent 都應該有明確的人類負責人、定義清楚的用途、限定範圍的授權、到期時間，以及持續的監控機制。
問題的核心在於架構層面的落差。傳統 IAM 平台描述的是「預期的存取」，也就是帳號開通了什麼權限、套用了什麼政策；但應用程式與基礎設施呈現的才是 Agent「實際執行了什麼」。兩者之間存在一塊被稱為「身分暗物質」（identity dark matter）的灰色地帶，包含未登錄的 Agent、散落各處的憑證、應用程式本地帳號，以及中央身分資料從未回報的驗證路徑。如果管理框架看不見這一層，產出的就只是政策意圖，而非真正的安全保證。
傳統 IAM 為何力有未逮
傳統 IAM 系統主要運作在兩個維度：設計階段的生命週期管理、政策定義、帳號開通與入離職異動流程，以及執行階段的單一登入（SSO）與應用程式邊界的存取檢查。這兩者描述的都是「設定好的存取」，而不是 Agent 進入系統後「實際做了什麼」。
人類使用者通常遵循可預測的任務路徑，但 Agent 會串連任務、動態選擇工具，組合出沒有任何權限審查預料到的行為。OWASP 針對大型語言模型應用程式公布的 Top 10 風險清單，將這種失敗模式直接命名為「過度代理」（excessive agency，編號 LLM06）：當 Agent 被授予過廣的功能、權限或自主權時，會執行超出核准任務範圍的動作。靜態的角色指派無法限制這種行為，設定審查也無法衡量它。同時要留意的是，設定錯誤不等於可立即被利用，真正的暴露程度取決於實際綁定在 Agent 身分上的權限、其執行環境可觸及的系統，以及運行時的條件。
核心內容
AI Agent 身分框架的組成可分為三層：確認 Agent 是誰、限制它能做什麼、證明它做了什麼。
在身分與憑證管理層面，每個 Agent 都需要獨立且可歸屬的身分，不能共用服務帳號，也不能借用人類憑證，因為歸屬是所有下游控制的前提。憑證設計應偏好工作負載身分聯合（workload identity federation）與短效、自動輪替的憑證，避免使用內嵌的長期金鑰。當 Agent 代表使用者行動時，OAuth 2.0 Token Exchange（RFC 8693）提供了委派與模擬的語意，能保留「Agent 自身身分」與「被借用的權限」之間的區別。
授權層面，NIST SP 800-53 第五版中的存取控制家族可直接適用於 Agent 身分，包括最小權限原則（AC-6）與職務分離（AC-5），但執行點必須比登入閘道更靠近實際動作。具體做法包括任務範圍授權（權限隨特定任務核發並隨之失效）、工具白名單、資料存取邊界（防止 Agent 對被操縱的資料採取行動），以及高風險操作需人工核准或第二重授權的動作門檻。
監控層面，可稽核性必須建立在行為遙測上，而非僅靠日誌。MITRE ATT&CK 中收錄的有效帳號濫用（T1078）與權限提升技術，產生的都是外觀正常的驗證紀錄，因為憑證本身合法。偵測的關鍵在於比對 Agent 的預期任務與其跨應用程式的實際執行，並在兩者偏離時能撤銷委派權限。
技術脈絡解讀
文章以幾個情境說明這個落差為何重要。一個跨 CRM、工單系統與內部知識庫運作的營運 Agent，在身分提供者眼中每天只有幾次正常登入，看似治理良好；但應用層遙測卻顯示它正在查詢客戶紀錄、匯出資料並修改權限。採購 Agent 的例子更精確：其核准任務是查詢供應商報價，被授予的卻是整個採購 API 的權限範圍，而實際執行時可能自行推導出「發起採購單」的動作。意圖、權限與執行是三份不同的產出物，只有第三份描述真實發生的事。持有基礎設施控制面身分的程式部署 Agent 風險更高，因為自動化憑證通常權限寬廣，一旦遭入侵，攻擊者可重塑環境甚至癱瘓偵測機制。
影響與限制
在導入策略上，文章建議以「擴充、自建、採購」三者並行評估。對已建置身分治理計畫的企業，擴充現有 IAM 平台是合理起點，SailPoint 與 Saviynt 等治理平台已推出非人類與 Agent 身分相關功能，但功能覆蓋範圍隨版本變動，需對照最新文件驗證。自建適合授權必須嵌入執行環境的場景，採購則補上治理平台通常不提供的層面：從應用程式與基礎設施直接發現 Agent 身分，並驗證執行結果是否符合意圖。評估框架時應檢視擁有權模型、憑證架構、委派授權、發現覆蓋率、執行期遙測、執行觸及範圍與稽核證據品質七個面向，其中撤銷速度與證據品質最常被忽略。
治理成熟度可分三階段：先以靜態帳號與角色治理建立盤點與定期審查，再進入以部署與退役事件觸發開通、憑證輪替與撤銷的事件驅動治理，最終達到持續身分可觀測性，能跨系統觀察 Agent 行為並產出遙測佐證的稽核證據。文中提到的 Orchid Security 即定位在第三階段，從應用與基礎設施直接發現身分，補足既有 IAM 平台的驗證與修復層。
展望未來，當 Agent 開始彼此委派任務時，權限會沿著沒有人逐步核准的鏈條傳遞，機器可讀政策、可驗證 Agent 憑證與受限委派的標準化工作正在推進，但跨框架互通性尚未定案，且持續授權機制只有在行為訊號存在時才有效。治理要求始終不變：鏈上的每一環都需要身分、範圍、到期時間，以及最終負責的人。需要提醒的是，本文部分內容為合作廠商供稿，其中產品定位與案例屬示意性質，實際覆蓋能力取決於所連接的應用與基礎設施範圍，企業評估時仍應以自身環境驗證為準。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。