在傳統的 IT 環境中，身份與資源之間通常還能建立相對清楚的關聯。例如 Server 的管理者是誰、電腦的使用者是誰、Web 服務屬於哪個部門、API Key 是誰在哪個 Application 建立的等等。

然而到了 AI Agent 的時代，事情開始變得不一樣了。我們還是可以回答，這個 AI Agent 是誰建立的。但當我們開始讓 AI Agent 透過 MCP 或 Connector 串接其他系統時，複雜的問題就來了。AI Agent 是用誰的 OAuth Token 做事? 是用誰的 API Key 做事? AI Agent 真的應該握有對應的權限嗎? AI Agent 的所作所為，真的該歸責於 OAuth Token 或是 API Key 的擁有者嗎?

當企業還用傳統的 IAM 邏輯在管理 AI Agent 時，很容易就會遇到這種難以判定責任歸屬的困境。而當遇到 Shadow AI 時，問題就會被進一步的放大，因為企業最終從 log 上只看得到 API Key 的擁有者，卻完全不知道有 AI Agent 的存在。

這就會產生一個非常有趣的身分錯位。AI Agent 可能是 Alice 建立的，但 MCP Server 的設定卻是用 Bob 的 API Key，而另一個 SaaS 服務又是透過 Charlie 的 Token 來驗證登入的。在傳統的角度來看，會直接認定操作 MCP 的是 Bob ，而操作 SaaS 服務的是 Charlie。從系統的角度來看，Alice、Bob、Charlie 都可能成為 Log 上的「操作者」，但真正做出決策與執行動作的，卻是另一個 AI Agent。當 Alice 沒有正式向組織申請登記 AI Agent 時，甚至沒有人知道這個 AI Agent 的存在。

這時候我們就會需要重新思考 API Key 和 OAuth Token 的角色。過去我們會直接認定這些 Credential 代表的是員工本人，但在 AI Agent 的時代，這就變成 AI Agent 向員工借了身份，而借身份這件事帶來最大的問題，就是 Owner 和 Actor 不再能劃上等號，這也是資安單位想要極力避免的事情。

所以在 AI Agent 時代，Non-Human Identity 就會變成 IAM 中很重要的一環。所謂的 Non-Human Identity ，指的是不以自然人作為直接主體，且往往是由特定裝置或自動化程式使用，例如常見的 Service Account、Workload Identity、Application Identity 等。

正式申請使用的 AI Agent 至少還有機會基於制度來要求註冊，但如果是使用者私下建立的 AI Agent 會完全成為企業中的隱身怪，沒有資產編號、沒有正式 Owner、沒有 IT 登錄資料，卻拿著某個員工的 Credential 持續工作。從 Log 中也完全看不出有個 AI Agent 在隱身在幕後操作。

所以對於企業而言，最急切且重要的議題，反而是在於 Identity Discovery ，也就是要怎麼揪出這些隱身幕後的 AI Agent。企業會需要知道有哪些 Agent、由誰建立、用了哪些 Credential、連接哪些系統、有哪些權限等。而這些資訊可能來自許多不同的系統，需要經過仔細盤點統整手邊有的資源才有機會達成，目前確實很難找到一個立即可用的解決方案，企業仍需要整合 IAM、CASB、EDR、API Gateway、SaaS Audit Log 等不同來源的資訊，逐步建立自己的 Identity Discovery 能力。

而「知道它是誰」只是第一步。下一個問題是：「它到底能做什麼？」