部署安全的企業級Agentic AI：MCP+Agent2Agent

作者：岱軍 2025-07-04 07:21:49

LLM、AI 代理及其不斷發展的工具生態系統（如?Model Context Protocol (MCP)[2]）的引入，為各種新的用例打開了大門。盡管如此，它們也給生產中的安全帶來了獨特的挑戰，讓我們對如何為用戶創建安全可靠的應用程序留下了許多未解之謎。

企業級 Agentic AI 安全部署：利用 MCP 擴展 LLM 應用面臨 Prompt Injection 等風險。Agent2Agent (A2A) 通過代理模式，實現身份驗證和授權分離，有效防御跨服務器泄露。結合輸入/輸出檢測，構建安全可擴展的云原生 AI 架構，保障企業數據安全。

譯自：Deploying A Secure Enterprise Agentic AI: MCP + Agent2Agent^[1]
作者：Rikki Singh

LLM、AI 代理及其不斷發展的工具生態系統（如 Model Context Protocol (MCP)^[2]）的引入，為各種新的用例打開了大門。盡管如此，它們也給生產中的安全帶來了獨特的挑戰，讓我們對如何為用戶創建安全可靠的應用程序留下了許多未解之謎。

當我們的團隊開始探索 MCP 及其應用時，我遇到了一些這樣的問題。我們問自己這樣的問題：“MCP 規范沒有明確說明我們應該如何進行身份驗證……那么我們應該如何考慮它？”我們想知道提供 API 密鑰的最佳方式是什么，未來的遠程服務器會是什么樣子，以及不同的客戶端及其 LLM 將如何解釋和利用我們通過服務器提供的工具。

本文探討了使用 LLM 固有的主要風險，我們如何看待隨著 MCP 等新標準的引入而發生的變化，以及我們如何考慮使用更新的標準（如 Agent2Agent (A2A)^[3]）構建安全且可擴展的 agentic 架構。

我們是如何走到這一步的？

在安全評估中，我們經常考慮兩個概念：攻擊面，即系統中容易受到攻擊者利用的地方的數量；以及 爆炸半徑，即一次成功的攻擊可能對系統產生的影響。LLM 最近因其靈活性和自動化世界的承諾而迅速普及，但當添加到我們的應用程序中時，它們也會帶來易受攻擊的攻擊面。基本的聊天機器人通過接受和推理用戶提供的不可信自然語言來擴大我們的攻擊面。由于 LLM 的非確定性性質，輸出缺乏可預測性，并且重現問題以進行診斷的能力有限。因此，我們也無法完全確定其答案可能造成的潛在危害，從而增加了我們的爆炸半徑。作為構建我們自己的 agentic 平臺的早期采用者，該團隊面臨著各種新的安全挑戰，其中最著名的是 Prompt Injections^[4] 和 Jailbreaks^[5]，這兩者都是由提供給 LLM 的不可信內容促成的，旨在導致意外的操作或響應。

然后是代理。Agentic AI 通過引入與 API 和數據的更多特權交互來提高復雜性和風險因素。現在，我們可以引入更智能的系統，這些系統使用工具和知識來源。代理與 API 交互，連接到數據源（有些來自公共互聯網），甚至可以與其他代理通信或由另一個 AI^[6] 代理主管管理。但是，如果您擴展我們的攻擊面和爆炸半徑的邏輯，您可以看到隨著我們在組件之間傳遞更多不可信內容，問題是如何復合的。間接提示注入^[7]可以通過為 LLM 知識抓取的網站傳遞，等待激活的合適用戶查詢。工具域的 DNS 記錄可能會欺騙主機^[8]訪問其自身本地網絡上的服務。不幸的目標可能會遇到數據泄露或遠程代碼執行。

并不是說我們以前沒有見過類似漏洞，但架構格局的變化起初可能會讓人感到困惑，需要新的安全思維方式。為了使更安全的 agentic 流的愿景成為可能，我們有 MCP 和 Agent2Agent 框架。雖然 MCP 側重于創建對工具的訪問，但 A2A 側重于代理之間的互操作性。

我們能做些什么？

下面，我們重點介紹了我們認為通過我們與 MCP 的合作很重要的三個關鍵漏洞，以及如何解決這些漏洞（詳細信息如下）：

1. 跨服務器泄露和敏感數據暴露： MCP 的優勢之一在于，您的應用程序/代理/客戶端可以收集完成請求所需的一切，可能來自多個 MCP 服務器，并將它們傳遞給 LLM（單個或多個供應商）進行處理。這隱含地存在將一個服務器中的資源暴露給另一個服務器的風險。我們建議希望將其工具暴露給這些客戶端的企業，利用代理來執行此操作，而不是直接使用 MCP 服務器，以便他們可以保持控制并保護自己免受數據暴露。

2. 身份驗證和授權： MCP 缺乏對用戶進行通用身份驗證的機制，例如 OIDC 或 SSO，并且可能繞過跨資源的授權要求（又名：The Confused Deputy^[9]）。因此，我們建議分離身份驗證和授權層，以便您可以使用現有的控制平面基礎設施來識別用戶和代理，確保他們始終擁有對其所操作數據的適當憑據。A2A 在這方面提供了便利，因為實現該協議的客戶端代理可以通過代理卡發現其他代理的身份驗證方案。這使企業能夠在探索維護和管理代理身份^[10]的替代方法時取得進展。

