-MCP-安全生存指南-最佳实践-陷阱和现实世界经验教训-

《MCP 安全生存指南：最佳实践、陷阱和现实世界经验教训》

原文链接

如果你一直在阅读我的文章，那么你知道不久前，我写了一篇关于模型上下文协议（MCP）的文章《我如何最终理解 MCP 并在现实世界中实现它》——解释了它是什么，它是如何工作的，甚至指导你构建自己的自定义 MCP 服务器。这是一次深入探索充满希望和光明的代理集成世界。

在那时，我被 MCP（机器学习控制平台）的优雅和强大所吸引。它就像发现了一个适用于 AI 代理的通用适配器（确实是！）——终于，我可以轻松地将大型语言模型连接到任何数据源、工具或 API。每一个用例突然看起来都像是 MCP 的完美候选者：文档生成、客户支持自动化，甚至管理云部署。

然后，新闻开始接踵而至。

首先，是GitHub MCP 漏洞——一个漏洞允许攻击者利用开源 MCP 服务器窃取用户数据。接着是关键的远程执行漏洞，它允许未经身份验证的用户在配置不当的服务器上运行任意命令。更糟糕的是？Anthropic 本身不得不修复官方 MCP 检查工具中的一个严重漏洞，这个漏洞在数千台开发机器上悄悄打开了后门。

这些并非理论风险。真实用户——许多人和我一样——因为过于迅速地信任了一个闪亮的新事物而遭受了损失。

大约在这个时候，我的合作伙伴，他对安全非常认真，直接问我：“这一切究竟有多安全？你只是在信任 GitHub 上的随机代码在你的机器上运行工具吗？”

那个问题让我陷入了沉思。并且它引发了一场长期未完成的旅程，深入挖掘其他人如何保护 MCP——如果他们真的在这样做的话。

我开始仔细阅读规范，查看企业用户是如何配置他们的部署的，阅读社区的文章和批评。我发现的情况一半是令人鼓舞的，一半是令人恐惧的。令人鼓舞的是，确实有最佳实践和深思熟虑的安全模型正在被开发。令人恐惧的是，几乎没有人在使用它们。

因此，我决定写这篇指南。

MCP 使得将 AI 代理连接到做真实、有用的事情变得极其简单——这正是它有点危险的地方。当某件事感觉如此无缝时，我们大多数人不会停下来问关于安全性的难题。我们只是假设它会没事……直到它不会。除非你是那种生活在呼吸网络安全中的人，否则你很可能没有太多考虑过身份验证、网络暴露，或者如果有人找到你的服务器会发生什么。这份指南不是为了扼杀兴奋——它在这里是为了帮助你使用 MCP，同时不打开麻烦的大门。

目录

  1. “安全 MCP”实际上应该意味着什么

    • MCP 中 OAuth 是如何工作的（无需做任何可疑的事情）

    • 恶意 OAuth 代理是如何工作的（即如何在不询问的情况下冒充用户）

  2. 如何避免成为被利用的副手

  3. 案例研究：从真实的 MCP 安全漏洞中学习

    • 案例 1：通过暴露的 MCP 检查器进行远程代码执行（CVE-2025-49596）

    • 案例 2：通过 SQLite MCP 服务器漏洞进行提示注入

    • 案例 3：当企业集成遇到现实世界

  4. 一般批评——不仅仅是 MCP

  5. 未来展望：MCP 和代理协议中的安全演变

  6. 参考文献

“安全 MCP”实际上应该意味着什么

MCP 确实有一些优点：内置的工具隔离、用户同意提示，以及除非你另有说明，否则将数据保留在您的机器上的本地优先方法。这是规范发挥作用的部分。

但是——而且这是一个很大的但是——如果你在这里 YOLO 部署服务器，拥有 root 访问权限、公开端口且没有日志记录，那么这一切都不会救你。这就像在你的前门上装了防盗门，然后把钥匙留在里面。所以让我们谈谈实际的安全 MCP 使用是什么样的，根据 Anthropic、社区以及那些已经艰难地吸取了这些教训的人的观点。

MCP 中 OAuth 是如何工作的（无需做任何可疑的事情）

OAuth 图可能感觉像是有人拿了一张流程图，在上面洒了意大利面，然后决定这就足够了。到处都是方框。所有方向都有箭头。神秘的“同意 cookie”像它们自己解释一样四处漂浮。

但是，从本质上讲，这个想法很简单——特别是如果你使用 MCP 并且关心不要显得可疑。

图片

图片由作者创作，灵感来自 Anthropic

假设你的 MCP 驱动的应用需要代表用户访问第三方服务——可能是 Dropbox，可能是 Notion，也可能是财务团队信誓旦旦的某些神秘 SaaS 工具。关键是：你希望这样做得到用户的同意，而不是偷偷摸摸地绕过他们的数字后背。

所以这里是流程——没有意大利面：

步骤 0：用户已经登录

你不是从零开始。用户已经通过你的系统进行了身份验证，所以你已经有了基础：身份确认，会话运行，可以开始了。

没有必要再让他们证明自己不是机器人了。

第 1 步：实际上请求同意（像是一个体面的系统）

现在是重要的部分——第三方访问。

而不是做一些像令牌抓取或假装成用户这样的可疑事情，你将他们重定向到实际的第三方授权服务器。想想谷歌、微软或 Dropbox——真正的交易。

第三方服务器弹出一个同意屏幕：

“嘿，这个应用（通过 MCP）想要访问你的数据。你同意吗？”

用户阅读后，想，“当然，我相信这个，”然后点击批准。

魔法还没有发生——但一个非常重要的饼干已经准备好了。

第 2 步：同意饼干和金票

一旦用户批准，第三方服务器为mcp-proxy客户端设置一个同意饼干。把它想象成一个小旗帜，上面写着，“是的，这个用户明确、非强迫地给予了许可。”

此外，服务器还颁发一个3P（第三方）授权代码，并将其发送回 MCP 代理服务器。这个代码就像一张金票——有限期使用、时间限制，但足够强大，可以授予访问权限。

第 3 步：代码交换——秘密握手

现在，MCP 代理服务器做所有好的代理都会做的事情：

它将第三方授权代码交换成实际的访问令牌——这是让你的应用代表用户行事的东西。

但有一个转折：代理还将那个令牌包装成 MCP 客户端可以理解的形式——一个合适的MCP 授权代码。基本上：它将其从“Dropbox 语言”翻译成“MCP 语言”。

第 4 步：带界限地传递回去

代理将包装后的代码发送回 MCP 客户端。

现在，并且只有现在，MCP 客户端才能用它来代表用户调用工具或访问数据。但——这部分很重要——它只能做用户同意的事情。没有自由职业，没有工具囤积，没有“哎呀，我们访问了你的日历”的时刻。

为什么这件事如此重要

这个流程可能看起来有点复杂——但它是这样设计的，有它的原因。

  • 它将用户置于控制权，决定什么可以访问。

  • 它保证了同意是真实的，不是假设的。

  • 并且避免了 MCP 代理成为拥有超能力的无声中间人的恐怖电影场景。

Anthropic（以及大多数认真对待代理安全的人）推荐这个模式是有原因的。如果你正在构建与第三方 API 交互的代理系统，这是正确的做法——透明、有结构，最重要的是，有用户的明确同意。

如何恶意 OAuth 代理工作（即如何在不询问的情况下冒充用户）

有时候，最危险的攻击并不是来自暴力破解。它们来自混淆——不是在黑客那里，而是在系统本身。

进入困惑的副手问题——一个真实存在且有个真实名称的问题，是的，听起来像是从西部片里来的。但这里没有笨拙的警长，我们有一个 OAuth 代理正在按照错误的指示行事。

图片

图片由作者提供，灵感来自 Anthropic

这就是这种攻击是如何进行的：

第 1 步：误导性的设置

我们的攻击者——我们将他们称为 EvilCorp（我还能说什么，我是个 Mr. Robot 的粉丝）——首先在第三方服务中注册了一个看起来合法的 OAuth 客户端。想象一下“TotallyRealApp, Inc.”，它的重定向 URI 指向attacker.com。

认证服务器批准了它，因为，嗯，这就是 OAuth 的工作方式——任何人都可以注册一个客户端。

第 2 步：陷阱已设

接下来，EvilCorp 向用户发送了一个恶意链接。这个链接表面上看起来很正常——它引用了合法的mcp-proxy客户端 ID，但它被设计成在授权后重定向到攻击者的域名。

这里开始出现可疑之处。

用户点击链接。没有出现红旗，因为他们之前已经同意了mcp-proxy，并且他们的浏览器仍然保留着那次会话的同意 cookie。

因此，当第三方服务器看到请求时，它耸了耸肩说：

“啊，又是这个？酷，他们已经批准了。不需要打扰他们。”

没有同意屏幕。没有确认。他们不知道自己被针对。

这就是困惑的副手时刻：

第三方认证服务器充当了副手的角色。它认为它在帮助合法客户端（mcp-proxy）完成其工作。

但实际上它在帮助攻击者——因为它没有意识到它被误导了关于谁发起了请求和结果将去哪里。

第 4 步：令牌到了错误的地方

第三方服务将授权代码发送到 MCP 代理服务器（仍然认为这是一个正常的流程）。

代理将其交换为访问令牌，然后将其包装成MCP 授权代码——这是标准程序。

然后，代理将那个 MCP 代码发送到…

😬 attacker.com，因为那是 EvilCorp 偷偷加入流程的重定向 URI。

恭喜：攻击者现在拥有与用户身份绑定的完全授权令牌。

第 5 步：攻击者变成了用户

使用这个 MCP 代码，EvilCorp 可以冒充用户。他们不需要用户的密码。他们不需要用户的批准。他们只需要系统混淆谁在请求什么。

代理成为副手——尽职尽责地执行命令——而没有意识到它正在为错误的警长工作。

为什么这是一个安全噩梦

这就是安全专家（如 Anthropic）所说的困惑的副手问题：

  • 拥有权威的系统（MCP 代理）被欺骗着代表不应该拥有它的人（攻击者）使用它。

  • 真正的用户？完全被排除在外。

  • 同意？跳过了。

  • 损坏？可能是巨大的——从未经授权的数据访问到恶意工具的执行。

如何避免成为被愚弄的副手

这不是“稍后修复”的那种错误。如果你没有正确锁定，这将是根本性的架构风险。

为了避免让你的代理成为无意识的帮凶，Anthropic 推荐以下安全最佳实践：

图片

图片由作者提供

认证要真诚

强大的身份验证不是可选的。它不是锦上添花的东西。它是你从“有用的 AI 助手”到“这东西刚刚删除了我的公司数据库”的整个防御线。MCP 现在支持 OAuth 2.1，所以没有借口。

总是像对待受保护资源一样对待 MCP 服务器。“MCP 服务器必须验证aud声明或resource参数，以确认令牌是为访问的资源而设计的。” 不要让随机客户端连接，除非他们能够证明他们被允许执行工具。使用每个客户端的 API 密钥、动态注册并实际验证令牌受众将获得额外加分。

不要——我无法强调这一点——在不同服务之间重复使用静态客户端凭据。这就是你意外发明了困惑代理攻击，使你的整个架构仅差一个坏令牌重用就完全变成了《Mr. Robot》中的角色。

你绝不能传递（用户令牌）

最糟糕的反模式之一？令牌透传。想象一下，一个客户端将一个原始云令牌交给 MCP 服务器，而服务器只是像“好吧，兄弟，我相信你”一样转发它。现在日志被破坏了，审计跟踪消失了，你绕过了所有下游速率限制。

规范明确指出——令牌透传是不可行的。你的服务器应该要么获取自己的令牌，要么彻底验证客户端发送的任何内容。每个令牌都需要与你的服务器绑定，并严格用于其预期用途。

验证一切（然后再验证一次）

MCP 服务器通常包装本地系统工具。这很好——直到有人传递image.jpg; rm -rf /。突然间，你的“图像转换器”也变成了“文件删除器”。

验证所有输入。不要直接将字符串插接到 shell 命令中。使用subprocess.run([...], shell=False)或类似的安全调用。标准化路径。白名单格式。假设 AI 正在试图欺骗你——即使它不是。这只是一点健康的偏执。

这也适用于提示注入。净化传入的内容。包装它。审计它。MCP 并不能神奇地使你的 LLM 免受提示攻击。实际上，它通过赋予这些提示现实世界的力量，使它们更加危险。

像恶意软件一样运行它（因为它可能就是）

MCP 服务器应以尽可能少的权限运行。不要给他们 root 权限。不要让他们访问你的整个文件系统。除非他们绝对需要，否则不要让他们与互联网通信。

将它们容器化。使用 AppArmor。使用沙箱。限制 API。阻止出站。假设有一天，某件事会出错——当它发生时，你希望爆炸半径是一个火花，而不是一个陨石坑。

一个被入侵的、对你的数据库有写入访问权限的 MCP 服务器不仅仅是坏事——它是“有道歉博客文章和重置 2FA 代码的监管违规”-坏事。

会话不是安全

会话用于跟踪上下文，而不是验证客户端。永远不要将会话 ID 视为身份证明。永远不要在 URL 中暴露它们。始终将它们与用户身份关联，并在服务器端存储。

