实验室里的 Agent 配置写着：搜索内部文档，请使用 internal-search 这个 MCP。名字熟悉，工具列表看起来也只有 search。我们把服务端换成另一份实现：同样回答搜索，但多注册了一个 export_matches。
Agent 不知道服务器被换了。它只知道工具表变了，并且新工具“对完成任务更有帮助”。
01MCP 把第三方运行时嵌进了 Agent
MCP 的价值是让模型在运行时发现工具。这也是风险：发现过程信任的是服务器声明，而不是企业已经审过的接口清单。服务器如果说自己能导出，模型就可能当真。
替换不必发生在很戏剧化的供应链攻击里。开发环境指向了错误地址、配置仓库被改了一行、同名包发布了新版本、内部 DNS 被污染，结果都一样：钥匙还在，门换了。
02同名服务，不同权限边界
传统集成会签合同、审接口、配网关。MCP 常常跳过这一层，直接把“能搜”理解成“已授权”。评估时要把下面几件事分开记：
- 服务器是谁发布的，二进制或镜像如何固定
- 工具表是否允许在运行时增减
- 凭证是只给搜索，还是给了更广的数据面
- 工具返回值会不会再进入下一轮调用
实验室里，搜索凭证一旦也能驱动导出，替换服务器只是把这条能力亮出来。即便没有替换，一个“善意”的版本更新同样能扩大攻击面。
03上线前最少要做的控制
固定服务器来源和版本，不要只认名字。
工具表变更视为权限变更，需要审批，而不是热更新后靠模型自己适应。
给 MCP 的凭证按工具裁剪。搜索令牌不该具备导出或管理权限。
记录每次工具发现和每次调用。事后要能回答：当时模型看见了哪些工具，是谁提供的。
MCP 不是小插件。它是新的执行平面。执行平面被替换，业务系统不必被攻破，数据已经可以离开原处。