一架客機正在滑向跑道，但塔台不知道機長是誰、不知道飛機要飛去哪裡，也不知道機上載了什麼。更重要的是，飛機可以在沒有進一步核准的情況下，自行改變航線和進入其他機場
沒有任何機場會讓這架飛機起飛
但許多企業目前部署 AI Agent 的方式，卻與此非常相似
企業讓 AI Agent 連接客戶資料庫、CRM、財務系統、客服平台和內部 API；讓它閱讀資料、建立工單、修改訂單，甚至代表員工執行操作。與此同時，企業可能仍然不知道有哪些 Agent 正在運行、哪些人可以使用它們、它們擁有哪些系統權限，以及哪些資料正被送往外部模型
問題已不再只是「AI 的答案是否準確」，與傳統生成式 AI Chatbot 不同，AI Agent 不只是產生文字，而是能理解目標、調用工具並執行任務。因此企業需要管理的不只是模型輸出，而是 Agent 的身份、權限與行為。
AI 發展得愈快，企業治理的距離便可能愈遠
香港網絡安全事故協調中心在《香港網絡安全展望 2026》中指出，香港在 2025 年錄得 15,877 件網路安全事故，按年增加 27%。報告亦將代理式 AI、企業 AI 管治較弱所造成的資料外洩，以及供應鏈風險列為 2026 年的重要網絡安全議題。
這反映企業正面對一個實際矛盾：
業務團隊希望利用 AI 推出產品、提升客服效率及自動化工作流程；資安與合規團隊卻未必已掌握 Agentic AI 的運作方式、風險邊界及控制工具
全面禁止 AI 可能使員工轉向個人帳戶、私人裝置或未經批准的平台，但在缺乏保護和監察的情況下開放使用卻可能讓客戶資料、財務資訊、內部文件或程式碼進入企業無法監察的環境
真正的答案並不是在「全面禁止」與「完全開放」之間二選一。
企業如何保護 AI Agent？
企業要建立有效的 AI Agent 安全治理，需要同時控制兩件事：
- 管理身分：確認哪一個人或 AI Agent 可以存取哪些資源及執行哪些操作
- 管理流量：檢查哪些 Prompt、模型回應和 API 請求可以通過企業的 AI 環境
對應到機場
- 身分控制回答的是：誰可以起飛？可以前往哪裡？
- 閘道控制回答的是：飛機載了什麼？航線是否安全？有沒有進入禁航區？
這就是企業 AI 安全的兩條跑道：Identity & Gateway
企業目前面對的兩種 AI 風險
風險一：內部使用者造成的 Shadow AI
當員工找不到經企業核准、方便使用的 AI 工具時，他們可能自行使用公共生成式 AI 平台處理工作。這些使用行為未必出於惡意，員工可能只是希望摘要客戶文件、分析數據、檢查程式碼或整理會議記錄
但當資料被輸入未經企業審查的平台，IT 團隊可能無法知道哪些資料離開了企業、由哪個帳戶上傳、平台如何處理資料，以及事件發生後應如何追查
這就是 Shadow AI，企業內部出現未經批准、缺乏監察或未納入治理的 AI 使用行為。
風險二：對外 AI 應用與自研 AI Agent 被操縱
另一種風險來自企業自行開發的 AI 客服、知識庫、工作流程 Agent 或自動化系統。傳統聊天機械人主要提供答案，AI Agent 則可能存取內部資料、呼叫 API、啟動工作流程或代表使用者執行操作
當攻擊者透過 Prompt Injection（提示詞注入）、惡意文件或經修改的外部內容影響 Agent，風險就不只是一個錯誤答案。如果 Agent 的權限過高，它可能在受到影響後讀取不應存取的資料、調用不應使用的工具，或執行未經批准的操作。
建立安全跑道：Identity × Gateway 雙軌架構
一座機場不能只依靠安檢，也不能只依靠護照
即使旅客已通過身分核實，行李仍需要接受檢查；即使行李沒有違禁品，旅客也不能隨意進入任何登機口或駕駛任何飛機；企業 AI 安全亦是如此。
| 機場運作 | AI 安全控制 |
| 護照、員工證及登機證 | 使用者與 AI Agent 的身分 |
| 可進入的區域 | 系統、API 與資料存取權限 |
| 行李及貨物安檢 | Prompt、Response 與敏感資料檢查 |
| 塔台及航線管理 | AI Gateway、模型路由及政策 |
| 禁航區 | 不允許 Agent 執行的操作 |
| 飛行紀錄及黑盒 | Log、Audit Trail 與事件調查 |
| 緊急停飛 | 撤銷 Token、停用 Agent |
跑道一：以身分治理控制「誰可以做什麼」
管理內部使用者的 AI 存取
企業首先需要建立一個清晰的核准工具清單，並將企業使用的 AI 應用納入既有的身分管理制度，透過 Okta Identity Governance、SSO 和 MFA，企業可以：
- 確認哪些員工可以使用指定 AI 工具
- 根據部門、職務及裝置狀態授予權限
- 建立 AI 工具的申請與審批流程
- 定期審查使用者是否仍然需要相關存取權
- 在員工轉職或離職時撤銷權限
- 保留存取及審批紀錄
Okta Identity Governance 的核心目標是讓使用者只保留工作所需的存取權，並透過生命週期、存取申請、Access Certification 和稽核機制落實最小權限。
將 AI Agent 視為真正的身分
AI Agent 不應只被視為程式中的一項功能。只要它能夠持有 Token、使用 API、讀寫資料或代表其他人執行操作，它便是一個需要獨立管理的 Non-human Identity，每一個 AI Agent 最少應有：
- 唯一身分
- 明確的人類負責人
- 清楚定義的任務
- 受限制的資料及工具存取範圍
- 短期或可撤銷的憑證
- 完整的操作及授權紀錄
- 停用及退役流程
Okta for AI Agents 的方向是將 Agent 作為 first-class identity 管理，包含發現、註冊、指派人類負責人、最小權限、短期憑證、生命週期治理、稽核及必要時撤銷存取。即使 Agent 因 Prompt Injection 受到操縱，身分與權限控制仍能限制它可以造成的影響。
跑道二：以 AI Gateway 管理「哪些內容可以通過」
身分控制決定誰可以進入系統，但企業仍需要知道資料在 AI 環境中如何流動。對於企業自建入口、內部 AI 應用，或透過 API 存取外部模型的使用情境，Cloudflare AI Gateway 可以成為企業與模型供應商之間的集中控制點，並
- 記錄模型請求及使用情況
- 監察 Token 與成本
- 管理不同模型供應商的流量
- 使用快取減少重複請求
- 為 AI 流量建立統一政策
- 檢查 Prompt 及模型回應中的敏感資料
Cloudflare AI Gateway 的 DLP 能夠掃描傳送給模型的 Prompt，以及模型傳回的 Response，識別敏感資料並根據企業建立的政策進行處理。
對於面向外部使用者的 AI 應用，企業則可以在應用入口加入 Cloudflare AI Security for Apps，偵測：
- Prompt Injection
- 個人識別資料
- 不安全主題
- 企業自訂的敏感主題
- 異常 Token 使用
偵測結果可以配合 WAF 自訂規則或 Rate Limiting 規則，採取記錄、限制或阻擋等行動。
Identity 與 Gateway 分別保護什麼？
| 風險 | Identity 控制 | Gateway／應用安全控制 |
| 未授權員工使用 AI | SSO、MFA、IGA、Access Review | AI 流量可視性及政策 |
| 敏感資料進入模型 | 限制可使用者及裝置 | DLP 掃描 Prompt／Response |
| Prompt Injection | 限制 Agent 權限及可用工具 | AI Prompt 偵測與 WAF 規則 |
| Agent 權限過高 | 最小權限、短期憑證 | 限制可存取的端點與流量 |
| Agent 行為失控 | 撤銷權限、停用 Agent | 阻擋請求及 Rate Limiting |
| 無法追查操作 | 身分與授權 Audit Trail | Prompt、Response 及流量 Log |
| 模型使用成本失控 | 限制使用者及應用權限 | Token 分析、快取及使用量監察 |
任何一條跑道單獨運作都不完整。只建立 Gateway，企業可能知道有什麼流量通過，卻不知道背後是哪個人或 Agent 取得授權。只建立 Identity，企業可能知道誰登入了系統，卻不知道 Prompt 中包含了什麼資料，或模型回傳了什麼內容。
結論：讓企業 AI 安全起飛
企業不能因為 AI 帶來風險，便永久關閉跑道；但亦不能為了加快創新，讓每一個 Agent 自行決定身分、權限與資料流向
企業可以先從盤點現有的 AI 工具、Agent、模型 API、服務帳戶及憑證開始，了解目前有哪些人與系統正在使用 AI。再來是釐清每一位使用者和 Agent 可以接觸哪些資料、存取哪些系統及執行哪些操作，並為高風險行動加入人工確認、權限撤銷及完整稽核紀錄。最後可以先選擇一個使用者、資料來源及操作範圍清晰的場景，例如內部知識搜尋、客服摘要或 IT 工單分類，建立身分、權限、流量檢查、DLP、Log 及事件處理機制，再逐步擴展至其他 AI 應用
真正可持續的 AI 治理，是確保每一位使用者及每一個 Agent 都有可識別的身分，每一項權限都有清晰範圍，每一個 Prompt 和模型回應都有適當檢查，而每一次重要 API 操作都可以被追蹤。當 Agent 出現異常行為時，企業亦必須能夠迅速限制權限或將其停用
AI Agent 安全治理的目的，不是阻止 AI 起飛，而是確保每一次起飛都能被識別、授權、檢查及追蹤
透過 Identity × Gateway 的雙軌架構，企業可以將 AI Agent 由一個不可控的實驗，轉變為可以安全擴展的企業能力。歡迎聯絡思想科技 Master Concept 專業顧問了解更多！
FAQ
AI Agent 有哪些主要資安風險？
AI Agent 的主要風險包括 Prompt Injection、敏感資料外洩、權限過高、憑證濫用、未受控的工具調用，以及缺乏完整操作紀錄。由於 Agent 可以代表使用者執行實際操作，其風險通常比只產生文字的聊天機械人更高。
企業應否全面封鎖公共 AI 工具？
不建議只依賴全面封鎖。封鎖可能令員工轉向個人裝置或未經監管的平台。較可持續的方法是提供經批准的 AI 工具，並結合身分管理、使用政策、員工培訓、流量可視性及 DLP。
企業如何防止 Prompt Injection？
企業不應只依賴 System Prompt。較完整的控制包括 AI Prompt 偵測、輸入內容政策、身分驗證、最小權限、工具調用授權、人工確認及完整稽核紀錄。
為什麼 AI Agent 要被視為 Non-human Identity？
因為 AI Agent 可以持有憑證、調用 API、存取資料及代表使用者執行操作。將 Agent 視為獨立身分，企業才能為它指派負責人、限制權限、管理生命週期，以及追查每一次操作。
AI Security 與傳統 Application Security 有什麼不同？
傳統 Application Security 主要保護應用程式本身，例如漏洞、API 安全與未授權存取；AI Security 則需要進一步管理模型互動、資料流向與 AI 行為。由於 AI 應用能理解自然語言、存取資料並執行任務，企業除了保護系統，也需要確保 Prompt、模型回應及 AI Agent 操作都受到適當監控與控管。因此，AI Security 是在既有應用安全基礎上，延伸出的新一代治理能力。
導入 Cloudflare 與 Okta 是否需要重構現有 AI 應用？
很多情況可以透過調整 API 路由、反向代理、身分驗證及授權方式，以較低改動導入。不過，實際工作量仍取決於既有應用架構、模型供應商、Streaming 設計、API 認證及工具調用方式，不應假設完全不需要修改。