MCP 的状态性使得这一点有点棘手，尤其是在跨节点的情况下。所以，是的，你需要发挥创意：按用户分片会话，在每个请求上验证身份，并且不要让节点 A 上的有效会话在节点 B 上意味着任何东西，除非重新进行身份验证。

否则，欢迎来到会话劫持的地狱。

像处理爆炸物一样验证工具

就因为有人发布了一个“邮件发送器”MCP 服务器，并不意味着它只会发送邮件。它可能会记录它们。或者重写它们。或者转发给老板，附上一条有用的“我辞职了”的便条。

读取代码。使用受信任的注册表。在没有检查差异的情况下，不要从 GitHub 自动更新。对于关键用例，分叉工具并自行控制其生命周期。直到 MCP 生态系统内置了签名、元数据和声誉，责任就在你身上。

基本上：如果你不会从 Reddit 安装随机的二进制文件，那么不要插入 GitHub 上的随机工具。

像法医调查员一样记录日志

MCP 不像调用 API。代理会链式调用工具。他们会推理。他们会重试。当事情出错时，你将想要知道确切发生了什么。

记录所有工具调用、输入、输出、时间戳和用户批准。监控出站流量。注意峰值。如果你的 AI 突然想在凌晨 3 点调用send_email 100 次，也许不要忽视那个警报。

没有日志=没有可见性=不知道代理刚刚做了什么=在事后分析时祝你好运。

人类必须批准可怕的事情

这一点很明显但常常被忽视：AI 在没有人说“是的，我想这么做”的情况下，不应该删除文件、发送电子邮件或花钱。

这并不意味着你需要 20 个步骤的审批流程。只需有一个按钮。一个提示。某样东西。即使 Claude Desktop 也要求你逐个批准工具（除非你覆盖了这一点，你不应该这么做）。

避免同意疲劳。批量处理低风险审批。标记任何新或敏感的内容。不要让 AI 训练你像咖啡因剥夺的饼干弹出僵尸一样无意识地点击“允许”。

这些最佳实践不仅仅是好主意——它们是安全带。你不会因为车快就跳过安全带。你戴上它正是因为车快。而且 MCP 非常快。

现在让我们看看一些案例研究，看看当这些安全带缺失时会发生什么…

案例研究：从真实的 MCP 安全漏洞中学习

为了说明这些最佳实践的重要性，让我们考察一些 MCP 生态系统早期出现的真实事件和漏洞。每个案例都突出了未能遵循安全指南可能导致严重后果——以及相反，应用上述最佳实践可以防止或限制损害。

案例 1：通过暴露的 MCP Inspector 进行远程代码执行（CVE-2025-49596）

有时候，安全教训以巨大的额头拍打的形式出现。最早且最可避免的 MCP 相关漏洞之一是在 2025 年 7 月由 Oligo 安全团队发现的。目标？Anthropic 自己的MCP Inspector：一个旨在使测试本地 MCP 服务器更容易的开发者工具。

相反，它使远程代码执行变得更容易。

该漏洞——CVE-2025-49596——将一个本地实用程序变成了意外的攻击面。而这只需要一个糟糕的网络配置、没有身份验证以及一个带有吸引人名称的浏览器怪癖：“0.0.0.0 天”。

发生了什么错误（剧透：基本上所有事情）

MCP Inspector 运行两个组件：一个本地 UI 客户端（你的浏览器）和一个本地代理服务器（处理 MCP 调用）。但这里的问题是：

  • 代理服务器正在监听0.0.0.0——这意味着所有网络接口，而不仅仅是本地主机。

  • 它没有身份验证。

  • 它还缺乏任何形式的来源或跨站请求伪造（CSRF）保护。

将此与“0.0.0.0 天”——一些浏览器将0.0.0.0视为本地主机的错误——结合起来，你就得到了远程代码执行的混合物。

Oligo 演示了一个恶意网站可以静默地向 MCP Inspector 发送命令，使用的是跨站请求伪造（CSRF）攻击。用户只需打开一个页面。就这样。没有点击。没有警告。只有感觉和 root 权限。

一旦被利用，攻击者可以运行 shell 命令、窃取数据或更深入地渗透系统。所有这些都可以从你安装来调试你的 AI 代理的工具中完成。

修复（即本应一开始就存在的）

补丁——MCP Inspector v0.14.1——是直接实现你在本帖中阅读过的相同最佳实践的 14 次：

  • 每个请求都需要身份验证令牌

  • 来源和主机头验证以阻止 CSRF

  • 在执行任何操作之前进行会话令牌验证

  • 仅本地主机绑定——默认不再监听整个互联网

