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 标准化了连接形式却不会自动证明服务可信。真正的工程质量来自注册、授权、验证、监控和退出的完整生命周期。