MCP 接得越多，Agent 不一定越聪明，但企业的攻击面一定更大

MCP 让大模型连接工具变得更标准。日历、数据库、文件系统、浏览器、代码仓库和内容平台，都可以用相似方式向 Agent 暴露能力。对开发者来说，这像给 AI 准备了一组通用插口，不必每接一个系统就重新设计整套协议。
便利也容易制造一种错觉：接入的 MCP 服务越多，Agent 就越强。实际情况往往相反。当工具数量快速增加，模型更难稳定选择正确工具，用户更难知道一次任务会触达哪些系统，管理员也更难维护权限、版本和责任人。能力列表变长了，系统的可预测性却下降了。每个 MCP 服务都扩大了一部分攻击面。它可能读取本地文件，访问内部数据库，调用发布接口，或把内容发送到外部平台。单看每项权限似乎合理，组合起来却可能形成意料之外的路径：Agent 从网页读取到一段恶意指令，再调用文件工具找到资料，最后通过消息或发布工具把内容送出。因此，企业选择 MCP 服务时首先要问的不是“它能做什么”，而是“完成当前任务最少需要它做什么”。一个只负责生成待审核文章的 Agent，不应默认获得删除内容、读取全部客户数据和直接公开发布的权限。工具能力应按读写分离，高风险动作应要求确认，身份凭证也不应被所有 Agent 共用。第二个关键是把来自工具的内容当作不可信输入。数据库字段、网页文本、邮件正文和第三方文档都可能包含会影响模型行为的文字。传统程序通常把它们当数据处理，语言模型却可能同时把它们理解成指令。只有明确区分系统规则、用户任务和环境内容，才能降低间接提示词注入改变任务目标的风险。JOTO 唯客 AI 护栏可以部署在这条交互链路上，对输入中的提示词注入、越狱和恶意链接进行识别，对 PII 等敏感字段做遮掩，并检查输出内容。安全日志则可记录检测事件，为排查某次异常工具调用提供上下文。它不能代替 MCP 服务本身的权限控制，但能够补充内容层和模型交互层的防线。企业还需要建立 MCP 清单：服务由谁提供、当前版本是什么、使用什么凭证、有哪些读写能力、被哪些 Agent 调用、多久复核一次。对于社区项目，应检查维护状态和依赖来源；对于内部服务，应明确负责人和下线机制。一个长期无人维护却持有高权限的连接，比模型偶尔答错更值得警惕。MCP 的价值在于降低连接成本，而不是取消治理成本。工具接入越容易，企业越需要克制。优秀的 Agent 系统不一定拥有最多工具，而是能在明确任务里，只调用必要工具，并让每次调用都可解释、可审计、可停止。真正的“万能适配器”不应变成万能钥匙。实施时，可以为不同业务建立隔离的 MCP 工具集合。内容 Agent 只看到内容数据库与草稿能力，研发 Agent 只看到限定仓库和测试环境，客服 Agent 只访问与当前请求相关的字段。即使使用同一底层模型，也不应让所有 Agent 共享同一套高权限凭证。隔离会增加配置工作，却能显著缩小异常影响范围。企业还应测试工具返回异常内容时系统如何反应，例如网页把恶意指令伪装成说明、接口返回超长文本，或多个工具给出冲突结果。MCP 标准化了连接形式，却不会自动证明服务可信。真正的工程质量来自注册、授权、验证、监控和退出的完整生命周期。