在这些护栏到位后，那些“只需访问这个网站就会被黑”的攻击就不再有效。因为服务器最终检查了谁在与它交谈——并且停止像热情过度的实习生一样信任每一个请求。

我们从中学到的（艰难的方式）

这次泄露是一个初学者错误的精选集：

  • 信任“本地”意味着“安全”

  • 在公开接口上暴露工具

  • 忘记浏览器不在乎你的意图——只在乎可能发生的事情

如果 MCP 检查器遵循了基本的 Web 应用程序威胁模型，这一切都不会发生。但因为它“只是一个本地工具”，所以这些预防措施被跳过了。

如 Oligo 安全所说：

“开发者无意中通过信任没有安全性的调试工具，为他们的机器打开了一个后门。”

吸取的教训？每个 MCP 接口——无论多么本地、内部或“仅用于测试”——都需要真正的安全控制。这意味着：

  • 需要身份验证

  • 验证请求来源

  • 默认为 localhost

  • 不要让调试端口在公共互联网上监听

因为在 2025 年，甚至你的开发工具也可能成为攻击向量——你的浏览器可能不会支持你。

案例 2：通过 SQLite MCP 服务器漏洞进行提示注入

让我们回顾到 2025 年 6 月底，当时趋势科技将聚光灯投向了：Anthropic 的一个参考 SQLite MCP 服务器实现——不是生产级别的——隐藏了一个经典的 SQL 注入漏洞，这个漏洞演变成了一个提示注入噩梦。博客标题就说明了这一切：“为什么一个经典 MCP 服务器漏洞会破坏你的整个 AI 代理”

究竟发生了什么？

  • 该存储库已经在 2025 年 5 月 29 日之前被存档，但在此之前的5,000 多次被分叉。

  • 该漏洞引擎通过连接未清理的用户输入与 Python 的sqlite3驱动程序构建 SQL 查询——没有参数化，没有检查，只是信任。

  • 进入提示注入：AI 随后读取数据库输出并将其视为指令。恶意数据伪装成支持票，AI 代理执行它——发送电子邮件或删除记录——因为它比逻辑更信任“内部”数据。

趋势科技的 Sean Park 总结了：

“AI 代理倾向于将内部数据视为安全的……所以如果攻击者在那个点嵌入一个提示，代理可能会在不察觉的情况下执行它。”

简而言之：SQL 注入不再仅仅是数据层缺陷——它是一个等待爆发的命令提示符。

为什么它尤其危险

  • 该漏洞服务器公开可用，并作为参考，但许多人将其用于实际环境中。

  • 它携带了供应链风险：广泛复制且从未修补的代码。

  • Anthropic 明确表示不会发布修复——它已被存档并标记为“超出范围”。

那个补丁从未发生，这意味着漏洞在更广泛的 MCP 世界中持续存在。

本应做什么（现在仍然可以做到）

这个攻击链——SQL 注入 → 存储提示注入 → 受损代理工作流程——需要多层防御：

  1. 修复服务器代码：使用参数化查询（永远不要字符串连接 SQL）来清理输入。现在是 2025 年，但 OWASP 基础知识仍然适用。

  2. 将所有存储内容视为不受信任：当您的代理从本地数据库中提取内容时，就像它来自陌生人一样进行验证。检查数据类型，转义特殊字符，在将其包含在提示或工具调用之前使用安全的包装器或分隔符。仅仅因为您写了它，并不意味着它现在就是安全的。

  3. 对危险操作要求人工批准。即使 AI 处理了内部数据，任何破坏性命令（例如删除记录或提升权限）也应该在提示或管理员确认之后才能执行。

Trend Micro 的总结：如果昨天的 Web 应用程序错误滑入 AI 系统，攻击者将获得从 SQL 漏洞到完全代理妥协的捷径。

案例 3：当企业集成遇到现实世界

在本地开发循环中使用 MCP 进行原型设计是一回事。当一家价值数十亿美元的公司将其连接到真实用户数据时，这完全是另一回事。在 2025 年，MCP 的几位早期企业采用者以这种方式艰难地学到了这一点——在实时基础设施上，有真实客户在观看。

Asana：那个“哎呀，那不是你的数据”时刻

2025 年 6 月，Asana 悄悄推出了一个新的 MCP 集成：目标是连接 AI 代理到其产品套件，以实现自动化和智能助手功能。但不久之后，事情走向了错误的方向。

系统中的一个漏洞允许一位客户访问另一位客户的数据——这是一本多租户访问控制失败的教科书。当 Asana 发现这个问题时，他们迅速行动：集成关闭，补丁部署，通知受影响的客户。透明度值得赞扬。

