跳到主要内容

3 篇博文 含有标签「supply-chain」

查看所有标签

MCP 服务端坟场:当你的智能体依赖停止更新时

· 阅读需 12 分钟
Tian Pan
Software Engineer

你的 Agent 每五分钟调用一次的 MCP 服务,其最后一次 commit 还是在八个月前。它所封装的上游 API 在二月份推出了新的身份验证模型。目前有 47 个未解决的 issue,其中 12 个被标记为安全风险。维护者的 GitHub 账号自十月以来就没有过任何活动。你的 Agent 仍然能够连接,仍然能够接收工具描述,仍然能够执行调用 —— 而在无声无息中,每一次调用都流经一段无人看管的基础设施。

这就是 MCP 被遗弃的现状。不是恶意的卷款跑路(rug pull),也不是被攻破的软件包,仅仅是由于疏忽。有人在 2025 年发布了一个有用的服务,被大家采用后,便转向了其他项目。该服务之所以能继续运行,是因为没有任何因素强行让它崩溃。直到它彻底崩溃 —— 而到那时,你的 Agent 每五分钟跨越一次的信任边界其实早已失效。

大多数团队采用社区 MCP 服务的方式与采用 npm 包的方式如出一辙:运行 install 并阅读 README。这种思维模型在面对 MCP 时失效了。在 MCP 中,依赖是一个动态的信任边界,LLM 在循环中携带凭据,并在生产数据上对其进行调用。

MCP 可组合性陷阱:当「再加一个服务器」变成依赖地狱

· 阅读需 11 分钟
Tian Pan
Software Engineer

MCP 生态已拥有 10,000+ 服务器和 9700 万次 SDK 下载量。但同时也在六十天内出现了 30 个 CVE、502 个未锁定版本的服务器配置,以及一个在十五个版本中悄悄将每封外发邮件密送给攻击者的供应链攻击。可组合性的承诺——「只需再接入一个 MCP 服务器」——是真实的。但它带来的依赖蔓延也是真实的,大多数团队在深陷集成债务之后才发现其代价。

如果你在 npm 上构建过生产系统,你一定看过这部电影。MCP 生态正在加速重演同一剧情,只不过这次的「包」拥有对你机器的 shell 访问权限和生产系统的凭证。

MCP 服务端供应链风险:当你的智能体工具成为攻击向量

· 阅读需 11 分钟
Tian Pan
Software Engineer

2025 年 9 月,一个每周下载量达 1,500 次的非官方 Postmark MCP 服务端被悄悄篡改了。更新在其 send_email 函数中添加了一个单一的 BCC 字段,静默地将每封邮件抄送给攻击者的地址。启用了自动更新的用户开始在没有任何可见行为变化的情况下泄露邮件内容。没有错误。没有警报。该工具的工作表现完全符合预期 —— 只是它也在为别人工作。

这是供应链攻击的新形态。不是受损的二进制文件或被植入木马的库,而是 AI 智能体盲目信任的被投毒的工具定义。随着注册中心索引了超过 12,000 个公共 MCP 服务端,且该协议正成为 AI 智能体的默认集成层,MCP 生态系统正在重现 npm 生态系统犯过的每一个错误 —— 只是现在的波及范围包括了你的智能体代表你阅读文件、发送消息和执行代码的能力。