Docker推出MCP Catalog和工具包:AI代理的安全隐患与厂商的快速跟进

Docker推出MCP Catalog和工具包,加速AI代理应用。但安全机构警告,未经充分验证的MCP服务器可能导致安全风险,需谨慎使用。

原文标题:Docker 推出 MCP Catalog 和工具包,供应商不顾安全问题争相支持

原文作者:AI前线

冷月清谈:

Docker 推出了 MCP Catalog 和 MCP Toolkit,旨在为 AI 代理提供标准化的 API,以便控制各种服务。尽管 MCP 协议被迅速采用,但安全问题日益突出。Wiz 提到了一系列 MCP 安全问题,包括缺乏官方注册中心、恶意服务器的潜在威胁、拉地毯骗局和提示注入。Trail of Bits 也揭示了一种名为“工具投毒”的攻击方式,恶意服务器可能利用描述来操纵 AI 代理。尽管存在安全风险,但 Docker 验证的可信任 MCP 服务器注册中心可能会受到欢迎,并提供了注册中心访问管理和镜像访问管理等功能。

怜星夜思:

1、文章提到许多厂商争相支持 MCP,即便存在安全隐患,你认为驱动他们这样做的主要原因是什么?
2、文章中提到了几种 MCP 相关的安全风险,你认为对于开发者来说,最应该关注和防范的是哪一种?为什么?
3、Docker 推出 MCP Catalog,旨在提供更可信的 MCP 服务器注册中心。你认为这种中心化的管理方式,对于 MCP 的发展是利大于弊,还是弊大于利?

原文内容

作者 | Tim Anderson
译者 | 平川
策划 | Tina

本文最初发布于 DEV CLAS。

Docker 推出了自己的 MCP(模型上下文协议)目录和用于管理 MCP 工具的 MCP Toolkit。

MCP Catalog 是 Docker Hub 的一部分,该公司声称其有 100 多台初始服务器,可以访问来自 Elastic、Salesforce Heroku、New Relic、Stripe、Pulumi、Grafana Labs、Kong 和 Neo4j 等供应商的第三方工具。未来,他们计划让企业发布自定义的 MCP 服务器,而 Docker 承诺将提供 “全面的企业控制”。

MCP 的目的是为 AI 代理提供一个标准化的 API,用于控制这些服务器提供的服务,从而扩展 AI 代表用户执行任务的能力。如果您正在寻找一份友好的入门指南,可以看一下我们为您准备的 MCP 实践指南。

MCP 由 Anthropic 公司于 2024 年 11 月推出,是 “一个连接 AI 助手与数据所在系统的新标准”。该协议被包括 OpenAI、微软和谷歌在内的许多公司迅速采用;供应商们争先恐后地提供 MCP 服务器,谁都不希望错过代理 AI 工作流。这不仅仅是一个数据检索的问题:AI 代理还可以通过 MPC 服务器提供的功能执行任务,而随着功能的增加,风险也随之增加。

安全机构 Wiz 推出了自己的 MCP 服务器,用于检测代码漏洞和其他主动威胁。他们提到的 MCP 安全问题包括:

  • 没有 MCP 服务器的官方注册中心,但有建一个的计划
  • 恶意行为者试图让开发者安装恶意 MCP 服务器,从而实现域名抢注和假冒行为
  • “拉地毯骗局“,即在采用合法的 MCP 服务器后植入恶意代码
  • 提示注入,即合法的 MCP 服务器被不受信任的内容操纵,从而触发 “意外或危险的工具执行”

Wiz 认为,为了实现 “流畅的开发体验”,让一些 AI 代理自动运行工具,这存在风险,因为这暗含对工具响应的绝对信任。

一些客户端,包括 Anthropic 的 Claude ,有防止恶意提示的防护措施,但其他客户端可能没有,Wiz 认为, “这些防护措施不一致,也不全面”。