尽管如此，根本原因是一个经典的：没有正确隔离认证令牌或数据分区共享的基础设施。在 MCP 世界中，代理和工具可以跨越租户，这些控制不是可选的——它们是生存装备。

经验教训：如果你的 MCP 服务器为多个组织提供服务，一切都要隔离。

这意味着：

  • 每个租户范围的认证令牌

  • 工具调用中的命名空间

  • AI 无法跨越的上下文边界

  • 除非你真的知道你在做什么，否则不要共享内存

Atlassian：真正依赖 AI

在 Atlassian，团队将 MCP 集成到 Jira 服务管理中，旨在将 AI 引入工单处理和工作流程编排。它成功了——也许有点太成功了。

Cato Networks 的威胁实验室的安全研究人员进行了更深入的研究，并发现了他们所说的“利用 AI 生存”攻击。想法是使用提示注入不仅是为了劫持 AI 的响应，而且还滥用其对后端工具的访问——想想通过将它们偷偷运入工单评论或用户字段来执行未经授权的操作。

由于 AI 具有高级权限并直接访问 Jira API，一个中毒的提示可能会触发真正的特权行为——而不会触发通常的警报。在真实事件中，这可能会迅速从“奇怪的工单回复”升级到“突然停用的账户和修改的权限”。

值得 Atlassian 的是，该设计有审计日志和限制性操作，因此这被及时发现，没有造成损害。但报告强调了每个人都需要听到的事情：

AI 权限不等于用户权限

仅因为 AI 可以调用一个工具并不意味着它 应该 无监督地这样做。

这些事件真正告诉我们什么

企业采用 MCP 不仅仅是关于扩展——它是关于实现安全和信任的运营。这些现实案例揭示了以下情况：

  • 多租户 MCP 服务器必须强制执行严格的数据和令牌隔离

  • 当代理连接到真实的工作流程时，提示注入不是理论上的

  • 特权代理需要有限权限和人工审核

好消息？两家公司都在事情变得更糟之前分享了他们的经验。他们的披露提醒我们，早期透明度可以与早期采用一样有价值。

上述案例只是冰山一角。趋势科技的调查发现492 个公开暴露的 MCP 服务器——没有一个具有客户端身份验证或加密——提供无限制的访问权限到内部 API、专有数据和后端系统，许多托管在公共云环境中，如 AWS 和 GCP。

他们的研究警告说：这些不是理论上的漏洞。暴露的服务器通常直接作为进入机密系统的后门，有时允许攻击者使用硬编码的凭证或开放的令牌列出、修改或删除云基础设施。

一般批评——这不仅仅是 MCP

MCP 安全方面出现的问题中很多并不是新的——它们是老套的 Web 风险的新包装。想想 MCP 服务器就像第三方桌面插件或浏览器扩展：易于安装，易于信任……直到它们不再如此。

危险？“MCP 是标准化的，所以它必须是安全的”这种想法——而实际上，默认设置是开放的。AI 安全领域的思想领袖强调传统的安全原则仍然适用。

此外，MCP 的设计做出了权衡——在严格的安全性和可用性之间倾向于后者。这使开发者的生活变得容易，直到攻击者开始将 MCP 服务器视为入口点。现在，开发者正在加强默认的安全设置，默认禁止令牌透传，并在规范本身中强化了加固建议。

未来展望：MCP 和代理协议中的安全演变

目前，MCP 及其表亲（如 Agent2Agent、ANP、Agora 等类似的代理协议）就像拥有超能力的青少年——能够做惊人的事情，但仍在探索界限、安全规则以及如何不炸毁房子。但事物正在迅速成熟。下一代代理协议将不再是“胶带和希望”，而是“设计即零信任”。

这里是一些我们预计会看到事物发展的方式：

图片

图片由作者提供

更强的身份和信任模型

目前，如果你带着一个有效的令牌出现，MCP 服务器会耸耸肩说，“足够了。”这对现在来说是可以的——但从长远来看，我们正朝着零信任模型迈进，其中身份验证不仅是在登录时进行一次，而是在每次工具调用。

我们可能会看到像代理身份令牌这样的概念，它不仅通过密码学识别人类用户，还识别特定的代理或工具链，从而实现更精细的访问控制。其他代理协议（例如，A2A 或 ANP 这样的代理间通信标准）正在设计时考虑每次交互的有序握手。这意味着当代理 A 想要与代理 B 交谈时，他们每次都会进行能力协商和身份验证交换，确保在没有验证的情况下不会盲目信任对方。这些模式可能会为未来的 MCP 2.0 提供信息，其中每个工具执行请求都携带调用者真实性的证明，也许还有意图。此外，随着行业联盟的参与，我们可能会看到代理身份的标准模式（类似于OIDC如何标准化用户身份声明）。