3. Prompt 注入和越獄： MCP 客戶端及其 LLM 容易受到來自其他連接的 MCP 服務器的 prompt 注入和越獄攻擊。對于客戶端和服務器，了解您的工具和資源是值得信賴的至關重要。在 A2A 服務器層采用檢測策略以降低這些攻擊成功的可能性會非常有效。A2A 不是這里唯一的架構選擇，任何免受直接輸入和輸出影響的代理模式都將為實施檢測策略提供空間。

正如您閱讀了以上內容，您可能已經清楚地意識到，本質上，與必須專門利用 MCP 服務器或 A2A 相比，代理架構的網格可以解決許多這些挑戰。

我們將在下面進一步闡述這些風險以及我們為那些希望通過示例了解它們的人提出的建議。我們在本次探索中的指導原則是確保我們能夠為我們的客戶構建安全系統^[11]，而不會使架構過于復雜而無法擴展。隨著企業希望采用這些框架來加速他們自己的 AI 創新，我們希望我們能夠共同做到這一點，而不會危及我們用戶的安全。

1. 跨服務器泄露和敏感數據暴露

第一次使用 MCP 時，它會讓人覺得很神奇。看著你的代理弄清楚如何與 API 交互并使用它來完成任務非常酷，它確實給人一種未來的感覺。我們應該擴展我們的代理并讓它訪問更多的服務器嗎？嗯，不幸的是，一個服務器存在與另一個服務器交互^[12]的風險。這里的問題是代理可以將來自每個服務器的組件混合在一起，允許它們潛在地查看和訪問^[13]它們不應該訪問的內容。這種跨服務器訪問也擴大了我們的攻擊面和我們的爆炸半徑^[14]。

多個 MCP 服務器會產生潛在的危險數據特權訪問混合。

A2A 通過在您的應用程序和連接的 MCP 服務器之間引入一個抽象層來幫助解決此問題。它引入了一個代理接口，該接口公開任務，通過隱藏其自身對 MCP 服務器的訪問權限來充當受信任的委托，從而保護您免受將特權數據暴露給應用程序中其他連接的服務器的風險。這并不能完全消除風險，因為從理論上講，您總是可能遇到隱藏在代理后面的惡意活動，但它有助于防止來自其他 MCP 服務器的竊聽和意外的資源使用。

A2A 代理委托對 MCP 資源的訪問，從而限制了對其他代理和服務器的直接暴露。

2. 身份驗證和授權

MCP 服務器目前主要在本地運行^[15]，但隨著時間的推移，它們將變為遠程運行，以便您的代理可以通過標準 HTTPS 連接到它。MCP 目前建議使用 OAuth 進行授權，但缺乏企業常用的身份驗證方式，例如 OpenID Connect、Single Sign-On 或 SAML。A2A 允許進行這種缺失的身份驗證，并支持靈活的授權架構，以確保我們的用戶和代理以可信的方式行事。

A2A 服務器通過標準交換提供身份驗證和授權選項，并期望客戶端和服務器自行協商。代理卡提供了訪問所需的身份驗證類型字段，授權字段計劃添加到規范中。借助 A2A，我們無需對當前的處理方式進行太多更改，即可擴展 MCP 提供的選項。也許您的公司使用 OpenID 進行員工登錄，并且您希望確保他們在允許任何代理代表他們執行授權操作之前，使用此系統進行身份驗證。MCP 本身目前無法在這方面為您提供太多幫助。

關于身份，我們應該進行的一項具體補充是將代理身份與用戶身份分開。用戶應該使用您的系統進行身份驗證，但代表該用戶的代理也應該被唯一標識以進行授權。用戶及其授權代理之間的授權權限可能存在差異。A2A 服務器應驗證每個工具和資源授權請求的任務要求，確保通過權限濫用無法進行未經授權的訪問，并且代理及其代表的用戶都具有正確的權限范圍。

抽象^[16] 已經在構建并作為服務提供，以規避 MCP 的某些限制，但它們仍處于實驗階段。更直接的路徑可能是您已經使用的標準流程。

3. Prompt 注入和越獄

在討論 LLM 的安全性時，我們不可避免地會遇到 prompt 注入^[17] 和越獄。它們是代理應用程序中最常被提及的兩個漏洞，并且經常參與促進其他攻擊。LLM 容易受到影響并且相對容易被欺騙。除非受到可以檢查不受信任的輸入和輸出的系統的保護，否則應用程序存在通過 LLM 解釋的更改指令來執行意外操作的風險。

由于 prompt 注入非常普遍，因此隔離和檢查 LLM 的任何不受信任的輸入至關重要。與具有可預測的工具和資源的定制代理相比，使用 MCP，我們的攻擊面和爆炸半徑會大大增加。我們無法真正信任多個連接的 MCP 服務器不會更新一個看起來安全的工具以稍后包含注入（您不知情的情況下），或者它們不會提供包含嘗試跨服務器訪問的 prompt 注入指令的資源。

可以通過掃描工具、運行時驗證以及在將任何不受信任的輸入發送到 LLM 之前實施注入檢測來緩解此問題。

但是，借助 A2A，我們的代理服務器可以充當抵御注入的第一道也是最后一道防線。在這種架構中，我們與外界的接口限制了來自其他服務器的注入所帶來的攻擊面。我們可以在代理服務器的入口點或請求流程中任何有意義的地方采用標準的輸入和輸出防護措施。我們還可以保護我們的用戶免受其他服務器的侵害，因為 A2A 服務器控制代理將用于完成其任務的工具和資源。