Entro Security 2026 年的研究顯示，在雲原生的企業環境中，非人類身分（non-human identity）的數量已達到真人身分的 144 倍，而 2024 年上半年這個比例還只是 92 比 1。然而，香港大多數企業的身分治理制度，至今仍然是為真人而設計的。
這個落差，正是企業 AI 最安靜的失效點。董事會批准了會代表公司下單、審批、對帳、發信的 AI 代理，卻沒有人批准過一套方法，去分辨哪一個代理做了哪一件事。
什麼是 Agent Identity（代理身分）？
Agent Identity 是指為每一個 AI 代理發出獨立的可驗證憑證、獨立的權限範圍，以及一條完整的授權鏈，用以記錄是哪一位員工授權了哪一項操作。它要回答事故覆核時的三個問題：哪個代理行動、代表誰行動、依據什麼權限。
缺少這一層，代理的行為在你的日誌中，只會顯示為它所借用的那把共用 API 金鑰。行為是真實的，問責卻是虛的。
這個概念在 2026 年進入企業詞彙，原因十分實際。過去的身分平台只需回答「這個人是否本人」，如今卻要回答「這個代理的行動，是否仍在某個人真正授予的權限之內」。這是完全不同的問題，失效方式也完全不同。
雲端安全聯盟（Cloud Security Alliance）2026 年關於非人類身分治理的研究，描述了同一個缺口：代理正在以非人類身分的形式配置權限、觸發流程、與企業系統互動，而管理它們的控制措施，卻是為靜態機器帳戶而寫的。
Agent Identity 與服務帳戶有何不同？
服務帳戶擁有固定的身分與固定的權限範圍，不論執行什麼任務，權限都一樣。AI 代理則是每項任務的權限範圍都不同，在不同時間代表不同的人，經由不同的授權鏈行事。把代理當成服務帳戶處理，等於一次過把它可能用到的所有權限全部給它。
一句話說清楚兩者的分別
--- 服務帳戶問的是：這個系統獲准做什麼？
--- 代理身分問的是：這個代理，在此刻，為這一個人，執行這一項任務時，獲准做什麼？
一個代理若在早上九時為財務主管核對發票，下午兩時又為採購部草擬供應商電郵，它不應該同時持有兩套權限。但在服務帳戶模式下，它就是同時持有。
一家典型企業究竟有多少非人類身分？
根據 Entro Security 2026 年的研究，全企業環境中非人類身分與真人身分的平均比例接近 45 比 1，在雲原生架構中更升至 144 比 1。以一家 300 人的香港公司計算，即代表在部署第一個 AI 代理之前，已有約 13,500 組機器憑證在流通。
Gartner 預測，到 2026 年底，將有 40% 的企業應用程式整合特定任務的 AI 代理，而該預測發布時這個比例還不足 5%。
推動這個數字的，是兩股結構性力量。雲端採用與微服務拆分，都會令單一業務流程所需的憑證數量倍增；而你批准的每一個 SaaS 整合，都自帶一套憑證。
Gartner 進一步預測，到 2028 年，財富 500 強企業平均將運行超過 15 萬個代理，而 2025 年這個數字還不足 15 個。曲線並非線性，底下的憑證擴散同樣不是。
治理信心的落差與增長同步。2026 年的業界調查顯示，只有約十分之一點五的企業對自己保護非人類身分的能力有高度信心，而在真人身分方面，這個比例接近四分之一。
香港私隱專員公署對代理式 AI 有何說法？
2026 年 3 月，個人資料私隱專員公署發出專門警示，將代理式 AI 視為一個獨立且升級的私隱風險類別，理由是代理獲授予前所未有的存取權與自主性，而相關保安控制尚未經過大規模實測。公署在 2026 年 5 月完成的循規審查涵蓋 60 家香港機構，發現 95% 已在日常運作中使用 AI，超過一半更同時運行三個或以上的 AI 系統。
公署的關注非常具體：代理可能觸及本地裝置、檔案、電郵、憑證、瀏覽器內容以至外部服務，然後在沒有真人即時參與的情況下，自主執行多步驟任務。
該輪審查並未發現違反《個人資料（私隱）條例》的個案，公署提出的建議是建立治理架構、進行私隱影響評估與 AI 審計、加強員工培訓，以及制訂事故應變計劃。這是監管機構在執法行動之前，先把缺口說清楚。
如何用四個步驟建立代理身分框架？
可行的框架有四步：盤點每一個代理及其目前使用的憑證、為每個代理發出獨立憑證、按任務而非按代理劃分權限，以及記錄授權鏈，使每項操作都能追溯至授權的真人。大多數企業可在一個季度內完成頭兩步。
第一步：先盤點，後治理
列出所有在生產環境運行的代理，包括業務部門未通知 IT 就自行部署的那些。逐一記錄它所使用的憑證，以及該憑證是否與其他系統共用。共用憑證，就是你最高嚴重性的發現。
第二步：發出獨立憑證
每個代理獲得屬於自己的身分。2026 年常見的做法包括帶自訂聲明的 JWT 權杖、由企業 PKI 簽發的 mTLS 客戶端證書，或雲端供應商的受管身分。Model Context Protocol 規範要求受保護的 HTTP 部署使用 OAuth 2.1 與 PKCE，為整合團隊提供了一個站得住腳的預設做法。
第三步：按任務劃分，而非按代理劃分
權限應附著於代理正在執行的任務，以及授權它的那個人，而不是附著於代理這個長期存在的實體。這一步是最多企業略過的一步，也正是限制事故波及範圍的關鍵。
第四步：記錄授權鏈
每一條操作日誌都應包含代理名稱、授權人、任務範圍與時間戳。如果你的審計軌跡答不出「是誰叫它這樣做」，那你其實沒有審計軌跡。
在香港金融服務企業，這件事是什麼樣子？
設想一家 400 人的持牌資產管理公司，同時運行客戶盡職審查、投資組合報告與內部服務台三組代理。在共用憑證的做法下，盡職審查代理技術上同時擁有客戶紀錄、投資組合持倉與內部知識庫的讀取權，因為這些權限在部署時被一次過打包給了它。
在代理身分模式下，盡職審查代理獲得的憑證，只涵蓋盡職審查紀錄，有效期僅限該項任務，並綁定發起任務的合規主任。
當監管機構查問某年某日是誰存取過某份客戶檔案，答案需要的是幾分鐘，而不是一次鑑證調查。這是與保安價值分開計算的營運價值。
成本論據通常足以終結爭辯。為已在生產環境運行的代理事後補上身分層，意味著要重新測試這些代理接觸過的每一個整合；在持牌機構，這還代表每一項都要重走變更管控流程。
在部署階段就設計好，成本只是其中一小部分，而且差額幾乎全是工程時間，而非牌照開支。
同樣的邏輯適用於運行貨運系統代理的物流企業，以及運行租戶紀錄代理的物業管理公司。行業會變，授權問題不會。
略過代理身分治理，會出什麼問題？
三類失效反覆出現：代理累積了無人覆核的權限、事故無法歸因至特定代理、離職員工留下仍以其授權運作的代理。三者在設計階段都極便宜就能預防，在部署之後才拆解則極為昂貴。
失效一：權限累積
代理獲得新功能，有人選擇擴大它原有的憑證，而不是另發一組限定範圍的憑證。十二個月後，這個代理能觸及的系統，早已超出當初商業方案提及的範圍。
失效二：無法歸因的事故
有資料被移動到不該去的地方。日誌顯示的，是一組由四個代理與兩支整合腳本共用的服務憑證。你的調查等於從零開始。
失效三：孤兒授權
一位部門主管離職，他的代理仍然以一個已不存在的權限繼續運作，而為真人設計的離職檢查清單，根本捕捉不到它們。
值得點名的還有二階效應。當監管機構或審計師拿不到一個乾淨的歸因答案，多數企業的實際反應是全面放慢代理部署，包括那些治理得當的代理。
因此，一宗無法歸因的事故，代價不只是那宗事故本身，而是所有原本運作良好的 AI 項目一併失去的動能。
這些失效會與影子 AI的問題疊加，也就是員工在任何治理流程之外自行部署工具的情況。
未來 90 天你應該做什麼？
第 1 至 4 週完成代理盤點，第 5 至 8 週按資料敏感度分類，第 9 至 12 週為最高敏感度的代理發出獨立憑證。這個次序能產出一份可向董事會呈交的定位報告，同時不需暫停任何進行中的 AI 項目。
--- 第 1 至 4 週：盤點所有生產環境代理及其現用憑證
--- 第 5 至 8 週：按代理可觸及資料的敏感度分類
--- 第 9 至 12 週：為最高一層發出獨立、按任務劃分的憑證
--- 持續：每季覆核授權鏈，與真人存取權覆核同步進行
如何用一張投影片向董事會說明
--- 現況：生產環境有多少代理，其中多少共用憑證
--- 曝險：目前任何一組共用憑證所能觸及的最敏感資料集
--- 監管定位：私隱專員公署 2026 年 3 月的代理式 AI 警示對你的要求
--- 計劃：90 天路線圖，逐階段列明負責人與預算
董事會願意批准身分工作，前提是把它框定為「問責歸因」，而不是「保安開支」。歸因是審計委員會早已理解的治理概念，它能把一項開放式的技術請求，轉化為一個有明確完成日期的控制缺口。
先做盤點而非先買工具的理由在於，大多數企業會發現自己的代理數量估錯了兩至三倍。你無法為一個尚未點算清楚的族群購買控制措施。
策略要點
代理身分不是部署之後才加上去的保安附件。它決定了你的 AI 項目，是一個能向監管機構解釋清楚的項目，還是一個只能事後道歉的項目。
未來十八個月在代理式 AI 上走得最快的企業，會是那些提早解決歸因問題的企業，因為它們可以批准新代理，而不必每個季度重開同一場治理爭辯。
香港企業在這件事上有一個狹窄的優勢。私隱專員公署在執法之前先公開了關注點，這意味著框架可以從容建立，而非在壓力下倉促完成。這個窗口不會永遠敞開。
懂AI的冷，更懂你的難。UD 同行28年，讓科技成為有溫度的陪伴。二十八年來與香港企業並肩的經驗告訴我們，治理這場對話，從來不只關乎技術，而是關乎一位部門主管能否站在董事會前，把系統做過的事交代清楚。
由 UD 企業 AI 團隊審閱。
掌握了框架，下一步是弄清楚你的組織實際站在哪裡。UD 團隊手把手帶你完成每一步，由 AI 準備度評估、代理盤點、憑證設計，到董事會層面的匯報。