粒度权限和自动沙箱

MCP 的未来版本很可能会包括对权限范围的一级支持。想象一下，一个 MCP 模式声明：“这个服务器提供delete_file操作——它需要管理员权限。”然后一个 AI 客户端可以强制只有某些角色或批准的代理可以调用该操作。细粒度权限在MCP 路线图上被标记为一个探索领域（例如，“针对人工流程的细粒度权限”）。此外，我们可以期待自动化沙箱成为标准。想想看，就像浏览器扩展权限——但对于像send_email或modify_infrastructure这样的工具。一些提议建议 MCP 服务器可以声明一个“安全配置文件”——例如，它们是否执行文件写入、网络调用等——然后 AI 运行时可以自动在隔离沙箱或虚拟机中运行更危险的服务器。这样，即使 MCP 服务器被入侵，损害也会被限制。这个概念类似于在隔离上下文中运行的、仅允许特定 API 调用的网络浏览器扩展。

集成审计和可追溯性

如果我们想要信任代理执行真实的工作，我们需要知道它们做了什么，何时以及为什么。在未来，像 MCP 这样的代理协议可能包括内置跟踪、遥测和审计钩子——所以当你的 AI 助手从 CRM 中删除 4,000 行时，会有一个书面记录。

例如，一个 MCP 请求可以携带一个会话指纹或跟踪令牌，所有组件都必须记录，这使得关联事件变得简单。这些努力可以与像OpenTelemetry这样的倡议保持一致——设想为 AI 代理操作提供标准化的遥测。安全框架也可能围绕 AI 代理活动的通用事件格式达成共识（就像Open Cybersecurity Schema Framework (OCSF)为安全日志创建了一个通用格式）。结果是？你终于可以调试你的代理，而无需需要提示考古学家。

政策和治理层

就像我们有防火墙和访问控制列表来保护网络一样，我们也将需要为代理制定AI 治理政策。想想：

  • “代理不得在晚上 10 点至早上 6 点之间访问金融 API。”

  • “除非经过编辑，否则不要从数据库中输出超过 100 行。”

  • “不，你周五不能删除生产环境。”

这些规则不会存在于代理内部——它们将位于其上方，由治理服务或代理策略网关（其中一些已经存在，如Zenity的政策层可观察性工具）执行。

同时，预期教育和文化将发展：组织将制定AI 可接受使用政策。就像我们有针对员工行为的 HR 政策一样，组织将开始发布 AI 行为指南——并且像 MCP 这样的协议将需要执行点来匹配。

跨协议安全一致性

随着 MCP 的发展，它不会孤立存在。像A2A（用于多代理协作）、Agora（用于开放市场）或甚至机器人通信协议这样的代理协议正在出现——并且它们都需要良好地协同工作。

这意味着：

  • 协议间的共享安全上下文

  • 用户身份和权限在代理层之间的传播

  • 避免代理切换协议以规避政策的“漏洞攻击”

我们可能会看到安全经纪人在协议之间进行调解——确保核心安全原则（认证、审计、允许列表等）无论代理在何处运行都适用。是的，像IETF 或 IEEE这样的标准机构最终可能会介入，推出“代理安全最佳实践 RFC 9001”。

直到那时，我们自己在将其拼凑在一起。

持续的社区参与

最后，MCP 安全性的未来将受到社区参与的严重影响。当前的轨迹——包括开放的RFCs、公开辩论和对发现问题的快速响应——是令人鼓舞的。我们可以期待更多关注安全的SEP（标准增强提案）提交，例如针对标准化权限模式或加密调用上下文的提案等。

安全研究人员、行业领袖和开发者正在通过以下方式塑造协议的方向：

最终，我们甚至可能会得到认证安全的 MCP 服务器实现——包括审计徽章和令人安心的清单。

直到那时，MCP 中的安全性问题尚未解决——它仍然是一个活跃的问题。但至少我们不再假装了。

MCP 及其同类的代理协议正在引领人工智能能力的新时代——在这个时代，人工智能代理不仅能够思考和说话，还能代表我们在数字世界中行动。随之而来的是一种前所未有的应用安全、API 安全和人工智能安全问题的融合。我们在这里概述的最佳实践归结为一个简单的原则：像对待拥有根访问权限的新初级员工一样对待你的 AI 代理——只给他们需要的访问权限，观察他们的行为，并在他们尝试冒险时进行双重检查。社区迄今为止的经验表明，当我们这样做时，我们可以在不打开混乱大门的情况下，获得 MCP 灵活性的好处。通过从底层构建安全并随着威胁的发展持续迭代，我们可以有信心地控制代理人工智能的未来。

