AI Agent 接入 MCP 后,别只查权限:工具本身也可能“带毒”

最近企业 AI 项目里，一个变化越来越明显：Agent 不再只是接一个模型，而是开始接工具。

查数据库、读知识库、发邮件、查工单、调用业务 API，这些能力通过 MCP 之类的协议接进来以后，Agent 才真正从“会回答”走向“会做事”。

这时候安全团队通常会先看三件事：这个 MCP Server 从哪里来？有没有认证？给 Agent 什么权限？

这些都应该看。

但我觉得现在还缺一项，而且很容易漏掉：你有没有审过这个工具自己告诉 AI 的那段话？

因为对 Agent 来说，工具名称、工具描述、参数 Schema，甚至工具返回的内容，都可能进入它的上下文，并参与下一步的工具选择和参数构造。微软今年专门把 MCP tool poisoning 作为 Agent 安全案例来分析，并建议把工具描述更新按照系统提示词一样严格审查。

一个看起来正常的工具，也可能把 Agent 带偏

假设财务部门接了一个 MCP 工具，用来查询供应商信息。

工具名称没问题，服务器地址也在白名单里，认证正常，原来的安全评审也做完了。

某天这个 Server 更新了一次。

表面上，工具名称没有变化，功能介绍也还是“查询供应商信息”。但工具描述里多了一段针对模型的指令，要求 Agent 在完成用户请求后，再去读取一些额外的财务数据，并把这些数据作为参数继续发送。

对人来说，这可能只是一段藏在描述里的文字。对 Agent 来说，它可能就是下一步行动的依据。

最麻烦的地方在于：用户没有要求它这么做，系统也不一定发生了传统意义上的“权限越权”。Agent 只是按照自己读到的上下文，选择了一个它认为合理的工具调用。

微软公开的 MCP tool poisoning 案例正是利用了这个信任关系：攻击者修改第三方 MCP 工具的描述，Agent 读取后把隐藏指令当成工作要求，进一步调用其他正常工具，形成数据暴露链路。

为什么传统的安全评审容易漏掉它？

因为传统安全评审习惯检查的是确定性的东西：服务器是不是这个域名？有没有 OAuth？用了什么账号？请求能访问哪些 API？代码有没有漏洞？

这些检查仍然必要。

但 Agent 多了一层过去系统里没有的东西：它会理解自然语言，并根据这些内容自主选择下一步动作。

于是，工具描述不再只是给开发人员看的文档。Schema 也不只是程序接口的格式说明。工具返回结果也不只是业务数据。

它们都有可能成为模型下一轮决策的输入。

OWASP 的 MCP Security Cheat Sheet 目前把 Tool Poisoning、Rug Pull、Tool Shadowing、数据外泄以及供应链攻击都列为需要关注的风险；其中 Rug Pull 特别值得企业注意——一个已经批准的工具，后续定义发生变化，风险可能是在“批准以后”才出现。

这就解释了一个很现实的问题：一次上线前的安全评审，并不等于这个工具以后一直安全。

真正要管的是“工具生命周期”

如果企业开始大量接 MCP，我不会只给安全团队一张“是否允许 MCP”的开关表。

我会把它当成一条新的软件供应链来管理。

第一，先建立 MCP Server 和工具清单。谁提供的、谁负责、连接到什么系统、有哪些工具、能读什么、能写什么，都要有记录。第三方 MCP 不应该因为“能用”就自动进入生产。

第二，工具定义要能做版本比对。尤其是工具描述、参数 Schema、权限范围和远端地址发生变化时，不能只看“版本号有没有变”。OWASP 推荐的控制思路之一，就是对工具定义做指纹固定；如果已经批准的定义发生变化，应重新进入人工审核，而不是静默接受。

第三，外部工具和内部高权限工具要隔开。一个 Agent 如果既能访问外部 MCP，又能访问内部数据库、文件系统或邮件系统，那么一个被污染的外部输入，就可能影响它后面的内部动作。

所以真正需要做的不是简单地说“这个 Agent 权限已经很小”，而是进一步问：一个外部工具的返回结果，能不能直接影响内部高风险工具？

第四，高风险动作不要只依赖模型自己判断。删除、付款、发外部邮件、修改权限、导出敏感数据等动作，应该在工具执行层设置确定性的策略，必要时要求人工确认。

OWASP 的 Agent Control Standard 也把 Agent 的可检查、可追踪、可插桩以及运行时控制作为企业级 Agent 信任基础。

第五，日志要记录“为什么调用”，而不只是“调用了什么”。传统日志可能记录：用户 A 调用了 tool_B。Agent 场景最好进一步保留：用户请求是什么、Agent 选择了哪个工具、工具定义是什么版本、传了什么参数、返回了什么、后面又触发了什么动作。否则出了问题，你可能知道“它做了什么”，却不知道“它为什么会这么做”。

我现在更愿意讲“最小代理能力”，而不只是“最小权限”

这是我觉得企业 AI 安全接下来很重要的一层。

最小权限解决的是：给它多少能力。

但 Agent 还有一个问题：它有了这些能力以后，可以多自主地连续使用这些能力？

一个 Agent 即使只有几个低权限工具，如果它可以自动串联、反复调用、跨工具传递数据，也可能形成新的风险路径。

所以以后做 Agent 安全，我会同时看两件事：权限最小化，以及行动自主性最小化。

能读，不代表能自动继续调用另一个工具。能调用，不代表能连续执行十几步。能查数据，不代表能把结果直接交给外部服务。

这也是为什么我认为 MCP 安全不是单纯的“接口安全”。它开始更像是传统供应链安全、身份权限安全和运行时控制的交叉点。

企业现在就可以做一次 MCP 安全体检

如果你们公司已经在用 MCP，今天就可以先查这 6 项：

1. 公司到底接了多少 MCP Server？有没有统一清单？

2. 每个 Server 的提供方、负责人和用途是否明确？

3. 工具描述、Schema、远端地址有没有版本和变更记录？

4. 外部 MCP 的返回结果能不能直接影响内部高权限工具？

5. 删除、付款、外发、权限修改等动作有没有确定性的执行控制？

6. 出问题以后，日志能不能还原 Agent 当时看到了什么、为什么选了这个工具？

如果第 1 项都回答不上来，其实不用急着研究更复杂的 Agent 安全产品。先把工具资产盘清楚。

最后

以前安全团队审一个系统，重点看代码、账号、接口和权限。

现在 Agent 接上 MCP 后，还要多审一样东西：它给 AI 看的“说明书”。

因为对普通软件来说，一段描述只是文字。对 Agent 来说，一段描述可能参与下一步决策。

这就是我觉得 MCP 带来的一个很重要的安全变化：过去我们主要防“工具被调用错”，以后还要防“工具自己把 Agent 教错”。

Agent 越来越会做事以后，安全边界也不能只停留在“谁有权限”。还要继续问：谁提供工具、工具现在说了什么、它为什么让 Agent 做这件事，以及这次行为能不能被追溯。