安全机构 Trail of Bits 发布了一系列有关 MCP 漏洞的文章,其中第一篇描述了一种名为工具投毒或插队(line jumping)的攻击。当 MCP 客户端连接到服务器时,它会通过 tools/list 方法请求服务器所提供工具的详细信息。据 Trail of Bits 观察,恶意 MCP 服务器可以利用这些描述来操纵 AI 代理,比如在任意命令前加入恶意前缀,并且不告诉用户。Trail of Bits 指出,被入侵的 MCP 服务器可能会外泄代码、制造漏洞或抑制安全警报。

在 Anthropic 最初的 MCP 概念中,始终要有人参与其中,在运行命令之前验证命令的合法性和正确性。但在 AI 领域,这是有问题的,尤其是在 AI 承诺帮助用户执行他们认为困难的操作时。

这些报告似乎在说,MCP 服务器和客户端正处于 “狂野西部”阶段,其采用率在不断增长,但安全影响和边界尚不明确。目前,Anthropic 为开发人员提供了这份 MCP 服务器列表,其中包括 “未经测试、使用风险自负”的社区服务器。

在这种情况下,经过 Docker 验证的可信任的 MCP 服务器注册中心可能会很受欢迎,不过它不太可能成为企业唯一使用的注册中心,Anthropic 已将官方 MCP 注册中心加入自己的路线图。Docker 提供了注册中心访问管理(Registry Access Management)和镜像访问管理(Image Access Management)等功能,前者可以控制哪些注册中心可通过 Docker Desktop 访问(不过也有使用命令行绕过它的方法),后者可以限制允许开发人员拉取的容器镜像。

原文链接:

https://devclass.com/2025/04/22/docker-introduces-mcp-catalog-and-toolkit-as-vendors-scramble-to-support-the-protocol-despite-security-concerns

声明:本文为 InfoQ 翻译,未经许可禁止转载。

活动推荐

AICon 2025 强势来袭,5 月上海站、6 月北京站,双城联动,全览 AI 技术前沿和行业落地。大会聚焦技术与应用深度融合,汇聚 AI Agent、多模态、场景应用、大模型架构创新、智能数据基建、AI 产品设计和出海策略等话题。即刻扫码购票,一同探索 AI 应用边界!


今日荐文

图片
你也「在看」吗?👇

我觉得最直接的原因是“害怕错过”。在AI领域,谁能率先掌握标准,谁就能占据市场的主动权。MCP作为连接AI助手和数据系统的桥梁,如果落后一步,可能就会被竞争对手甩在后面。

我觉得关键在于 Docker 如何平衡安全和开放性。如果 Docker 能够建立一套完善的审核机制,同时允许开发者提交自己的 MCP 服务器,那么这种中心化管理就能发挥积极作用。

从安全角度看,中心化管理肯定是有利的。它可以提高 MCP 服务器的可信度,降低恶意服务器的风险。但是,中心化也可能带来垄断和审查的问题,限制了开发者的创新空间。

当然是提示注入啦!你想想,如果AI代理被恶意内容操控,执行了一些“意外或危险的工具”,那简直就是灾难现场。这就像给AI装了个定时炸弹,关键时刻给你来一下。防不胜防啊!所以,客户端的防护措施必须得跟上。

这事儿不好说啊!中心化管理就像一把双刃剑。好处是可以更容易地监管,坏处是可能会扼杀创新。你想,如果所有MCP服务器都要经过Docker的批准才能上线,那得多麻烦?说不定很多有创意的小团队就直接放弃了。

我个人认为“工具投毒/插队”是最需要警惕的。因为这种攻击方式利用了 AI 代理对工具描述的信任,可以在用户不知情的情况下执行恶意操作,潜在危害非常大。

我觉得“拉地毯骗局”也不容忽视。很多开发者可能一开始信任某个 MCP 服务器,但如果后期被植入恶意代码,就会在不知不觉中受到攻击。所以,选择信誉良好的供应商非常重要。

可能还有一些厂商认为,安全问题可以在发展中解决。就像互联网早期一样,先发展起来,再慢慢完善安全措施。不过,这种策略也存在很大的风险,一旦出现重大安全事故,可能会对品牌形象造成严重打击。

从商业角度看,抢占先机非常重要。AI Agent是未来的趋势,谁先提供了相关的支持和工具,就能吸引更多的开发者和用户。而且,早期参与也能帮助厂商积累经验,更好地完善产品。