當前，各行業(yè)組織紛紛加速布局 AI 驅(qū)動型基礎(chǔ)設(shè)施，全力打造 “AI 為先” 的運營模式。然而，安全防護建設(shè)卻明顯滯后，成為一大短板?；诖笮驼Z言模型（LLMs）和多組件協(xié)議（MCP）構(gòu)建的多智能體系統(tǒng)，雖在效率提升、業(yè)務(wù)拓展上潛力巨大，但也催生了傳統(tǒng)安全工具無法應(yīng)對的新型漏洞，給 AI 環(huán)境安全帶來嚴峻挑戰(zhàn)。

為解決這一痛點，網(wǎng)絡(luò)安全領(lǐng)域企業(yè) Wallarm 密切關(guān)注新興攻擊面的防護指南，尤其參考了近期發(fā)布的《OWASP 多智能體系統(tǒng)威脅建模指南 v1.0》，結(jié)合實際應(yīng)用場景，編制出一份實用的 MCP 安全清單。

這份清單精準聚焦多智能體系統(tǒng)中的 11 類核心安全風險，不僅清晰剖析了各類風險的危害，還給出了針對性的防御方案。比如，針對 “意外的遠程代碼執(zhí)行與代碼攻擊”，提出權(quán)限限制、環(huán)境隔離、執(zhí)行控制等多維度防護手段；面對 “模型不穩(wěn)定導致 MCP 請求不一致” 問題，從調(diào)用限制、速率管控、提示優(yōu)化三方面制定應(yīng)對策略。此外，清單還涵蓋工具濫用、客戶端仿冒、通信不安全、資源過載、服務(wù)賬戶信息泄露、日志操縱、權(quán)限泄露、服務(wù)器權(quán)限隔離不足、生態(tài)系統(tǒng)中惡意服務(wù)器等風險，對應(yīng)的防御措施涉及驗證監(jiān)控、身份管理、加密通信、資源管控、敏感信息保護等多個層面。

有了這份 MCP 安全清單，各組織在推進 AI 基礎(chǔ)設(shè)施建設(shè)時，能更精準地識別安全隱患、部署防護措施，從而有效守護原生 AI 環(huán)境安全，打造兼具靈活性與安全性的 AI 驅(qū)動型基礎(chǔ)設(shè)施。

1. T11—— 意外的遠程代碼執(zhí)行與代碼攻擊

在原生 AI 系統(tǒng)中，智能體并非僅對查詢做出響應(yīng)，它們還會生成并執(zhí)行代碼。這為隱蔽而危險的提示注入攻擊打開了方便之門。若攻擊者在提示中注入操作系統(tǒng)命令等惡意指令，大型語言模型可能在不知情的情況下嵌入并執(zhí)行這些指令，造成嚴重安全威脅。緩解措施可從多維度實施：

• 權(quán)限限制：僅在絕對必要時允許代碼生成；應(yīng)用最小權(quán)限原則，僅授予完成任務(wù)所需的最低權(quán)限；限制對文件系統(tǒng)和網(wǎng)絡(luò)等系統(tǒng)資源的訪問。
• 環(huán)境隔離：對執(zhí)行環(huán)境進行沙箱隔離，防止主機級別的安全危害。
• 執(zhí)行控制：實施執(zhí)行控制策略，對具有提升權(quán)限的 AI 生成代碼進行標記并暫停執(zhí)行，等待人工審核；限制 CPU、內(nèi)存和執(zhí)行時間，使其與任務(wù)范圍相匹配；使用允許列表而非阻止列表來明確規(guī)定允許的操作；在智能體代碼和工具中始終遵循安全編碼規(guī)范。

2. T26—— 模型不穩(wěn)定導致 MCP 請求不一致

模型不穩(wěn)定易引發(fā) MCP 客戶端向 MCP 服務(wù)器發(fā)送不一致或異常請求，干擾系統(tǒng)正常操作。例如，模型執(zhí)行構(gòu)建 SQL 查詢等任務(wù)出錯時，可能反復(fù)重試錯誤指令，給后端帶來過多流量，進而演變?yōu)榫芙^服務(wù)問題。由于模型難以及時察覺自身錯誤，基礎(chǔ)設(shè)施需具備錯誤識別能力，具體防范措施如下：

• 調(diào)用限制：按會話或任務(wù)對工具調(diào)用的頻率和數(shù)量加以限制。
• 速率管控：根據(jù)網(wǎng)絡(luò)狀況和智能體活動實施自適應(yīng)速率限制。
• 提示優(yōu)化：構(gòu)建具有明確格式和邏輯步驟的提示；使用思維鏈（CoT）提示法（一種引導模型進行逐步推理的方法），減少因跳躍式推理導致的不一致性。

3. T2—— 通過 MCP 實現(xiàn)的工具濫用

在 MCP 環(huán)境中運行的智能體能夠訪問工具 API 執(zhí)行計算、轉(zhuǎn)換或業(yè)務(wù)操作。但若缺乏適當驗證，智能體可能被誘騙使用錯誤工具執(zhí)行任務(wù)，改變輸出結(jié)果或破壞信任。為緩解這一風險，可從多個層面著手：

• 驗證與監(jiān)控層面：實施嚴格的工具訪問驗證，對每次調(diào)用進行驗證；監(jiān)控工具使用模式，及時發(fā)現(xiàn)異常情況。
• 權(quán)限與范圍層面：為不同工具配置不同權(quán)限集；限制每個工具的訪問范圍，使其僅能獲取所需資源。
• 隔離與安全層面：在隔離環(huán)境中運行工具，防止交叉影響；驗證輸入，限制函數(shù)范圍，阻止危險操作。
• 管理與規(guī)范層面：防止命名沖突和未授權(quán)的工具間訪問；對工具調(diào)用的頻率和數(shù)量加以限制；在文檔中包含必要的類型、計量單位和運行時驗證要求，確保工具正確使用。

4. T40——MCP 客戶端仿冒：身份管理問題

在分布式智能體生態(tài)系統(tǒng)中，身份至關(guān)重要。若惡意攻擊者獲取有效憑據(jù)，或系統(tǒng)未能正確驗證智能體身份，他們可能訪問特權(quán)工具或數(shù)據(jù)。為防范這一風險，需構(gòu)建完善的身份管理體系：

• 開發(fā)強大的身份驗證框架，確保身份不與單一憑據(jù)相關(guān)聯(lián)。
• 使用行為分析檢測智能體活動中的異常情況。
• 實施可隨時間調(diào)整且能抵御操縱的智能體信譽系統(tǒng)。
• 強制使用公鑰基礎(chǔ)設(shè)施（PKI），智能體必須通過由可信證書頒發(fā)機構(gòu)（CA）頒發(fā)的數(shù)字證書進行身份驗證，PKI 通過證書鏈驗證機制有效確保證書的真實性和完整性。
• 驗證私鑰所有權(quán)，以確認智能體身份。
• 使用具有智能體間身份驗證功能的安全通信協(xié)議。
• 實施沙箱隔離和政策執(zhí)行措施，限制已被入侵智能體的影響范圍。

5. T30——MCP 實施中的通信不安全問題

若 JSON-RPC 和 SSE 等通信協(xié)議實施不當，攻擊者可能攔截、修改或注入傳輸中的數(shù)據(jù)。例如，MCP 客戶端與服務(wù)器間的請求和響應(yīng)通過未加密的 HTTP 發(fā)送時，攻擊者可能篡改響應(yīng)，導致大型語言模型輸出無效結(jié)果。緩解這一風險需強化通信安全：

• 使用 HTTPS 和雙向 TLS（mTLS）等安全通信協(xié)議。
• 驗證證書屬性和頒發(fā)機構(gòu)，防止中間人攻擊。
• 對所有與 MCP 相關(guān)的通信強制實施加密和身份驗證。
• 持續(xù)監(jiān)控流量，警惕異常模式、有效負載篡改或注入嘗試。

6. T4—— 資源過載風險

攻擊者可能通過大量 CPU、內(nèi)存或服務(wù)請求使 AI 系統(tǒng)過載，降低系統(tǒng)性能或?qū)е戮芙^服務(wù)。例如，惡意攻擊者可能觸發(fā) 100 次大型文件讀取操作，或發(fā)送 PostgreSQL 的 pg_sleep (600) 睡眠命令凍結(jié)數(shù)據(jù)庫操作?？赏ㄟ^以下方式緩解風險：

• 部署資源管理控制措施，合理分配 CPU、內(nèi)存和 I/O 預(yù)算。
• 結(jié)合實時監(jiān)控實施自適應(yīng)擴展。
• 按智能體會話實施 AI 速率限制政策。
• 對提示大小、任務(wù)持續(xù)時間和重試次數(shù)設(shè)置嚴格配額。

