全面 MCP 安全清單：守護 AI 驅動型基礎設施安全
當前，各行業組織紛紛加速布局 AI 驅動型基礎設施，全力打造 “AI 為先” 的運營模式。然而，安全防護建設卻明顯滯后，成為一大短板。基于大型語言模型（LLMs）和多組件協議（MCP）構建的多智能體系統，雖在效率提升、業務拓展上潛力巨大，但也催生了傳統安全工具無法應對的新型漏洞，給 AI 環境安全帶來嚴峻挑戰。
為解決這一痛點，網絡安全領域企業 Wallarm 密切關注新興攻擊面的防護指南，尤其參考了近期發布的《OWASP 多智能體系統威脅建模指南 v1.0》，結合實際應用場景，編制出一份實用的 MCP 安全清單。
這份清單精準聚焦多智能體系統中的 11 類核心安全風險，不僅清晰剖析了各類風險的危害，還給出了針對性的防御方案。比如，針對 “意外的遠程代碼執行與代碼攻擊”，提出權限限制、環境隔離、執行控制等多維度防護手段；面對 “模型不穩定導致 MCP 請求不一致” 問題，從調用限制、速率管控、提示優化三方面制定應對策略。此外，清單還涵蓋工具濫用、客戶端仿冒、通信不安全、資源過載、服務賬戶信息泄露、日志操縱、權限泄露、服務器權限隔離不足、生態系統中惡意服務器等風險，對應的防御措施涉及驗證監控、身份管理、加密通信、資源管控、敏感信息保護等多個層面。
有了這份 MCP 安全清單，各組織在推進 AI 基礎設施建設時，能更精準地識別安全隱患、部署防護措施，從而有效守護原生 AI 環境安全，打造兼具靈活性與安全性的 AI 驅動型基礎設施。
1. T11—— 意外的遠程代碼執行與代碼攻擊
在原生 AI 系統中，智能體并非僅對查詢做出響應，它們還會生成并執行代碼。這為隱蔽而危險的提示注入攻擊打開了方便之門。若攻擊者在提示中注入操作系統命令等惡意指令，大型語言模型可能在不知情的情況下嵌入并執行這些指令，造成嚴重安全威脅。緩解措施可從多維度實施：
- 權限限制：僅在絕對必要時允許代碼生成；應用最小權限原則，僅授予完成任務所需的最低權限；限制對文件系統和網絡等系統資源的訪問。
- 環境隔離：對執行環境進行沙箱隔離，防止主機級別的安全危害。
- 執行控制：實施執行控制策略，對具有提升權限的 AI 生成代碼進行標記并暫停執行，等待人工審核；限制 CPU、內存和執行時間，使其與任務范圍相匹配；使用允許列表而非阻止列表來明確規定允許的操作；在智能體代碼和工具中始終遵循安全編碼規范。
2. T26—— 模型不穩定導致 MCP 請求不一致
模型不穩定易引發 MCP 客戶端向 MCP 服務器發送不一致或異常請求，干擾系統正常操作。例如，模型執行構建 SQL 查詢等任務出錯時，可能反復重試錯誤指令，給后端帶來過多流量，進而演變為拒絕服務問題。由于模型難以及時察覺自身錯誤，基礎設施需具備錯誤識別能力，具體防范措施如下：
- 調用限制：按會話或任務對工具調用的頻率和數量加以限制。
- 速率管控：根據網絡狀況和智能體活動實施自適應速率限制。
- 提示優化：構建具有明確格式和邏輯步驟的提示；使用思維鏈（CoT）提示法（一種引導模型進行逐步推理的方法），減少因跳躍式推理導致的不一致性。
3. T2—— 通過 MCP 實現的工具濫用
在 MCP 環境中運行的智能體能夠訪問工具 API 執行計算、轉換或業務操作。但若缺乏適當驗證，智能體可能被誘騙使用錯誤工具執行任務，改變輸出結果或破壞信任。為緩解這一風險，可從多個層面著手：
- 驗證與監控層面：實施嚴格的工具訪問驗證，對每次調用進行驗證；監控工具使用模式，及時發現異常情況。
- 權限與范圍層面：為不同工具配置不同權限集；限制每個工具的訪問范圍，使其僅能獲取所需資源。
- 隔離與安全層面：在隔離環境中運行工具，防止交叉影響；驗證輸入，限制函數范圍，阻止危險操作。
- 管理與規范層面：防止命名沖突和未授權的工具間訪問；對工具調用的頻率和數量加以限制；在文檔中包含必要的類型、計量單位和運行時驗證要求，確保工具正確使用。
4. T40——MCP 客戶端仿冒：身份管理問題
在分布式智能體生態系統中，身份至關重要。若惡意攻擊者獲取有效憑據，或系統未能正確驗證智能體身份，他們可能訪問特權工具或數據。為防范這一風險，需構建完善的身份管理體系：
- 開發強大的身份驗證框架，確保身份不與單一憑據相關聯。
- 使用行為分析檢測智能體活動中的異常情況。
- 實施可隨時間調整且能抵御操縱的智能體信譽系統。
- 強制使用公鑰基礎設施（PKI），智能體必須通過由可信證書頒發機構（CA）頒發的數字證書進行身份驗證，PKI 通過證書鏈驗證機制有效確保證書的真實性和完整性。
- 驗證私鑰所有權，以確認智能體身份。
- 使用具有智能體間身份驗證功能的安全通信協議。
- 實施沙箱隔離和政策執行措施，限制已被入侵智能體的影響范圍。
5. T30——MCP 實施中的通信不安全問題
若 JSON-RPC 和 SSE 等通信協議實施不當，攻擊者可能攔截、修改或注入傳輸中的數據。例如，MCP 客戶端與服務器間的請求和響應通過未加密的 HTTP 發送時，攻擊者可能篡改響應，導致大型語言模型輸出無效結果。緩解這一風險需強化通信安全：
- 使用 HTTPS 和雙向 TLS（mTLS）等安全通信協議。
- 驗證證書屬性和頒發機構，防止中間人攻擊。
- 對所有與 MCP 相關的通信強制實施加密和身份驗證。
- 持續監控流量，警惕異常模式、有效負載篡改或注入嘗試。
6. T4—— 資源過載風險
攻擊者可能通過大量 CPU、內存或服務請求使 AI 系統過載，降低系統性能或導致拒絕服務。例如，惡意攻擊者可能觸發 100 次大型文件讀取操作，或發送 PostgreSQL 的 pg_sleep (600) 睡眠命令凍結數據庫操作。可通過以下方式緩解風險：
- 部署資源管理控制措施，合理分配 CPU、內存和 I/O 預算。
- 結合實時監控實施自適應擴展。
- 按智能體會話實施 AI 速率限制政策。
- 對提示大小、任務持續時間和重試次數設置嚴格配額。
7. T21—— 服務賬戶信息泄露隱患
MCP 服務賬戶配置不當可能導致憑據通過工具、日志或文件訪問泄露。例如，連接到讀取環境變量工具的大型語言模型可能無意中泄露 AWS 憑據。防范措施包括：
- 自動對個人身份信息（PII）和憑據進行脫敏處理，尤其是從日志或智能體輸出中自動檢測并隱藏密鑰、令牌等敏感信息。
- 按角色和上下文使用細粒度的訪問控制。
- 定期輪換憑據，縮短可能被入侵的時間窗口。
- 設置防護措施，防止憑據共享或意外泄露。
- 對所有訪問令牌和 API 應用最小權限原則。
8. T22—— 選擇性日志操縱問題
攻擊者可能操縱日志行為，隱藏惡意活動或用無用事件淹沒系統。例如，他們可能將日志級別更改為 DEBUG 或 TRACE 以隱藏攻擊，用無用事件使日志系統過載，或通過配置操縱禁用日志功能。緩解策略如下：
- 實施日志的加密驗證，確保日志完整性。
- 使用具有嚴格訪問控制的不可變日志存儲，防止日志被篡改或刪除。
- 通過元數據豐富日志內容，提高可見性。
- 部署異常檢測系統，充分考慮 AI 智能體的非確定性行為。
9. T3—— 權限泄露風險
攻擊者可能通過配置錯誤、提示注入或訪問邏輯操縱來提升權限。例如，某個提示可能說服大型語言模型向攻擊者授予管理員權限，或惡意用戶可能將管理員組權限惡意降級至普通用戶訪問級別。為緩解這一風險：
- 在所有層級實施細粒度訪問控制。
- 動態驗證角色變更，并記錄所有權限提升操作。
- 除非預先獲得批準，否則阻止智能體之間的權限委托。
- 對高風險操作實施人工驗證。
- 使用分層防御措施防止提示注入和權限濫用。
10. T45——MCP 服務器權限隔離不足：身份管理問題
如果 MCP 服務器對主機資源或網絡擁有過多訪問權限，安全入侵可能在系統間蔓延。例如，MCP 服務器上某個易受攻擊的工具允許路徑遍歷（一種常見 Web 漏洞，攻擊者可通過構造特殊路徑訪問未授權文件），可能泄露其他服務或 MCP 環境的機密信息。防止此類情況需做好權限隔離：
- 在服務器級別應用最小權限原則。
- 通過沙箱隔離和資源邊界隔離智能體和工具。
- 實施運行時監控和嚴格的訪問執行措施，防止權限提升或橫向移動。
11. T47—— 生態系統中的惡意 MCP 服務器：智能體身份管理問題
攻擊者可能部署惡意 MCP 服務器偽裝成合法服務器，連接到該惡意服務器的智能體隨后會被入侵。這是針對 MCP 信任模型的生態系統級攻擊。緩解這一風險需強化身份驗證與信任機制：
- 使用去中心化標識符（DIDs）在服務間進行身份驗證，DIDs 是一種去中心化的身份標識方式，不依賴中心化機構即可實現身份驗證。
- 應用雙向 TLS 和 DID 簽名消息等安全身份驗證協議。
- 通過帶時間戳的憑據驗證防止重放攻擊。
- 維護可適應動態智能體屬性的可信智能體注冊表。
結語
如果沒有強大的安全模型，MCP 和多智能體系統的靈活性就會變得脆弱不堪。通過遵循 OWASP 的威脅建模指南和上述建議，各組織能夠打造出既安全又智能的 AI 基礎設施。
原文鏈接:
https://securityboulevard.com/2025/08/comprehensive-mcp-security-checklist-protecting-your-ai-powered-infrastructure/?utm_source=rss&utm_medium=rss&utm_campaign=comprehensive-mcp-security-checklist-protecting-your-ai-powered-infrastructure）
