Mend Releases AI Security Governance Framework: Covering Asset Inventory, Risk Tiering, AI Supply Chain Security, and Maturity Model

安全團隊聽說某個 AI 工具存在時，它往往已在生產環境跑了幾週。Mend 發布的《AI 安全治理：實用框架》正面回應這個普遍現象：絕大多數組織今天仍停在安全成熟度的第 1 或第 2 階段，AI 採用速度遠快於治理跟上的速度，而這份框架的起點不是假設你已有成熟方案，而是從零給出可操作的行動手冊。

影子 AI 盤點：治理從可見性而非政策出發

框架開篇確立一個核心前提：「你無法治理你看不見的東西」。要解決可見性問題，框架把「AI 資產」的定義刻意放寬，涵蓋 GitHub Copilot（AI 輔助程式碼開發工具）、Codeium 等開發工具；OpenAI API、Google Gemini 等第三方 API 接口；各類開源模型；Notion AI 等 SaaS 產品內嵌的 AI 功能；以及能自主規劃並執行多步驟任務的 AI 代理（Agent）。

這種寬廣定義直指「影子 AI」（Shadow AI）問題的核心。現實場景是這樣展開的：工程師私下安裝 Copilot 加速出貨，資料分析師悄悄用 LLM（大型語言模型）做報表，產品團隊在功能分支裡埋入第三方模型——到安全團隊聽說的時候，AI 早已在處理真實資料、觸碰真實系統了。框架特別強調，找出這些工具的過程必須是非懲罰性的，讓開發者感到揭露是安全的，否則盤點行動本身就注定失敗。只有讓人敢說，才能建立完整資產清單，進而展開任何有意義的治理。

五維度評分與 Tier 1-3 分層治理邏輯

有了清單，下一步是優先排序。框架不把所有 AI 部署視為同等危險，而是以五個維度對每個資產評分，每個維度 1-3 分，合計 5 到 15 分：資料敏感性（Data Sensitivity）、決策權限（Decision Authority，AI 輸出是否直接觸發後續動作）、系統存取範圍（System Access）、對外曝露程度（External Exposure），以及供應鏈來源（Supply Chain Origin）。

依總分劃分三個風險等級：Tier 1（5-7 分）只需標準安全審查和輕量監控；Tier 2（8-11 分）觸發強化審查、存取控制和每季行為稽核；Tier 3（12-15 分）必須完整安全評估、設計審查、持續監控，並備好事件回應計畫。框架點出一個容易忽略的事實：模型不改任何程式碼，單靠整合方式改變——例如新增生產資料庫寫入權限，或把服務開放給外部用戶——就可能讓風險等級從 Tier 1 直接跳到 Tier 3。治理的焦點不只是模型本身，而是模型在整個系統脈絡中的位置與權限。

存取控制方面，框架以最小權限原則（Least Privilege，每個身份只能存取完成工作所需的最少資源）貫穿始終：API 金鑰必須精確限定在特定資源，不得讓 AI 與人類用戶共用憑證，預設採用只讀存取。AI 生成的內容本身也可能成為資料外洩管道——透過推論或重建帶出敏感資訊——因此輸出端必須過濾社會安全碼、信用卡號、API 金鑰等受管制資料模式。AI 生成的程式碼也必須接受與人類所寫程式碼同等嚴格的 SAST（靜態應用安全測試）和 SCA（軟體組成分析）掃描。

AI-BOM：把供應鏈透明度延伸到模型與訓練資料

部署第三方模型，就等於繼承了訓練者、訓練資料集，以及所有打包進來的依賴項的安全狀態。框架引入 AI-BOM（AI Bill of Materials，AI 物料清單）概念，把傳統 SBOM（軟體物料清單，追蹤軟體元件與已知漏洞）的範疇延伸到 AI 層。一份完整的 AI-BOM 應記錄：模型名稱、版本與來源；訓練資料的參照記錄；微調（fine-tuning）資料集；運行模型的所有軟體依賴；推理（inference）基礎設施元件；以及已知漏洞及其修復狀態。

這不只是內部風險管理的工具，也是直接回應新興法規的基礎文件。EU AI Act（歐盟 AI 法案）和 NIST AI RMF（美國國家標準技術局 AI 風險管理框架）均明確要求供應鏈透明度，AI-BOM 讓組織不論對齊哪個外部框架，都有一份可追溯的合規底層文件。

傳統 SIEM 抓不到的四類 AI 威脅與三層監控架構

傳統的 SIEM（安全資訊和事件管理系統，集中分析安全日誌與告警的平台）、網路異常偵測、端點監控，設計邏輯都建立在人類攻擊者的威脅模型上，對 AI 工作負載特有的失效模式幾乎沒有偵測能力：prompt injection（提示詞注入，透過惡意輸入操控 AI 行為）、model drift（模型漂移，輸出隨時間悄然偏移）、行為操控，以及大規模越獄（jailbreak）嘗試。

框架因此定義三個必要的監控層：模型層監看用戶輸入中的 prompt injection 跡象、嘗試提取系統提示（system prompt）或模型配置的行為，以及輸出信心分數的顯著偏移；應用整合層重點追蹤 AI 輸出流向敏感接收端的情況——資料庫寫入、外部 API 呼叫、命令執行——以及 API 呼叫量偏離基線的異常；基礎設施層監控對模型製品（model artifact）或訓練資料儲存的未授權存取，以及向核准清單以外 AI API 的意外對外流量（egress）。

六項政策元件、四個角色與四階段成熟度模型

政策層面，框架定義六個核心元件：核准工具清單（可直接採用、免去額外審查）；分層審查流程（Tier 1 輕量、Tier 2/3 深度）；資料處理規則（內部 AI 與外部第三方 API 的明確分野）；AI 生成程式碼安全要求；架構審查中的 AI 整合揭露義務；以及禁止使用清單（如未經批准對受管制客戶資料訓練模型）。治理責任劃定四個角色：AI 安全負責人（維護核准清單、升級高風險案例）、開發團隊（聲明工具使用、提交 AI 程式碼審查）、採購與法務（審查供應商合約的資料保護條款），以及對 Tier 3 部署風險進行最終簽核的高層主管。

框架以 AI 安全成熟度模型收尾，四個階段直接映射到 NIST AI RMF、OWASP AIMA、ISO/IEC 42001、EU AI Act 四大框架：Emerging（臨時應對 / 初步意識）→ Developing（定義流程 / 被動回應）→ Controlling（主動管理）→ Leading（持續優化 / 自適應）。每個階段轉換有明確的業務成果：Emerging 到 Developing 是可見性建立（部署 AI-BOM、跑初次威脅建模）；Developing 到 Controlling 是自動化護欄（CI/CD AI 安全掃描、系統提示強化）；到達 Leading 則需持續驗證——自動化紅隊測試（automated red teaming）、AIWE（AI 弱點枚舉）評分、運行時監控。在 Leading 階段，安全不再是開發的瓶頸，而是 AI 採用加速度的基礎設施。Mend 同時提供一份自我評估工具，宣稱可在五分鐘內對照四大框架完成組織 AI 成熟度評分。

大多數組織的問題不是缺 AI 安全策略，而是連自己跑了幾個 AI 都不知道——治理從清查開始，不從政策開始。