部落格 發布於 AIA: 2026年5月15日

AI 應用錯誤設定：公開 agent 端點如何變成遠端程式碼執行漏洞（RCE）和憑證外洩入口

Microsoft Defender Security Research 發現，某些 AI 應用和 agent 服務（例如遠端 MCP server、Mage AI、kagent 和 Microsoft AutoGen Studio）在網路上可以被公開存取，卻沒有把登入驗證、權限控管和後端服務帳號設定好。這樣一來，攻擊者不一定要找零日漏洞；只要連到公開的介面或 API，就可能操作內部工具、執行 shell 命令、部署 Kubernetes 工作負載，或讀到 AI 服務的 API key。這篇的重點很直接了當：只要 AI 應用是公開對外提供服務的，就要當正式系統管理，不能把測試時方便使用的預設設定直接拿去上線。

Remote Code ExecutionCredential TheftAI Deployment SecurityAgentic AIKubernetes
8 項對應的 AIDEFEND 防禦手法
來源: When configuration becomes a vulnerability: Exploitable misconfigurations in AI apps 
作者 Microsoft Defender Security Research Team and Yossi Weizman · 原文發布: 2026年5月14日

威脅分析

  • 攻擊起點不是 zero-day，而是一個可被公開存取的 AI 服務。 Microsoft 把問題定義成「公開暴露」加上「驗證和授權不足」。一旦 AI UI、API 或 agent 端點能從網際網路連到，攻擊者可能只要送正常請求，就能碰到背後的工具、資料或執行功能。
  • 遠端 MCP server 可能直接暴露內部工具。 Microsoft 觀察到多個遠端 MCP server 沒有啟用驗證。未驗證的呼叫者可以直接操作一些內部系統，例如客服或 IT 申請資料、人資系統和私有程式碼 repo；真正麻煩的是，這些操作不是用呼叫者自己的權限執行，而是借用 MCP server 本身已經拿到的權限。也就是說，攻擊者不需要先拿到那些內部系統帳號，只要連上這個未驗證的 MCP 入口，就可能用該 MCP server 的身分做事。
  • Mage AI 的預設部署可能把管理介面公開出去。 Microsoft 指出，照官方 Helm chart 部署時，Mage AI 可能透過 Kubernetes LoadBalancer 變成網際網路上可存取的服務，而且預設沒有啟用登入驗證。更嚴重的是，這個管理介面裡本來就有 shell 命令執行功能；所以只要介面被公開，攻擊者不登入也可能遠端執行命令。再加上掛載的服務帳號（service account）權限很高，影響範圍可能擴大到整個 cluster。
  • kagent 如果被公開，就可能變成 Kubernetes 控制入口。 kagent 預設不是公開服務，但預設也沒有登入驗證。所以只要部署時不小心把它公開出去，匿名使用者就能要求 AI agent 部署高權限 pod、從其他 workload 偷憑證、設定惡意模型或 agent，甚至從 cluster 往雲端資源橫向移動。
  • Microsoft AutoGen Studio 在 multi-agent 工作流程裡也有同樣模式。 Microsoft 指出，Microsoft AutoGen Studio 預設沒有啟用登入驗證；它預設不會對外公開，但如果實例被公開，攻擊者就可能竄改元件、部署惡意 agent 設定，或直接取出連到 AI 服務的明文 API key。
  • 共同教訓是：錯誤設定本身就是攻擊路徑。 這些案例不需要很高深的漏洞利用。真正危險的組合是：服務公開在網路上、沒有驗證、背後使用的服務帳號權限過大，又有可執行功能；團隊卻仍把這些 AI 工作負載當成實驗工具，沒有同步建立正式上線該有的監控和安全基準。

適用的 8 項 AIDEFEND 防禦手法

