Microsoft Defender 研究團隊在 ２０２６ 年 ５ 月提醒一個很實際的 AI 安全問題：很多 AI app 的風險不是來自高深 zero-day，而是 misconfiguration。
也就是公開端點、弱認證、過大權限、Kubernetes service 暴露、內部 dashboard 沒保護好。
這聽起來不像新問題，但放進 AI agent 場景後，衝擊會變大。因為 AI app 常常接了模型、資料、工具、內部 API、檔案、向量資料庫和自動化權限。
一個原本只是「測試用 dashboard 暴露」的問題，可能變成 RCE、憑證竊取或資料外洩。
AI app misconfiguration 是什麼？
Misconfiguration 不是漏洞程式碼本身，而是部署方式讓強大功能變成可被濫用的入口。
常見例子：
- 開發用 UI 直接暴露到網路。
- 沒有 authentication。
- 只有弱密碼或共用 token。
- Kubernetes LoadBalancer 開錯。
- 內部 dashboard 可從外網存取。
- Agent tool endpoint 沒有 authorization。
- Service account 權限過大。
- Demo container 直接跑 production data。
這些問題不需要攻擊者發明新 exploit。只要找到可存取入口，就可能開始操作。
為什麼 AI app 特別危險？
傳統 dashboard 暴露，可能只是看得到監控資料。
AI app 暴露，可能代表攻擊者能：
- 讀 prompt history。
- 呼叫 model。
- 操作 agent tools。
- 讀向量資料庫。
- 連內部 API。
- 下載檔案。
- 執行 notebook 或 code。
- 取得 cloud credentials。
Agentic workload 讓風險從「資訊外洩」升級成「能做動作」。
Microsoft 提到哪些高風險類型？
Microsoft 提到在野外觀察到多種 AI app 或平台 misconfiguration，包括：
- Agentgateway。
- MLRun。
- Numaflow。
- OpenLIT。
- Microsoft Agent Framework Dev UI。
- Nvidia Nemo Agent Toolkit。
- Marimo。
- Comfy UI。
- Ray Dashboard。
- MCP Hub Dashboard。
這些名稱不代表工具本身不能用。
真正的重點是：許多 AI 開發工具預設是為本機、內網、開發或受控環境設計，一旦被公開到網路，風險模型會完全不同。
公開端點必須是安全決策
很多事故不是因為團隊決定公開服務，而是「暫時開一下」之後忘記關。
AI service 是否公開，應該有明確決策：
| 問題 | 要求 |
|---|---|
| 是否需要 public access？ | 不需要就只放內網或 private endpoint |
| 是否有 authentication？ | 所有端點都要驗證，不只 UI |
| 是否有 authorization？ | 不同角色只能做必要操作 |
| 是否有 network controls？ | 限 IP、VPN、Zero Trust access |
| 是否有 audit log？ | 記錄誰存取、做了什麼 |
不要把「沒人知道這個 URL」當安全設計。
Kubernetes 要特別小心
Microsoft 提到很多 AI workload 跑在 cloud-native infrastructure，Kubernetes 是常見操作層。
這裡最容易出現的問題是 service exposure。
例如開發者為了測試，把 service type 改成 LoadBalancer，讓 AI dashboard 或 agent endpoint 暴露到外網。測完沒有收回，攻擊面就留在那裡。
建議至少做：
- Kubernetes service exposure audit。
- NetworkPolicy。
- Ingress authentication。
- Secret scanning。
- Workload identity 最小權限。
- 禁止 dev UI 上 production namespace。
- Defender／CSPM 類工具監控公開 service。
AI app 部署安全 checklist
部署 AI app 或 agent 前，至少檢查：
- 所有 UI、API、tool endpoint 是否需要登入。
- 是否有 role-based authorization。
- Agent 使用的 service account 是否最小權限。
- Sandbox 是否隔離。
- 是否禁止直接連 production data。
- Prompt history 和 tool logs 是否含敏感資料。
- Kubernetes service 是否暴露到外網。
- 是否有 audit log。
- 是否有 egress control。
- 是否能快速停用 agent 或 revoke token。
這些基本功比模型選型更能降低事故風險。
結論
AI app misconfiguration 會是 ２０２６ 年企業 AI 的高頻風險。
原因很簡單：大家都在快速部署 agent、dashboard、RAG、notebook、MCP server 和自動化工具，但很多部署還停留在實驗心態。
只要 AI system 能接資料與工具，它就不是玩具。它應該被當成高影響 workload 部署、監控和治理。