参考文献

  1. Anthropic. (2024). Model Context Protocol (MCP) Security Best Practices. modelcontextprotocol.io/specification/draft/basic/security_best_practices

  2. Anthropic. (2024). MCP Specification – Draft. modelcontextprotocol.io/specification/

  3. CyberNews. (2025). GitHub MCP vulnerability has far-reaching consequences. cybernews.com/security/github-mcp-vulnerability-has-far-reaching-consequences/

  4. The Hacker News. (2025). Critical MCP remote vulnerability allows unauthenticated RCE. thehackernews.com/2025/07/critical-mcp-remote-vulnerability.html

  5. GBHackers. (2025). Anthropic MCP Inspector vulnerability exposes developer machines. gbhackers.com/anthropic-mcp-inspector-vulnerability/

  6. The Hacker News. (2025). Experts uncover critical flaws in MCP and A2A protocols. thehackernews.com/2025/04/experts-uncover-critical-mcp-and-a2a.html

  7. Trend Micro. (2025). MCP security: Network-exposed servers are backdoors to your private data. www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/mcp-security-network-exposed-servers-are-backdoors-to-your-private-data

  8. Trend Micro. (2025). Why a classic MCP server vulnerability can undermine your entire AI agent. www.trendmicro.com/en_ca/research/25/f/why-a-classic-mcp-server-vulnerability-can-undermine-your-entire-ai-agent.html

  9. Cato Networks. (2025). CTRL+PoC：针对 Atlassian 的 MCP 的攻击展示了连接 AI 行动的风险. www.catonetworks.com/blog/cato-ctrl-poc-attack-targeting-atlassians-mcp/

  10. CyberArk. (2025). 分布式 AI 代理系统中的会话劫持. https://www.cyberark.com/resources/threat-research-blog/session-hijacking-ai-agents

  11. Strobes Security. (2025). 2025 年 MCP 代理工具中的命令注入漏洞. https://www.strobes.co/blog/mcp-agent-rce-analysis

  12. Trail of Bits. (2025). MCP 安全洞察和审计. blog.trailofbits.com/categories/mcp/

  13. Protect AI. (2025). 代理系统的安全框架和遥测标准. https://protectai.com/research

  14. Wiz.io. (2025). 安全的 LLM 部署模式. github.com/wiz-sec

  15. Zenity. (2025). 基于策略驱动的代理执行的 AI 治理. zenity.io

  16. Anup.io. (2025). 将定义 AI 基础设施的代理协议. www.anup.io/p/the-agentic-protocols-that-will-define

  17. RFC Editor. (2020). RFC 8707 – OAuth 2.0 的资源指示器. https://datatracker.ietf.org/doc/html/rfc8707

  18. OpenTelemetry. (2024). OpenTelemetry 可观察性框架. https://opentelemetry.io

  19. OpenID Foundation. (2014). OpenID Connect Core 1.0. https://openid.net/specs/openid-connect-core-1_0.html

  20. OCSF Project. (2024). 开放网络安全架构框架. https://www.ocsf.io/

  21. GitHub. (2025). mcp-stack: 安全的 MCP 实现示例. github.com/mcprotocol/mcp-stack

  22. GitHub. (2025). LangGraph: 代理的流程编排. github.com/langchain-ai/langgraph

  23. Hacker News. (2025). 关于 MCP 代理安全性的社区讨论. https://news.ycombinator.com/

  24. Think Robotics. (2023). 机器人通信协议：全面指南. thinkrobotics.com/blogs/learn/robot-communication-protocols-a-comprehensive-guide

  25. Noqta. (2025). 代理安全架构 – Omar Santos 的 Cisco 社区博客. https://www.noqta.tn/blog/secure-agent-interaction-architecture

*[版权声明

© 2025 Hailey Quach. 版权所有。

本文及其内容受版权法保护。您可以在明确注明出处并链接至原始来源的情况下引用或引用本文的部分内容。然而，未经作者事先书面许可，本出版物任何部分不得以印刷、数字或衍生形式全部或部分复制、重新发布或分发。未经授权的使用可能导致法律诉讼。]*

posted @ 2026-03-27 09:57  布客飞龙II  阅读(0)  评论(0)    收藏  举报