AID-M-005.002
Configuration Baseline Definition & Posture SLOs (Service Level Objectives)
極高
這是最核心的控制，因為這篇描述的問題，核心就是部署方式不安全：服務直接對外、驗證預設沒開、服務帳號權限過大、AI 工具沒有照核准基準上線。安全基準應該明確定義哪些 AI 服務可以公開、哪些必須留在內網、必須啟用什麼驗證、哪些 Helm 預設值不能用、Kubernetes 服務帳號的權限上限，以及不符合規則的 manifest 在部署前就要被擋下來。
AID-H-004.002
Service & API Authentication
極高
這些暴露之所以能被利用，是因為 AI UI、API、MCP 端點和內部工具接受未驗證或驗證不足的存取。服務與 API 驗證應該要求每一個 AI 控制面都實施身分驗證，包括遠端 MCP server、AutoGen Studio API、Mage AI UI、模型設定端點，以及任何能碰到工具或 secrets 的服務間呼叫。
AID-H-019.004
Intent-Based Dynamic Capability Scoping
極高
Microsoft 的 MCP 案例尤其清楚：工具不是用使用者或 agent 當下任務所需的窄範圍權限執行，而是直接用 server 已經拿到的高權限執行。每個工作階段都應該只拿到當下需要的工具、Kubernetes 動作、repo、人資紀錄、客服或 IT 申請資料和模型設定權限，而不是讓任何呼叫者繼承後端的完整權限。
AID-M-009.003
Agent Identity, Delegation Lineage & Runtime Authorization
高
公開的 AI agent 只要部署 pod、讀取 secret、修改模型設定或呼叫內部系統，防禦方就需要知道是哪個 agent 執行個體在動作、基於誰的授權、拿到哪個委派範圍。把動作綁到可追責的執行期身分，可以避免高風險操作最後只留下一個籠統的服務帳號或匿名 Web 請求。
AID-I-002.001
Internal AI Network Segmentation
高
許多案例之所以變嚴重，是因為 AI 控制面被放在錯誤的網路邊界上。內部 MCP server、資料流程 UI、Kubernetes agent 控制台和 multi-agent 開發介面，應該放在私有網路路徑、service mesh 政策和 namespace 層級區隔後面，避免公開元件可以直接碰到高權限工具或 secrets。
AID-H-026.001
Dangerous Construct Detection & Blocking
高
Mage AI 公開的 Web 介面含有 shell 命令執行功能，所以一個沒有驗證的部署就直接變成工作負載裡的 RCE。只要 AI 平台包含 Jupyter Notebook 這類可直接執行程式碼的介面、shell 面板、程式碼 runner、工作流程步驟或 agent 工具執行，就要擋掉危險語法和危險命令路徑，不該讓公開介面變成任意命令執行入口。
AID-D-004.003
Runtime Configuration & Policy Drift Detection and Monitoring
高
即使部署前已經訂好安全基準，上線後也要持續確認實際設定沒有跑掉。例如 Kubernetes Service 被改成公開 LoadBalancer、登入驗證被關掉、Helm chart 設定值不再符合基準，或新的 AI 開發介面被開到未核准的網路位置。設定偏移偵測的目的，就是在這些問題剛出現時就提出有證據的警示，而不是等服務已經默默公開在網路上才發現。
AID-D-005.002
Security Monitoring & Alerting for AI
中
這些攻擊路徑會留下可偵測的行為：匿名請求打到 AI 控制 UI、未知 client 呼叫 MCP 工具、資料流程平台出現 shell 命令、高權限 pod 被建立、Kubernetes secret 被讀取、AI provider key 被存取、模型設定遭變更。AI-aware 監控應該對這些行為示警，避免一個錯誤設定的端點讓攻擊者長期留在系統裡。

身為資安防禦者，我們應該這麼做

  • 盤點所有透過 Kubernetes、入口流量控制器（ingress controller）、LoadBalancer、通道或公有雲端點公開的 AI 與 agent 服務。範圍要包含遠端 MCP server、Mage AI、kagent、AutoGen Studio、Jupyter Notebook 這類可執行程式碼的介面、管理介面和內部開發介面。
  • 每個 AI 介面、API、MCP 端點和工具閘道都要啟用驗證與授權。如果 AI 服務真的需要公開，必須放在 SSO、網路限制和明確負責人核准後面。
  • 檢查 AI 工作負載的 Helm 設定值（values）、Kubernetes Service、ingress 規則和服務帳號。擋掉未驗證的公開 LoadBalancer，移除 cluster-admin 這類過大綁定，並把每個服務帳號限制在它真正需要的命名空間、Kubernetes Secret 和 API 動作。
  • 把 API key 和模型供應商憑證移出 agent 設定畫面和明文應用儲存。改用受管 secrets 儲存服務；只要曾經透過 AutoGen Studio 或 kagent 類似設定暴露，就要輪替；同時避免匿名使用者讀到模型設定。
  • 停用或嚴格管制 shell 執行、Jupyter Notebook 這類介面的程式碼執行、工作流程裡的程式碼步驟，以及能部署工作負載或執行命令的 agent 工具路徑。這些都是程式碼執行面，不是一般應用功能。
  • 新增偵測規則：新的公開 Kubernetes 服務、匿名 agent 動作、第一次 MCP 工具呼叫、高權限 pod 部署、Kubernetes Secret 讀取、AI 應用執行 shell 命令，以及可疑 AI 介面活動後的對外連線。

結論

Microsoft 這篇報告提醒我們，AI 安全很多時候不是等到模型看到提示詞（prompt）才失守。一個公開的 AI 端點，只要沒有驗證、背後使用的服務帳號權限過大，旁邊又有 shell 或 agent 工具，就已經是一條攻擊路徑。AIDEFEND  在這裡對應到最重要的防禦手段和觀念：建立安全部署基準、落實服務驗證、縮小工具權限、讓 agent 身分可追責、做好網路區隔、避免不安全的程式碼執行、偵測設定偏移，並對 AI 工作負載加上專門的監控。