身分生命週期管理（Identity Lifecycle Management, ILM）是企業安全的核心，但目前大多數公司的實作方式是為「人類」設計的。當 AI Agent（AI 代理，指能自主執行任務、調用 API 的 AI 實體）大規模進入企業環境時，傳統的治理模型會出現嚴重的結構性盲點。
對於剛接觸企業級權限管理的工程師來說，首先要理解的是傳統 ILM 的運作邏輯。
傳統的身分治理邏輯：以 HR 為核心
傳統的 IGA（Identity Governance and Administration，身分治理與管理）工具建立在一個基本假設上：每一個身分都對應到一個真實的人。這個人的權限變動是由 HR 系統（如 Workday 或 SAP）驅動的事件觸發。
這種模式被稱為 Joiner-Mover-Leaver（入職、調職、離職）模型。當新員工入職（Joiner）時，HR 記錄觸發帳號創建與權限分配；當員工調職（Mover）時，屬性更新會觸發權限重新計算；當員工離職（Leaver）時，HR 終止事件會觸發所有系統的權限回收。
這套系統之所以強大，是因為它具有確定性。權限與組織事實（職位、部門、主管）直接掛鉤，且每一步都有審計日誌可循，符合 SOX 或 HIPAA 等合規要求。
AI Agent 為何讓這套模型崩潰
AI Agent 不是透過 HR 系統入職的。它們由工程師透過配置檔案、API 調用或編排框架（如 LangChain 或 AWS Bedrock Agents）直接部署到生產環境。這導致了三個核心治理失效：
第一，缺乏權威來源與入口控制。 人類入職有 HR 流程，但 AI Agent 的誕生可能只是一個 Terraform 指令或一次 API 呼叫。這意味著 IGA 平台根本不知道這個身分何時被創建，也沒有經過任何主管審核就直接擁有了 API 金鑰或 OAuth 令牌。
第二，動態權限範圍與固定角色的衝突。 傳統的 RBAC（Role-Based Access Control，基於角色的存取控制）假設職能是可預測的。但 AI Agent 的行為是目標導向的，它可能會在運行時透過 Tool-calling（工具調用）或 RAG（檢索增強生成）模式，嘗試訪問原本未被明確授權的 API 或儲存系統。其權限範圍在運行時會動態擴展，而傳統 ILM 只能處理靜態的權限分配。
第三，多環境實例化與分身問題。 人類身分在同一時間只能在一個地方，但一個 AI Agent 可以同時在多個雲端環境或容器中運行數十個實例。在多代理架構中，主代理還會衍生出子代理並委派權限。傳統 IGA 無法追蹤這種動態分叉與合併的權限圖譜。
實務上的三大安全風險
如果繼續用管理人類的方式管理 AI Agent，會產生以下具體風險：
過度授權成為常態。 開發者為了確保 AI Agent 能順利完成任務，傾向於賦予寬泛的權限（例如使用通配符 *）。由於缺乏入職審核流程，Agent 從第一天起就處於過度授權狀態。
權限審查形同虛設。 傳統的定期權限審查依賴於「主管」確認。但 AI Agent 沒有主管，其所有者通常是一個開發團隊。審查者看到的往往是創建時的靜態權限，而非 Agent 在運行時實際累計的行為權限，導致審查結果在操作層面毫無意義。
幽靈憑證殘留。 當一個 AI 專案被廢棄或工作流被刪除時，不會觸發 HR 的離職事件。這導致 API 金鑰、服務帳號或 OAuth 授權在秘密管理工具（Secrets Manager）中永久生效。這些失去所有者且無人監控的長效憑證，是攻擊者最理想的入侵路徑。
如何構建適用於 AI Agent 的新治理模型
要解決這個問題，不能強行將 AI Agent 塞進 HR 流程，而必須根據其運作特性重建治理邏輯：
自動化全表面發現。 不能依賴申報，而必須透過工具持續掃描雲端 IAM 策略、Kubernetes 服務帳號、OAuth 註冊表以及 CI/CD 流水線，即時掌握所有非人類身分的清單。
建立基於行為的屬性模型。 捨棄部門、職稱等人類屬性，改用：負責團隊、運作目的、授權 API 列表、部署時間戳以及預期生命週期。
以行為監控取代定期審查。 AI Agent 的變動太快，季度審查太慢。應導入持續行為監控，將「觀察到的訪問模式」作為治理輸入。當 Agent 調用的 API 偏離其定義的功能範圍時，應立即觸發治理事件，而非等待下次審查。
基於運作狀態的自動回收。 建立與憑證使用日誌掛鉤的回收機制。例如，若某個 API 金鑰在定義的時間窗內沒有任何請求，則自動標記為失效並觸發撤銷流程，將生命週期終點與實際運作狀態同步。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。