企業 AI 的安全問題，正在從「誰能登入系統」轉成「誰能讓 agent 代表他做事」。Okta 在 6 月 16 日宣布擴大與 Google Cloud 的合作，把身份安全接進 Gemini Enterprise Agent Platform、Agent Runtime、Google Agent Gateway 與 Chrome Enterprise。表面上看，這是一組供應商整合；實際上，它抓到的是 agentic AI 進入生產環境後最麻煩的地方：agent 不只是回答問題，它會持有 token、呼叫 API、碰 SaaS 資料、連 MCP server，甚至在背景替使用者完成一串工作。
這也是為什麼 Okta 這次把語言放在「AI-powered workforce」。企業過去熟悉的是人類員工、服務帳號、機器身份與 SaaS 權限；現在多了一種更難管理的非人類操作者。它不像傳統服務帳號那樣只跑固定流程，也不像人類員工那樣每一步都在螢幕前做決定。它可能接到一句自然語言指令，就開始查資料、寫信、更新 CRM、開工單、推送檔案或呼叫內部工具。當 agent 變成工作流的一部分，身份治理就不能只停在登入頁。
Okta 公告裡比較具體的部分，是 Auth0 for AI Agents 與 Gemini Enterprise Agent Platform 的 Agent Runtime 整合。它列出的能力很像替 agent 裝上企業安全骨架：確認只有已驗證使用者能啟動 agent；用 Token Vault 儲存、管理與刷新 OAuth token，讓 agent 可以代表使用者連到下游服務；遇到敏感或高風險動作時觸發 human-in-the-loop 批准；用 Fine-Grained Authorization 限制 agent 只能做使用者被允許做的事；再把身份與授權加到 MCP server 上。這些不是讓模型變聰明的功能，而是讓模型「可以被允許」的功能。
這個差別很重要。過去企業導入 AI 時，常把治理問題放在資料外洩、提示詞政策、模型供應商或員工是否能用某個聊天工具。到了 agent 階段，風險會變成立體的：同一個使用者授權的 agent，可能同時碰郵件、雲端硬碟、專案管理、財務系統和客戶資料；同一個 token 若被濫用，影響範圍不只是一段對話，而是一整段跨系統流程。真正該問的，不只是「這個 agent 可不可信」，而是「它現在用誰的身份、拿到哪些權限、準備做什麼、誰能追溯」。
Okta 自己的調查剛好替這個焦慮加了背景。它說 92% 受訪高階主管表示組織中已有中度或廣泛的自主 AI agent 使用，但只有 34% 的組織把同等安全控管套用到 agentic labor force 與人類員工身上。另有 58% 高階主管回報過去 12 個月經歷過 AI 相關資安事件或差點出事。這些數字來自供應商研究，不能當成中立官方統計，但它們反映一個很現實的落差：高階主管相信自己看得見 AI，員工與工具實際上已經跑在治理前面。
Google Cloud 在這裡的角色也不只是雲端算力。它把 Gemini Enterprise Agent Platform 定位成企業建置、擴展、治理與最佳化 agent 的平台；一旦平台要承接更多 agent，身份、授權與政策執行就會變成平台競爭的一部分。Okta 公告提到的 Google Agent Gateway 更直接：外部 agent 與 Google services 互動時，gateway 會成為政策執行點，並把即時驗證與授權委派給 Okta for AI Agents。這個功能在公告中屬於接下來的整合方向，不能寫成已經全面可用，但它透露的方向很清楚：雲端 agent 平台需要一個跨人類與非人類身份的控制面。
另一條線則落在瀏覽器。這看起來像旁支，其實是 agentic enterprise 的入口問題。大量 SaaS 與 AI 工作都在瀏覽器裡發生，攻擊者偷到 session token 之後，不一定需要知道密碼，也可能繞過登入當下的多因素驗證。Okta 和 Chrome Enterprise 的整合包括 Universal Enrollment、Device Trust、macOS Extensible SSO，以及 Device Bound Session Credentials。DBSC 的邏輯是把 session 密碼學式綁到特定裝置，讓被偷走的 cookie 不容易搬到另一台機器重用。這不是萬靈丹，卻把企業安全往「登入後」推了一步。
把 agent 身份治理和瀏覽器 session 放在同一篇公告裡，正好說明企業 AI 的新邊界不在某一個產品裡。使用者在 Chrome 開工作頁面，透過 Google 的 agent 平台啟動任務，用 Auth0 或 Okta 控制身份，agent 再帶著 OAuth token 去碰 SaaS、資料庫或 MCP server。任何一層鬆掉，後面都可能變成一條自動化的風險路徑。這也是為什麼「agent 上線」不能只由 AI 團隊說了算；資安、身份、瀏覽器管理、雲平台與業務系統都會被拉進同一張圖。
從產業角度看，這件事也讓身份廠商重新站到 AI 平台旁邊。模型公司和雲端平台掌握 agent 的建置與執行環境，但企業真正要買單，還需要回答採購與稽核會問的問題：誰批准了 agent？它能不能繼承人類權限但不超權？token 是否集中保管？高風險動作能否停下來等人批准？MCP server 是否有明確的驗證與授權？日後出事時，能不能重建 agent 做過的每一步？這些不是炫技問題，而是 agent 能否從展示走到正式流程的門檻。
當然，供應商整合不等於治理完成。Okta for AI Agents 與 Gemini Enterprise Agent Platform 的集中可視性與政策控制仍有部分是 coming soon；企業也不會只用 Google Cloud、只用 Okta、只在 Chrome 裡工作。真正困難的是異質環境：Microsoft、Salesforce、ServiceNow、GitHub、內部工具、開源 agent framework 與各種瀏覽器外掛會一起存在。身份層若想成為共同控制面，就必須在跨平台政策、可攜稽核紀錄、標準化 agent 身份與最小權限上拿出更強的互通性。
但方向已經很難回頭。AI agent 的價值來自它能行動，而行動一定會碰權限。企業不可能讓每個 agent 都像超級使用者一樣拿到一串長效 token，也不可能只靠員工承諾不要把敏感資料丟給未批准工具。Okta 和 Google Cloud 這次合作真正值得注意的地方，是它把 agentic AI 的安全焦點從模型回答品質拉到「每一次代理行動」：誰發起、誰授權、誰保管 token、誰執行政策、誰留下紀錄。
如果 2025 年企業還在問要不要部署 AI agent，2026 年的問題就更像是：部署之後怎麼不讓它變成新的影子身份。Okta 與 Google Cloud 的整合不是終點，但它標示了一個產業共識正在形成：agent 要進生產環境，身份治理不再是附加功能，而是基礎設施。
參考來源
- https://www.okta.com/newsroom/press-releases/okta-teams-up-with-google-cloud-to-secure-the-ai-powered-workforce/
- https://www.techzine.eu/news/security/142204/okta-and-google-cloud-link-identity-to-ai-agents-and-browsers/
- https://siliconangle.com/2026/06/16/okta-expands-google-cloud-partnership-secure-ai-agents-browser/
- https://www.okta.com/en-au/newsroom/articles/ai-agents-at-work-2026-agentic-enterprise-security/
- https://cloud.google.com/products/gemini-enterprise-agent-platform