企業正在快速導入生成式 AI。ChatGPT、Gemini、Claude、Microsoft Copilot 等工具已經進入日常工作，不少企業也開始建立 AI 使用政策，規定哪些平台可以使用、哪些資料不能輸入，以及哪些 AI 工具需要 IT 核准。
但有了政策，不代表企業已經真正掌握 AI 的使用情況。
行銷人員可能因為工作需要，自行註冊新的 AI 工具；開發人員可能授權 AI 存取 GitHub；業務人員可能把 AI 助手連接到 Google Drive。這些行為未必出於惡意，很多時候只是因為業務需求的速度比正式的 IT 審批流程更快。
問題是，當 AI 使用開始分散到不同帳號、應用程式與連接方式後，企業真正需要知道的已經不只是「員工用了哪些 AI」，而是：
誰正在使用？以什麼身分使用？AI 被授權存取什麼？這些權限是否仍然合理？
這就是 Shadow AI 開始從 AI Governance 問題，延伸成 Identity Security 問題的地方。
Shadow AI 的真正盲點，是企業看不見「誰擁有什麼 Access」
Shadow AI 一般讓人聯想到「員工偷偷使用未經批准的 AI」。因此企業最直覺的處理方式，通常是建立 Approved AI List，或者直接封鎖未經批准的平台。
這些控制仍然有價值，但只能回答第一層問題：哪些 AI 可以使用？
真正的治理還需要回答第二層：誰可以使用，以及使用之後可以接觸什麼？
例如，一名員工使用企業 Google 帳號登入一個 AI 服務，再授權它連接 Google Drive。對員工而言，只是按下「Allow」，讓 AI 幫忙搜尋文件；但從企業安全角度來看，一段新的 Access Relationship 已經建立。
現在企業需要知道的就不只是 AI 工具名稱，而是這名使用者是誰、用了哪個企業 Identity、授權了哪些權限、可以接觸哪些資料，以及這項 Access 應該維持多久。如果員工日後轉職或離職，原本建立的 AI Access 是否會一起被檢查或撤銷？
如果答案不清楚，問題就已經不是單純的 Shadow AI Visibility，而是 Identity Governance 的缺口。這也是 Okta 在 AI 時代可以扮演的重要角色。企業本來就利用 Identity 平台回答「誰可以存取什麼」，而 AI 的普及並沒有改變這個基本原則，只是讓需要治理的 Identity 與 Access 關係變得更多。
AI 的風險正在從「輸入了什麼資料」延伸到「AI 可以存取什麼」
企業最早關注生成式 AI 安全時，問題通常集中在資料外洩。例如員工是否把客戶資料、原始碼、合約或其他敏感資訊貼進公共 AI 平台。這仍然是非常重要的風險，但現在的 AI 使用方式正在改變。AI 不再只是等待使用者把資料貼進 Prompt，越來越多工具可以直接連接 Google Drive、GitHub、Salesforce、Slack、CRM、API 或其他企業資源。
因此企業需要同時回答兩個不同的問題：
What data is going into AI?
員工把什麼資料交給 AI？
以及：
What can AI access?
AI 本身被允許存取什麼？
前者主要涉及 Data Governance、DLP 和 Browser Security；後者則開始進入 Identity、Authorization 與 Access Governance。
AI Agent 只是把這個問題再往前推一步。當 AI 不只是讀取資料，而能夠代表使用者查詢系統、呼叫 API 或執行動作時，企業更需要知道這個 AI 由誰負責、取得了哪些權限，以及權限是否可以被限制和撤回。因此，AI Agent 並不是另一個獨立的安全問題，而是讓 Identity × Access 這個問題變得更明顯。
Okta 如何把 AI Access 加入企業既有的 Identity Governance？
與其為 AI 重新建立一套完全獨立的安全架構，一個更實際的方向，是把 AI 納入企業本來就在使用的 Identity Security 模型。
這也是 Okta 目前 AI Identity 策略的核心之一。
以 AI Agent 為例，Okta for AI Agents 可以發現已知及未知的 AI Agents，把它們登記到統一的 Identity Directory，並指定明確的 Human Owner。這樣 Security Team 不再只看到「環境裡存在一個 Agent」，而可以進一步知道它由誰負責，以及它與哪些企業資源建立了連接。
第二步是控制 Access。
如果某個 AI 只需要存取一部分資料，就不應該因為整合方便而取得過大的權限；如果某項存取只在執行任務期間需要，也沒有必要長期保留 Credential。Okta for AI Agents 的設計包括以 scoped、short-lived credentials 取代較高風險的 long-lived tokens，並透過 least-privilege policy 控制 Agent 能夠連接的資源。
再往下一步，就是把 Access 放進治理流程。
Okta Identity Governance（OIG）整合 Lifecycle Management、Workflows 與 Access Governance，而 Access Governance 本身又包括 Access Requests、Access Certifications、Governance Reporting 和 Entitlement Management。這代表企業可以不只決定「是否給予 Access」，還可以管理誰提出申請、誰批准、授予了哪些具體權限，以及日後是否仍然需要保留。
Okta 也持續把 Identity Governance 的治理能力延伸到 AI Agents 及其 linked applications，讓 AI Access 可以沿用企業既有的治理邏輯，而不需要成為另一個完全孤立的權限世界。
最後一個關鍵是 Lifecycle。
真正成熟的 Access Governance 不只是懂得「給權限」，更重要的是懂得在不再需要時「把權限拿回來」。如果 Agent 被停用、Owner 離職、用途改變或出現異常行為，企業需要有清楚的方式停止新的存取。
所以 Okta 在這個架構中的價值，不只是「保護 AI」。更精確地說，是把 AI 帶回企業熟悉的 Identity Security 原則：
誰是 Owner？可以存取什麼？為什麼擁有這個 Access？應該保留多久？什麼時候需要撤銷？
這些問題本來就是 Identity Governance 的核心，只是 AI 讓它們變得更加迫切。
Shadow AI 治理不應只靠 Block，而應該建立可見、可控、可撤銷的 Access
這並不代表 Identity Platform 可以單獨解決所有 Shadow AI 問題。
如果企業希望了解員工是否正在私人裝置使用公共 AI、是否把敏感資料貼進生成式 AI，Browser Security、DLP、CASB 及其他 Data Security 控制仍然有其重要性。而這個區別反而更能說明完整 AI Governance 應該如何建立。
Browser 和 Data Security 回答：資料如何進入 AI？
Identity Security 則回答：誰正在建立 Access？AI 可以存取什麼？誰應該對這些權限負責？
企業真正需要的不是其中一種控制，而是讓這些控制互相配合。
企業評估 AI 權限治理的 5 大核心提問：
- 連接可見度：我們是否掌握哪些 AI 與 AI Agent 正在連接企業資源？
- 權限歸屬：是否清楚知道誰建立、誰該對這些 AI 工具負責（Human Owner）？
- 存取範圍：是否明確知道這些 AI 工具被授權接觸哪些資料與系統？
- 最小權限：這些 Access 是否嚴格符合最小權限原則（Least Privilege）？
- 生命週期撤銷：當人員離職、用途改變時，能否迅速撤銷相關存取權限？
如果其中幾個問題無法回答，企業面對的可能就不只是 Shadow AI，而是更廣泛的 Identity Visibility 與 Access Governance 缺口。
AI Governance 的下一步，是把 Identity 放回治理中心
企業最初管理生成式 AI 時，最擔心的是員工把什麼資料放進 AI。
現在，另一個同樣重要的問題正在出現：AI 被允許接觸什麼？
當 AI 開始與企業 Application、Data 和 Workflow 建立更多連接，治理的重點自然會從單純管理工具，延伸到管理 Identity 與 Access。
這也是 Shadow AI 在企業環境中真正值得關注的原因。
問題並不只是「公司裡還有多少未經批准的 AI」，而是企業是否能清楚知道每一段 AI Access 背後的 Identity、Owner、Permission 與 Lifecycle。
AI Governance 不應該建立另一座安全孤島。AI 越深入企業工作流程，就越需要回到 Identity：誰可以存取什麼、在什麼條件下存取，以及這項權限什麼時候應該結束。
您的企業是否真的看得見 AI 背後的 Identity 與 Access？歡迎聯絡思想科技 Master Concept 專業顧問一起評估現有 AI Identity 與 Access Governance 架構，找出 Shadow AI、Access Visibility 與 Identity Governance 中可能存在的缺口。
FAQ
Shadow AI 是什麼？
Shadow AI 是企業未正式核准或無法完整掌握的 AI 使用，例如員工自行使用 AI 工具或建立未受治理的 AI Agent。
Shadow AI 有什麼風險？
真正的風險不只在資料外洩，而是企業可能不知道誰正在使用 AI、AI 可以存取什麼，以及這些權限是否仍然合理。
公司可以怎麼管理 Shadow AI？
不能只靠封鎖。企業需要同時掌握 AI 使用情況、保護敏感資料，並管理背後的 Identity、Access 與權限生命週期。
Okta 可以管理 Shadow AI 嗎？
Okta 可協助企業發現與治理 Shadow AI Agents，確認 Owner、控制 Access，並把 AI Agent 納入既有的 Identity Governance 流程。
為什麼 Shadow AI 是 Identity Security 問題？
因為當 AI 開始連接 Google Drive、GitHub、CRM 或其他企業系統，關鍵問題就從「用了哪個 AI」變成「誰授權了 AI 存取什麼」。
