守護自主型企業：從 AI 策略到 Agentic AI Runtime 的全方位安全
- 2 days ago
- 8 min read
生成式 AI 正迅速走進企業日常營運。由員工使用 ChatGPT、Microsoft Copilot 等工具處理文件，到企業建立客服聊天機械人、RAG 知識庫及自主式 AI Agent，AI 已不再停留於概念驗證，而是逐步接觸企業資料、系統權限，甚至代替人類執行工作。
當 AI 只負責生成內容時，企業關注的可能是答案是否準確；但當 AI 開始閱讀內部文件、呼叫 API、修改資料，甚至自主制訂及執行行動計劃，企業需要思考的問題便更為複雜：
誰正在使用 AI？AI 可以存取甚麼資料？它可以執行哪些操作？當 AI 被誤導、濫用或作出錯誤決定時，企業能否及時發現及阻止？
在 Amidas Solution Day 2026 上，Check Point Cyber Security Evangelist Johnny Wong 以自主型企業的安全為題，分享企業在推動 AI 轉型時，如何從策略、資料、身份、應用程式，以至 Agent Runtime 建立完整防線。 AI 風險正由「內容安全」延伸至「行動安全」
近年的 AI 事故顯示，風險可以出現在多個層面。
首先是資料外洩與帳戶接管。員工可能使用個人帳戶登入公開 AI 工具，將公司文件、程式碼或客戶資料上載至未經批准的平台。另一方面，AI 助手亦可能在身份驗證不足的情況下執行敏感操作，例如協助重設密碼或存取帳戶。
其次是AI 被濫用或操控。攻擊者可以透過 Prompt Injection、惡意指令或刻意設計的對話，引導聊天機械人產生有害內容、洩露資料，甚至生成惡意程式或攻擊腳本。
更值得關注的是不受控制的自主行動。當企業由一般生成式 AI 走向 Agentic AI，AI 不再只是提供建議，而是可以自行規劃步驟、呼叫工具及執行操作。一旦 Agent 誤解指令、取得過多權限，或受到外部內容影響，便可能錯誤修改系統設定、刪除資料，甚至觸發連鎖式事故。
由此可見，企業需要保護的已不只是 Prompt 和 Output，而是整個 AI 使用流程，包括誰在使用、使用甚麼資料、連接哪些系統，以及最終可以執行甚麼行動。
安全採用 AI，應由策略與框架開始
面對這些風險，企業不應在引入 AI 工具後，才逐一修補安全漏洞。較理想的做法，是在 AI 導入初期建立清晰的轉型框架，讓業務目標、安全要求及合規需要同步規劃。
Check Point 建議企業透過五個階段推動 AI Transformation Journey：
Frame：訂立 AI 策略，明確業務目標及優先使用場景。
Map：了解每個 AI Use Case 所涉及的資料來源、資料流向、模型及外部服務。
Design：根據員工使用 AI、生成式 AI 應用及 Agentic AI 的不同需要，設計相應的安全控制。
Deploy：建立 Guardrails、身份管理及存取權限，特別是針對 AI Agent 等非人類身份。
Operate & Evolve：持續監察 AI 使用情況、檢視風險及配合合規要求，並隨着模型、應用及威脅變化不斷調整。
這個框架的重點，是先了解企業真正希望 AI 解決甚麼問題，再決定應採用哪些平台、控制措施及管治流程，而不是單純由購買某一項 AI 安全產品開始。
換言之，AI 安全並不是部署階段才需要處理的技術問題，而是應從 Use Case 規劃、資料分類及權限設計開始，貫穿整個 AI 生命週期。
從評估中找出最容易被忽略的安全缺口
當企業開始梳理 AI Use Case 及資料流，往往會發現很多問題並不來自模型本身，而是源自企業既有的帳戶、權限及資料管理方式。
其中一個常見問題是 Shadow AI。員工可以在公司裝置上使用個人帳戶登入 Claude Code、Cursor、ChatGPT 等服務，企業既無法掌握他們輸入了甚麼資料，相關內容亦可能受消費者版本條款，而非企業級資料保護協議規管。
另一個問題是 RAG Oversharing。例如 Microsoft 365 Copilot 可能根據現有 SharePoint 權限，搜尋並顯示人力資源、法律或財務部門的文件。這些過度開放的權限在傳統操作介面中未必容易被察覺，但透過 AI 搜尋後，原本分散於不同位置的敏感內容便可能被迅速整合及暴露。
至於 Agentic AI，MCP Server 權限過大亦是重要風險。若開發人員將 MCP Server 連接至整個專案目錄，而沒有設定檔案範圍、沙盒或人工審批機制，AI Agent 便可能讀取包含生產環境憑證的 .env 檔案，甚至修改不應接觸的資料。
因此，AI Security Assessment 不應只檢查模型輸出，還需要審視使用者身份、個人帳戶、資料權限、Agent 工具、MCP 連接及可執行操作。只有先看清這些隱藏的連接與權限，企業才知道真正需要在哪裏建立控制。
AI 時代需要重新定義 Zero Trust
當 AI 開始連接企業資料及執行業務流程，傳統網絡架構亦需要重新檢視。
以往的 Zero Trust 架構通常將網絡劃分為使用者、DMZ、應用程式及核心系統。然而，隨着企業引入 AI Orchestration、RAG Pipeline 及自主式 Agent，原有架構已不足以反映新的信任邊界。
Check Point 提出的 AI Zero Trust Topology 包括五個區域：
1. Perimeter & Users
2. DMZ / Frontend
3. AI Orchestration
4. Agentic
5. Core Systems & Data
當中，AI Orchestration 與 Agentic 是兩個全新的信任區域。
這個轉變非常重要，因為傳統防火牆主要分析網絡連線、協定及封包，但 Prompt Injection 的攻擊內容可能存在於一個格式完全正常的 HTTPS Request 內。從網絡角度看，該請求沒有異常；真正的攻擊存在於文字的語意與意圖之中。
因此，在應用程式進入模型、Agent 或核心系統之前，企業需要加入能理解 AI 輸入、輸出及行動意圖的安全控制，而不能只依賴傳統 NGFW 或 WAF。
建立由員工、應用程式到 AI Agent 的統一防禦
重新劃分信任邊界後，下一步便是將控制措施落實到不同使用場景。Check Point 將企業 AI 安全分為 Employees、Applications 及 Agents 三個主要範疇，並透過 Discover、Govern 及 Protect 三個層面建立統一的 AI Defense Plane。
員工與端點 AI 使用
Workforce AI Security 的目標並不是全面禁止員工使用 AI，而是讓企業在不妨礙生產力的前提下，建立安全預設。
企業需要識別員工正在使用哪些 AI 工具、是否透過個人帳戶登入、曾經輸入哪些敏感內容，以及端點上的 Cursor、Claude Code、VS Code Agent 等工具能夠存取哪些檔案及資料。
更重要的是，安全控制不應只檢查 Prompt，還需要管理 AI Agent 的行為、資料存取及可執行操作。這樣才能讓員工安全使用 AI，而不是在缺乏可視性及管治的情況下自行探索。
AI 應用程式與 Guardrails
員工使用 AI 之外，企業亦可能同時開發多個 AI 應用程式。由於不同專案的用途、風險及資料敏感程度並不相同，Guardrails 必須具備足夠彈性。
企業可以將 AI Guardrail 直接整合至每一個 GenAI Application，為不同應用設定獨立政策；亦可以建立 Shared AI Gateway，以共用方式保護多個 AI 應用及外部模型。
前者適合需要高度差異化控制的專案，後者則有助大型企業統一管理及簡化部署。兩種模式亦可並存，讓企業按業務用途、開發模式及風險程度選擇合適架構。
Agentic Workflow 與 Runtime Protection
當 AI 應用進一步發展成 Agentic Workflow，保護範圍便需要延伸至整個執行鏈。
一個完整的 Agentic AI Workflow，可能包括前端應用、LLM、RAG、MCP Server、企業資料庫、外部服務及其他 AI Agent。每個階段都有不同風險，任何一個環節失去控制，都可能影響後端系統及敏感資料。
企業需要在 Runtime 階段即時偵測 Prompt Injection、資料外洩、有害輸出及工具權限濫用；在資料層面保護非結構化資料的輸入；在模型訓練期間偵測 Data Poisoning；並在開發、微調及 Prompt Engineering 階段進行安全測試。
這種保護方式不再局限於單一模型或應用，而是覆蓋 AI 由開發、連接資料、作出推理，以至執行行動的完整流程。
AI Red Teaming：測試的不只是系統，而是 AI 的行為
要驗證上述控制是否真正有效，企業亦需要重新思考安全測試方式。
傳統 Penetration Testing 主要針對網絡、系統及應用程式漏洞，但 AI Red Teaming 更着重對抗性及風險導向測試，包括 Prompt Injection、越權操作、敏感資料洩露、模型繞過及 Agent 行為操控。
攻擊者亦不一定使用企業日常支援的語言。Check Point 的簡報指出，其 AI-Native Security Foundation Model 會分析超過 100 種攻擊語言。攻擊者可能利用阿拉伯文、瑞典文或其他語言，嘗試繞過只針對中文或英文建立的安全規則。
因此，AI 安全測試需要結合專家主導的 Red Teaming，以及平台化、持續性的自動測試，而不是在系統上線前進行一次檢查便告完成。隨着模型、資料來源、Prompt、工具及權限持續改變，安全驗證亦必須同步更新。
AI 不只是需要被保護，也將改變安全營運
AI 在企業安全架構中的角色並不只有「被保護的一方」。它亦可以成為 Security Operations 的一部分，協助企業處理日益複雜的安全工作。
透過針對網絡安全場景微調的 LLM、多 Agent 系統、Agentic Automation Platform 及 MCP Server，企業可讓不同安全工具互相協作，例如整理過去十日的安全事件、分析政策設定、提出調整建議，或將原本需要數小時完成的工作縮短至數分鐘。
然而，當安全營運本身開始使用 Agentic AI，企業同樣需要為這些 Agent 設定身份、權限、行動範圍、審批機制及完整審計記錄。否則，用於提升效率的自動化工具，亦可能成為新的高權限風險來源。
這亦再次說明，AI 安全並不是阻止企業使用 AI，而是確保 AI 在清晰的身份、權限、政策及監察機制下運作。
AI 安全不是一次性項目，而是持續性的能力
無論企業是否已經正式採用 AI，攻擊者早已開始利用 AI 提升偵察、漏洞分析、社交工程及攻擊自動化能力。未來的攻擊可能以更少人手、更快速度橫跨整個攻擊鏈，而新模型與 Agentic Capability 亦會持續普及。
因此，企業不能只在 AI 專案推出前進行一次風險評估，而應持續重新檢視自身的 Security Posture，包括員工 AI 使用、資料權限、模型、Agent、MCP、應用程式及整體基礎設施。
由策略規劃、風險評估、Zero Trust 架構，到 Workforce AI Security、Application Guardrails、Runtime Protection 及 AI Red Teaming，每一個環節都需要互相連接，才能形成完整的 AI 安全體系。
在正式部署 AI 前，企業可先透過 Amidas 與 Check Point 的 AI Workshop，梳理現有及計劃中的 AI Use Cases、識別高風險資料流及安全缺口，並按照業務價值與風險訂立優先次序，逐步建立安全、合規及可持續發展的 AI Transformation Journey。
立即聯絡我們了解更多：
Whatsapp: 9828 3401