7. T21—— 服務(wù)賬戶信息泄露隱患

MCP 服務(wù)賬戶配置不當可能導致憑據(jù)通過工具、日志或文件訪問泄露。例如，連接到讀取環(huán)境變量工具的大型語言模型可能無意中泄露 AWS 憑據(jù)。防范措施包括：

• 自動對個人身份信息（PII）和憑據(jù)進行脫敏處理，尤其是從日志或智能體輸出中自動檢測并隱藏密鑰、令牌等敏感信息。
• 按角色和上下文使用細粒度的訪問控制。
• 定期輪換憑據(jù)，縮短可能被入侵的時間窗口。
• 設(shè)置防護措施，防止憑據(jù)共享或意外泄露。
• 對所有訪問令牌和 API 應(yīng)用最小權(quán)限原則。

8. T22—— 選擇性日志操縱問題

攻擊者可能操縱日志行為，隱藏惡意活動或用無用事件淹沒系統(tǒng)。例如，他們可能將日志級別更改為 DEBUG 或 TRACE 以隱藏攻擊，用無用事件使日志系統(tǒng)過載，或通過配置操縱禁用日志功能。緩解策略如下：

• 實施日志的加密驗證，確保日志完整性。
• 使用具有嚴格訪問控制的不可變?nèi)罩敬鎯?，防止日志被篡改或刪除。
• 通過元數(shù)據(jù)豐富日志內(nèi)容，提高可見性。
• 部署異常檢測系統(tǒng)，充分考慮 AI 智能體的非確定性行為。

9. T3—— 權(quán)限泄露風險

攻擊者可能通過配置錯誤、提示注入或訪問邏輯操縱來提升權(quán)限。例如，某個提示可能說服大型語言模型向攻擊者授予管理員權(quán)限，或惡意用戶可能將管理員組權(quán)限惡意降級至普通用戶訪問級別。為緩解這一風險：

• 在所有層級實施細粒度訪問控制。
• 動態(tài)驗證角色變更，并記錄所有權(quán)限提升操作。
• 除非預(yù)先獲得批準，否則阻止智能體之間的權(quán)限委托。
• 對高風險操作實施人工驗證。
• 使用分層防御措施防止提示注入和權(quán)限濫用。

10. T45——MCP 服務(wù)器權(quán)限隔離不足：身份管理問題

如果 MCP 服務(wù)器對主機資源或網(wǎng)絡(luò)擁有過多訪問權(quán)限，安全入侵可能在系統(tǒng)間蔓延。例如，MCP 服務(wù)器上某個易受攻擊的工具允許路徑遍歷（一種常見 Web 漏洞，攻擊者可通過構(gòu)造特殊路徑訪問未授權(quán)文件），可能泄露其他服務(wù)或 MCP 環(huán)境的機密信息。防止此類情況需做好權(quán)限隔離：

• 在服務(wù)器級別應(yīng)用最小權(quán)限原則。
• 通過沙箱隔離和資源邊界隔離智能體和工具。
• 實施運行時監(jiān)控和嚴格的訪問執(zhí)行措施，防止權(quán)限提升或橫向移動。

11. T47—— 生態(tài)系統(tǒng)中的惡意 MCP 服務(wù)器：智能體身份管理問題

攻擊者可能部署惡意 MCP 服務(wù)器偽裝成合法服務(wù)器，連接到該惡意服務(wù)器的智能體隨后會被入侵。這是針對 MCP 信任模型的生態(tài)系統(tǒng)級攻擊。緩解這一風險需強化身份驗證與信任機制：

• 使用去中心化標識符（DIDs）在服務(wù)間進行身份驗證，DIDs 是一種去中心化的身份標識方式，不依賴中心化機構(gòu)即可實現(xiàn)身份驗證。
• 應(yīng)用雙向 TLS 和 DID 簽名消息等安全身份驗證協(xié)議。
• 通過帶時間戳的憑據(jù)驗證防止重放攻擊。
• 維護可適應(yīng)動態(tài)智能體屬性的可信智能體注冊表。

結(jié)語

如果沒有強大的安全模型，MCP 和多智能體系統(tǒng)的靈活性就會變得脆弱不堪。通過遵循 OWASP 的威脅建模指南和上述建議，各組織能夠打造出既安全又智能的 AI 基礎(chǔ)設(shè)施。

原文鏈接:

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）