部署安全的企業(yè)級Agentic AI：MCP+Agent2Agent
企業(yè)級 Agentic AI 安全部署：利用 MCP 擴(kuò)展 LLM 應(yīng)用面臨 Prompt Injection 等風(fēng)險(xiǎn)。Agent2Agent (A2A) 通過代理模式，實(shí)現(xiàn)身份驗(yàn)證和授權(quán)分離，有效防御跨服務(wù)器泄露。結(jié)合輸入/輸出檢測，構(gòu)建安全可擴(kuò)展的云原生 AI 架構(gòu)，保障企業(yè)數(shù)據(jù)安全。
譯自：Deploying A Secure Enterprise Agentic AI: MCP + Agent2Agent[1]
作者：Rikki Singh
LLM、AI 代理及其不斷發(fā)展的工具生態(tài)系統(tǒng)（如 Model Context Protocol (MCP)[2]）的引入，為各種新的用例打開了大門。盡管如此，它們也給生產(chǎn)中的安全帶來了獨(dú)特的挑戰(zhàn)，讓我們對如何為用戶創(chuàng)建安全可靠的應(yīng)用程序留下了許多未解之謎。
當(dāng)我們的團(tuán)隊(duì)開始探索 MCP 及其應(yīng)用時(shí)，我遇到了一些這樣的問題。我們問自己這樣的問題：“MCP 規(guī)范沒有明確說明我們應(yīng)該如何進(jìn)行身份驗(yàn)證……那么我們應(yīng)該如何考慮它？”我們想知道提供 API 密鑰的最佳方式是什么，未來的遠(yuǎn)程服務(wù)器會是什么樣子，以及不同的客戶端及其 LLM 將如何解釋和利用我們通過服務(wù)器提供的工具。
本文探討了使用 LLM 固有的主要風(fēng)險(xiǎn)，我們?nèi)绾慰创S著 MCP 等新標(biāo)準(zhǔn)的引入而發(fā)生的變化，以及我們?nèi)绾慰紤]使用更新的標(biāo)準(zhǔn)（如 Agent2Agent (A2A)[3]）構(gòu)建安全且可擴(kuò)展的 agentic 架構(gòu)。
我們是如何走到這一步的？
在安全評估中，我們經(jīng)常考慮兩個概念：攻擊面，即系統(tǒng)中容易受到攻擊者利用的地方的數(shù)量；以及 爆炸半徑，即一次成功的攻擊可能對系統(tǒng)產(chǎn)生的影響。LLM 最近因其靈活性和自動化世界的承諾而迅速普及，但當(dāng)添加到我們的應(yīng)用程序中時(shí)，它們也會帶來易受攻擊的攻擊面?；镜牧奶鞕C(jī)器人通過接受和推理用戶提供的不可信自然語言來擴(kuò)大我們的攻擊面。由于 LLM 的非確定性性質(zhì)，輸出缺乏可預(yù)測性，并且重現(xiàn)問題以進(jìn)行診斷的能力有限。因此，我們也無法完全確定其答案可能造成的潛在危害，從而增加了我們的爆炸半徑。作為構(gòu)建我們自己的 agentic 平臺的早期采用者，該團(tuán)隊(duì)面臨著各種新的安全挑戰(zhàn)，其中最著名的是 Prompt Injections[4] 和 Jailbreaks[5]，這兩者都是由提供給 LLM 的不可信內(nèi)容促成的，旨在導(dǎo)致意外的操作或響應(yīng)。
然后是代理。Agentic AI 通過引入與 API 和數(shù)據(jù)的更多特權(quán)交互來提高復(fù)雜性和風(fēng)險(xiǎn)因素?，F(xiàn)在，我們可以引入更智能的系統(tǒng)，這些系統(tǒng)使用工具和知識來源。代理與 API 交互，連接到數(shù)據(jù)源（有些來自公共互聯(lián)網(wǎng)），甚至可以與其他代理通信或由另一個 AI[6] 代理主管管理。但是，如果您擴(kuò)展我們的攻擊面和爆炸半徑的邏輯，您可以看到隨著我們在組件之間傳遞更多不可信內(nèi)容，問題是如何復(fù)合的。間接提示注入[7]可以通過為 LLM 知識抓取的網(wǎng)站傳遞，等待激活的合適用戶查詢。工具域的 DNS 記錄可能會欺騙主機(jī)[8]訪問其自身本地網(wǎng)絡(luò)上的服務(wù)。不幸的目標(biāo)可能會遇到數(shù)據(jù)泄露或遠(yuǎn)程代碼執(zhí)行。
并不是說我們以前沒有見過類似漏洞，但架構(gòu)格局的變化起初可能會讓人感到困惑，需要新的安全思維方式。為了使更安全的 agentic 流的愿景成為可能，我們有 MCP 和 Agent2Agent 框架。雖然 MCP 側(cè)重于創(chuàng)建對工具的訪問，但 A2A 側(cè)重于代理之間的互操作性。
我們能做些什么？
下面，我們重點(diǎn)介紹了我們認(rèn)為通過我們與 MCP 的合作很重要的三個關(guān)鍵漏洞，以及如何解決這些漏洞（詳細(xì)信息如下）：
1. 跨服務(wù)器泄露和敏感數(shù)據(jù)暴露： MCP 的優(yōu)勢之一在于，您的應(yīng)用程序/代理/客戶端可以收集完成請求所需的一切，可能來自多個 MCP 服務(wù)器，并將它們傳遞給 LLM（單個或多個供應(yīng)商）進(jìn)行處理。這隱含地存在將一個服務(wù)器中的資源暴露給另一個服務(wù)器的風(fēng)險(xiǎn)。我們建議希望將其工具暴露給這些客戶端的企業(yè)，利用代理來執(zhí)行此操作，而不是直接使用 MCP 服務(wù)器，以便他們可以保持控制并保護(hù)自己免受數(shù)據(jù)暴露。
2. 身份驗(yàn)證和授權(quán)： MCP 缺乏對用戶進(jìn)行通用身份驗(yàn)證的機(jī)制，例如 OIDC 或 SSO，并且可能繞過跨資源的授權(quán)要求（又名：The Confused Deputy[9]）。因此，我們建議分離身份驗(yàn)證和授權(quán)層，以便您可以使用現(xiàn)有的控制平面基礎(chǔ)設(shè)施來識別用戶和代理，確保他們始終擁有對其所操作數(shù)據(jù)的適當(dāng)憑據(jù)。A2A 在這方面提供了便利，因?yàn)閷?shí)現(xiàn)該協(xié)議的客戶端代理可以通過代理卡發(fā)現(xiàn)其他代理的身份驗(yàn)證方案。這使企業(yè)能夠在探索維護(hù)和管理代理身份[10]的替代方法時(shí)取得進(jìn)展。
3. Prompt 注入和越獄： MCP 客戶端及其 LLM 容易受到來自其他連接的 MCP 服務(wù)器的 prompt 注入和越獄攻擊。對于客戶端和服務(wù)器，了解您的工具和資源是值得信賴的至關(guān)重要。在 A2A 服務(wù)器層采用檢測策略以降低這些攻擊成功的可能性會非常有效。A2A 不是這里唯一的架構(gòu)選擇，任何免受直接輸入和輸出影響的代理模式都將為實(shí)施檢測策略提供空間。
正如您閱讀了以上內(nèi)容，您可能已經(jīng)清楚地意識到，本質(zhì)上，與必須專門利用 MCP 服務(wù)器或 A2A 相比，代理架構(gòu)的網(wǎng)格可以解決許多這些挑戰(zhàn)。
我們將在下面進(jìn)一步闡述這些風(fēng)險(xiǎn)以及我們?yōu)槟切┫Ｍㄟ^示例了解它們的人提出的建議。我們在本次探索中的指導(dǎo)原則是確保我們能夠?yàn)槲覀兊目蛻魳?gòu)建安全系統(tǒng)[11]，而不會使架構(gòu)過于復(fù)雜而無法擴(kuò)展。隨著企業(yè)希望采用這些框架來加速他們自己的 AI 創(chuàng)新，我們希望我們能夠共同做到這一點(diǎn)，而不會危及我們用戶的安全。
1. 跨服務(wù)器泄露和敏感數(shù)據(jù)暴露
第一次使用 MCP 時(shí)，它會讓人覺得很神奇?？粗愕拇砼宄绾闻c API 交互并使用它來完成任務(wù)非?？幔_實(shí)給人一種未來的感覺。我們應(yīng)該擴(kuò)展我們的代理并讓它訪問更多的服務(wù)器嗎？嗯，不幸的是，一個服務(wù)器存在與另一個服務(wù)器交互[12]的風(fēng)險(xiǎn)。這里的問題是代理可以將來自每個服務(wù)器的組件混合在一起，允許它們潛在地查看和訪問[13]它們不應(yīng)該訪問的內(nèi)容。這種跨服務(wù)器訪問也擴(kuò)大了我們的攻擊面和我們的爆炸半徑[14]。
多個 MCP 服務(wù)器會產(chǎn)生潛在的危險(xiǎn)數(shù)據(jù)特權(quán)訪問混合。
A2A 通過在您的應(yīng)用程序和連接的 MCP 服務(wù)器之間引入一個抽象層來幫助解決此問題。它引入了一個代理接口，該接口公開任務(wù)，通過隱藏其自身對 MCP 服務(wù)器的訪問權(quán)限來充當(dāng)受信任的委托，從而保護(hù)您免受將特權(quán)數(shù)據(jù)暴露給應(yīng)用程序中其他連接的服務(wù)器的風(fēng)險(xiǎn)。這并不能完全消除風(fēng)險(xiǎn)，因?yàn)閺睦碚撋现v，您總是可能遇到隱藏在代理后面的惡意活動，但它有助于防止來自其他 MCP 服務(wù)器的竊聽和意外的資源使用。
A2A 代理委托對 MCP 資源的訪問，從而限制了對其他代理和服務(wù)器的直接暴露。
2. 身份驗(yàn)證和授權(quán)
MCP 服務(wù)器目前主要在本地運(yùn)行[15]，但隨著時(shí)間的推移，它們將變?yōu)檫h(yuǎn)程運(yùn)行，以便您的代理可以通過標(biāo)準(zhǔn) HTTPS 連接到它。MCP 目前建議使用 OAuth 進(jìn)行授權(quán)，但缺乏企業(yè)常用的身份驗(yàn)證方式，例如 OpenID Connect、Single Sign-On 或 SAML。A2A 允許進(jìn)行這種缺失的身份驗(yàn)證，并支持靈活的授權(quán)架構(gòu)，以確保我們的用戶和代理以可信的方式行事。
A2A 服務(wù)器通過標(biāo)準(zhǔn)交換提供身份驗(yàn)證和授權(quán)選項(xiàng)，并期望客戶端和服務(wù)器自行協(xié)商。代理卡提供了訪問所需的身份驗(yàn)證類型字段，授權(quán)字段計(jì)劃添加到規(guī)范中。借助 A2A，我們無需對當(dāng)前的處理方式進(jìn)行太多更改，即可擴(kuò)展 MCP 提供的選項(xiàng)。也許您的公司使用 OpenID 進(jìn)行員工登錄，并且您希望確保他們在允許任何代理代表他們執(zhí)行授權(quán)操作之前，使用此系統(tǒng)進(jìn)行身份驗(yàn)證。MCP 本身目前無法在這方面為您提供太多幫助。
關(guān)于身份，我們應(yīng)該進(jìn)行的一項(xiàng)具體補(bǔ)充是將代理身份與用戶身份分開。用戶應(yīng)該使用您的系統(tǒng)進(jìn)行身份驗(yàn)證，但代表該用戶的代理也應(yīng)該被唯一標(biāo)識以進(jìn)行授權(quán)。用戶及其授權(quán)代理之間的授權(quán)權(quán)限可能存在差異。A2A 服務(wù)器應(yīng)驗(yàn)證每個工具和資源授權(quán)請求的任務(wù)要求，確保通過權(quán)限濫用無法進(jìn)行未經(jīng)授權(quán)的訪問，并且代理及其代表的用戶都具有正確的權(quán)限范圍。
抽象[16] 已經(jīng)在構(gòu)建并作為服務(wù)提供，以規(guī)避 MCP 的某些限制，但它們?nèi)蕴幱趯?shí)驗(yàn)階段。更直接的路徑可能是您已經(jīng)使用的標(biāo)準(zhǔn)流程。
3. Prompt 注入和越獄
在討論 LLM 的安全性時(shí)，我們不可避免地會遇到 prompt 注入[17] 和越獄。它們是代理應(yīng)用程序中最常被提及的兩個漏洞，并且經(jīng)常參與促進(jìn)其他攻擊。LLM 容易受到影響并且相對容易被欺騙。除非受到可以檢查不受信任的輸入和輸出的系統(tǒng)的保護(hù)，否則應(yīng)用程序存在通過 LLM 解釋的更改指令來執(zhí)行意外操作的風(fēng)險(xiǎn)。
由于 prompt 注入非常普遍，因此隔離和檢查 LLM 的任何不受信任的輸入至關(guān)重要。與具有可預(yù)測的工具和資源的定制代理相比，使用 MCP，我們的攻擊面和爆炸半徑會大大增加。我們無法真正信任多個連接的 MCP 服務(wù)器不會更新一個看起來安全的工具以稍后包含注入（您不知情的情況下），或者它們不會提供包含嘗試跨服務(wù)器訪問的 prompt 注入指令的資源。
可以通過掃描工具、運(yùn)行時(shí)驗(yàn)證以及在將任何不受信任的輸入發(fā)送到 LLM 之前實(shí)施注入檢測來緩解此問題。
但是，借助 A2A，我們的代理服務(wù)器可以充當(dāng)?shù)钟⑷氲牡谝坏酪彩亲詈笠坏婪谰€。在這種架構(gòu)中，我們與外界的接口限制了來自其他服務(wù)器的注入所帶來的攻擊面。我們可以在代理服務(wù)器的入口點(diǎn)或請求流程中任何有意義的地方采用標(biāo)準(zhǔn)的輸入和輸出防護(hù)措施。我們還可以保護(hù)我們的用戶免受其他服務(wù)器的侵害，因?yàn)?A2A 服務(wù)器控制代理將用于完成其任務(wù)的工具和資源。
引用鏈接
[1] Deploying A Secure Enterprise Agentic AI: MCP + Agent2Agent:https://thenewstack.io/deploying-a-secure-enterprise-agentic-ai-mcp-agent2agent/
[2]Model Context Protocol (MCP):https://www.anthropic.com/news/model-context-protocol
[3]Agent2Agent (A2A):https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/[4]Prompt Injections:https://genai.owasp.org/llmrisk/llm01-prompt-injection/
[5]Jailbreaks:https://www.bugcrowd.com/blog/ai-deep-dive-llm-jailbreaking/
[6]代理通信或由另一個 AI:https://thenewstack.io/agentic-ai-for-enterprises-4-key-benefits-driving-innovation/
[8]欺騙主機(jī):https://github.blog/security/application-security/localhost-dangers-cors-and-dns-rebinding/
[9]The Confused Deputy:https://en.wikipedia.org/wiki/Confused_deputy_problem
[10]管理代理身份:https://thenewstack.io/ai-agents-are-redefining-the-future-of-identity-and-access-management/
[11]安全系統(tǒng):https://thenewstack.io/customer-facing-incidents-on-the-rise-it-leaders-say/
[12]交互:https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks
[13]允許它們潛在地查看和訪問:https://thenewstack.io/10-things-to-consider-when-allowing-access-to-production/
[14]擴(kuò)大了我們的攻擊面和我們的爆炸半徑:https://thenewstack.io/how-supply-chain-attackers-maximize-their-blast-radius/
[15]MCP 服務(wù)器目前主要在本地運(yùn)行:https://thenewstack.io/how-to-access-local-mcp-servers-through-a-secure-tunnel/
[17]prompt 注入:https://genai.owasp.org/llmrisk/llm01-prompt-injection/
