企業導入 AI Agent 之後，資安問題不再只是「員工有沒有把機密資料貼到 ChatGPT」。
新的問題是：公司裡可能有很多 agent 正在讀資料、呼叫 API、操作瀏覽器、寫入 SaaS、串接 MCP server。它們不是傳統使用者，也不是傳統應用程式，卻能代表人完成工作。
這就是 AI-SPM 開始被討論的原因。
AI-SPM，全名是 AI Security Posture Management，可以翻成 AI 安全姿態管理。它的目標是讓企業持續看見、評估與控制 AI 系統和 AI Agent 帶來的風險。
AI-SPM 是什麼？
AI-SPM 是一種新的資安管理類別，重點在管理企業 AI 使用狀態。
它通常包含：
- 盤點企業內部使用哪些 AI 工具與模型。
- 發現正式與非正式的 AI Agent。
- 追蹤 agent 能讀哪些資料、能呼叫哪些工具。
- 檢查 API key、connector、MCP server 與外部資料流。
- 偵測異常 prompt、異常資料傳輸與異常 tool call。
- 評估模型、資料、權限與業務流程風險。
- 提供修補建議、停用機制與稽核紀錄。
如果 CSPM 是管理雲端安全姿態，SaaS security 是管理 SaaS 使用風險，那 AI-SPM 就是管理 AI 與 agent 工作流的安全姿態。
為什麼傳統資安工具不夠？
傳統資安工具很擅長看使用者、裝置、網路、雲端、SaaS 與 endpoint。
但 AI Agent 會讓邊界變模糊。
一個 agent 可能：
- 使用某個員工的身份登入。
- 讀取 CRM、Google Drive、SharePoint 或 GitHub。
- 呼叫外部模型 API。
- 連到 MCP server。
- 在瀏覽器裡完成多步驟操作。
- 依照文件內容決定下一步。
- 把資料整理後送到另一個 SaaS。
從傳統工具看，這些行為可能像正常使用者操作。
但從 AI 風險角度看，你需要知道的不是只有「誰登入了」，而是「哪個 agent 代表誰做了什麼」。
這就是 AI-SPM 的盲點切入點。
Self-running agents 帶來什麼新風險？
TechRadar 近期把 self-running agents 稱為 2026 年企業安全危機之一。核心原因很簡單：agent 從被動回答，變成主動執行。
過去 LLM 的主要風險是輸出錯誤、幻覺、資料外洩。
Agent 的風險多了幾層：
| 風險 | 說明 |
|---|---|
| 身份不清 | Agent 用人類帳號做事，事後難以追責 |
| 權限過大 | Agent 拿到比任務需要更多的資料與工具 |
| 資料流不可見 | 資料在 SaaS、API、模型與 connector 之間移動 |
| 行為基準不存在 | 資安團隊不知道 agent 的正常行為長什麼樣 |
| Prompt injection | 外部內容可能誘導 agent 做錯事 |
| Tool call 失控 | Agent 呼叫錯工具或在錯誤情境執行操作 |
| 審核疲勞 | 人類反覆批准，最後失去審核品質 |
AI-SPM 的價值，就是把這些風險變成可觀測、可分級、可處理的項目。
好的 AI-SPM 要回答哪些問題？
企業可以用這份問題清單判斷自己是否需要 AI-SPM。
| 問題 | 為什麼重要 |
|---|---|
| 公司有哪些 AI 工具與 agent？ | 沒有 inventory 就沒有治理 |
| 每個 agent 的 owner 是誰？ | 出錯時要有責任歸屬 |
| Agent 能碰哪些資料？ | 控制敏感資料外洩 |
| Agent 能呼叫哪些工具？ | 控制可執行動作 |
| 正常行為基準是什麼？ | 才能偵測異常 |
| 是否保留 tool call 與輸出紀錄？ | 事後稽核需要證據 |
| 是否能停用或撤權？ | 失控時要能快速收斂 |
| 是否能接 SIEM、DLP、IAM？ | AI 風險不能變成另一座孤島 |
如果公司現在答不出這些問題，代表 AI 使用已經超過傳統政策能管理的程度。
AI-SPM 跟 Agent 365、Gemini Enterprise 有什麼關係？
Microsoft Agent 365、Gemini Enterprise Agent Platform、Chrome Enterprise MCP Server，都可以視為 AI-SPM 拼圖的一部分，但它們不是完全相同的東西。
| 類型 | 角色 |
|---|---|
| Microsoft Agent 365 | Microsoft 生態裡的 agent 管理、身份、安全與稽核 |
| Gemini Enterprise Agent Platform | Google Cloud 與 Gemini 生態裡的 agent 建置、部署與治理 |
| Chrome Enterprise MCP Server | 讓 agent 能管理 Chrome Enterprise 安全與 DLP 工作流 |
| AI-SPM | 跨工具、跨平台、跨資料流的 AI 安全姿態管理 |
如果企業只在單一生態裡運作，平台內建治理可能足夠。
但大多數企業會同時使用 Microsoft、Google、AWS、OpenAI、Anthropic、GitHub、Slack、Salesforce、ServiceNow。這時 AI-SPM 的重點就會變成跨平台盤點與風險整合。
導入 AI-SPM 前，先做這五件事
企業不一定要立刻買新工具。比較務實的順序是先建立基本盤。
1. 建 AI asset inventory
列出公司使用的 AI 工具、模型、API、agent、connector、MCP server、自動化平台與瀏覽器 agent。
2. 分級 agent 風險
依照資料敏感度與可執行動作分級。
只產生草稿的 agent 是低風險。能讀客戶資料、改 CRM、寫 code、發信、跑 shell command 的 agent 是高風險。
3. 建立資料流視圖
看資料從哪裡進來、送到哪個模型、回到哪個系統、是否被寫入外部 SaaS。
4. 建立 approval 與停用機制
高風險 tool call 需要人工 approval。Agent 出錯時，要能撤銷 token、關閉 connector、停用 MCP server 或封鎖 API key。
5. 串接既有資安系統
AI 風險應該進入 SIEM、DLP、IAM、EDR、CASB 或內部治理流程，而不是只停留在 AI 團隊自己的表格。
AI-SPM 不是禁止 AI
AI-SPM 的目的不是把 AI 鎖死。
相反，它是讓企業能更放心地擴大使用 AI。
如果沒有 AI-SPM，企業通常會走向兩個極端：
- 放任員工與團隊自行使用，形成 Shadow AI。
- 過度禁止，讓真正有價值的 AI workflow 卡住。
好的 AI-SPM 應該讓低風險使用更順，讓高風險使用更可控。
例如：
- 低風險文件摘要可以快速放行。
- 中風險 CRM 分析需要資料範圍限制。
- 高風險自動發信、修改權限、部署程式碼，需要審核與紀錄。
企業不是要問「能不能用 AI」，而是要問「這個 AI workflow 的風險等級是多少」。
2026 年為什麼會加速？
2026 年 AI-SPM 會加速，原因有三個。
第一，agent 數量增加。從 Copilot、Claude Code、Codex、Gemini、Zapier Agents、n8n，到內部自建 agent，企業很快會看不清全貌。
第二，agent 權限變大。Agent 不只讀資料，也開始呼叫工具、修改系統與完成交易。
第三，董事會開始問 ROI 與風險。AI 預算增加後，企業不只要證明有效，也要證明可控。
AI-SPM 會變成 AI ROI 的另一面：如果不能治理，AI 很難大規模落地。
結論
AI-SPM 是企業 AI 從實驗走向生產後自然出現的資安需求。
它處理的不是單一模型，而是整個 AI 使用面：工具、agent、資料流、權限、行為基準、稽核與停用。
未來企業導入 AI Agent，不能只問「這個 agent 能不能完成任務」。
還要問：「我們能不能看見它、限制它、追蹤它，並在必要時停用它？」
這就是 AI-SPM 會變重要的原因。
FAQ
AI-SPM 跟 CSPM 有什麼不同？
CSPM 管雲端設定與雲端資源安全。AI-SPM 管 AI 工具、模型、agent、資料流、connector、MCP server 與 AI workflow 的風險。兩者會重疊，但 AI-SPM 更關注 agent 行為與模型相關風險。
只有大企業需要 AI-SPM 嗎？
完整平台可能比較適合大企業，但中小企業也需要基本 AI 盤點、資料分級、工具白名單、API key 管理與高風險操作審核。
買 Agent 365 或 Gemini Enterprise 就等於有 AI-SPM 嗎？
不完全。它們能提供各自生態內的 agent 管理與治理能力，但如果公司同時使用多個雲端、多個模型與多個 SaaS，仍需要跨平台盤點與風險整合。
Sources: