隨著企業導入 AI 代理（AI Agent）處理日常系統工作，開放標準 MCP（Model Context Protocol，模型情境協定）近年迅速普及，使 AI 得以即時存取資料庫、檔案與 API。專家指出，負責串接 AI 與企業系統的 MCP 伺服器往往同時掌握大量憑證、服務帳號金鑰與 API 權杖；一旦管理不當，便可能讓整個企業暴露在風險之中。
什麼是MCP（Model Context Protocol）
MCP 由 Anthropic 率先提出，讓 AI 助理得以連接外部工具與資料，不再侷限於模型既有的知識，而能查詢資料庫、開啟檔案或呼叫 API。居中運作的 MCP 伺服器就像 AI 與目標系統之間的橋樑：它只開放特定、允許 AI 執行的動作，但也因此幾乎握有目標系統的存取憑證，這正是風險核心。
如今 AI 代理不只是產生答案，而是透過非人類身分（Non-Human Identities，NHI，如 API 金鑰與權杖）主動執行任務、擷取資料並決定呼叫哪個工具。一旦憑證外洩，攻擊者取得的不只是資料，更是能代替 AI 動手操作的能力。
MCP伺服器的五大洩密途徑
MCP 發展速度快，許多伺服器在建置與部署時，未能同步落實原本應有的資安措施。以下是幾種常見的洩密成因。
明文設定檔洩露：MCP 伺服器常將權杖與金鑰以明文存放在本機設定檔；許多環境只要貼上一段含憑證的設定字串就能啟動伺服器。這份檔案一旦留在硬碟上，容易因保管疏忽而外流，或在機器間複製、甚至不慎提交進 Git 版本庫。攻擊者只要觸及伺服器，就能讀到裡面所有憑證。
除了單一檔案外洩，
憑證分散也讓治理出現缺口。由於缺乏集中存放機密的機制，每個 AI 代理往往各自管理憑證，同樣的金鑰與權杖因此散落在各種設定檔與環境變數之中；開發、測試與正式環境之間也常出現重複副本。組織一旦無法掌握完整的憑證清單，這些憑證就很少被輪換，長期保持有效。每一份散落且長效的憑證，都是駭客可能找到的入口。
與前兩種因管理疏失而生的曝險不同，
提示注入不需要攻擊者硬闖系統。AI 代理會依照接收到的內容行動；攻擊者可能在 AI 存取的文件、客服工單或網頁裡埋入隱藏指令，讓 AI 誤判為合法命令並依循執行。透過這種手法，AI 代理可能被誘導濫用工具權限，甚至交出原本該保護的機密。
另一個常見成因是
過度授權留下的後門。開發過程中為了避免頻繁遇到授權錯誤，開發人員常先給 MCP 伺服器過寬的存取範圍，之後就沒再檢視，這類權限往往就這樣被帶進正式環境。最小權限原則（least privilege）一旦沒落實，AI 代理能觸及的範圍就會遠超任務所需；單一環節遭入侵時，曝險範圍也會隨之放大。
最後，
任何人都能發布 MCP 伺服器，這本身就是潛在的供應鏈信任風險。以 CVE-2025-6514 為例：下載次數超過 40 萬次、在用戶端執行的 OAuth 代理工具（OAuth proxy）mcp-remote，一旦連上惡意伺服器，可能觸發作業系統層級的命令注入，導致遠端程式碼執行（RCE），讓攻擊者趁機竊取代理程式所在機器上的憑證。
如何強化MCP伺服器的機密防護
專家也提出幾項建議：
- 停止在設定檔、環境變數與原始碼中硬編憑證，改為集中存放於統一的受管理機密庫，讓 AI 代理在執行當下只從單一來源提取所需憑證。
- 採用短期有效憑證並自動輪換，縮小憑證外洩後可能被利用的時間窗口。
- 落實最小權限原則，讓每個 AI 代理只能存取任務所需的系統與資料。
- 對敏感操作保留人工確認機制；擷取未遮罩機密、刪除紀錄或存取正式環境前，都需取得明確核准。
- 採用零信任、零知識架構加密機密資料，確保機密僅在使用當下才會被解密；即使儲存平台本身遭入侵，攻擊者也無法讀取內容。
- 完整記錄並稽核 AI 代理的所有操作，方便日後合規查核與事件調查。
- 建立 MCP 伺服器完整清單，找出組織內未被納管、卻仍持續握有有效憑證的影子 AI（shadow AI）。
MCP 為企業環境新增了一層介於 AI 代理與關鍵系統之間的中介層，同時也握有存取這些系統的憑證。組織應以看待任何持有機密的正式系統的同等標準，落實 MCP 伺服器的資安治理，及早集中管理憑證，並控管每個代理可觸及的範圍。
本文轉載自 TheHackerNews。