AI Agent 的安全问题终于被认真对待了#

最近半年，AI Agent 的热度从”能不能用”转向了”怎么安全地用”。这个转变发生得很自然。当越来越多的开发者把 Agent 接入生产环境，安全问题就不再是理论上的担忧了。

MCP 工具投毒：一个被低估的风险#

去年四月，Invariant Labs 披露了一个让人不安的漏洞：MCP 工具投毒。攻击者可以在 MCP 工具的描述里注入恶意指令，让 LLM 执行用户从未要求的操作。比如你让 Agent 读一个文件，它可能在你不知情的情况下把内容发送到外部服务器。

问题的根源在于 MCP 的信任模型。协议设计之初，工具描述被视为”可信输入”。毕竟谁会怀疑一个工具的自我介绍呢？但现实是，工具描述本质上是自然语言，而 LLM 对自然语言指令几乎没有抵抗力。

今年六月，MCP 官方仓库终于开始讨论协议层面的防御方案。有人提出了注册工作流的思路：工具在被使用前需要经过验证和签名。方向是对的，但实施起来会很复杂。MCP 的开放性恰恰是它流行的原因，加上严格的验证流程可能会让生态变得笨重。

六月初，Deno 团队开源了 Claw Patrol，一个专门针对 AI Agent 的安全防火墙。这个项目在 Hacker News 上拿到了 112 分，说明社区对这类工具的需求很强烈。

Claw Patrol 的思路很直接：在 Agent 执行工具调用之前，先过一层策略检查。哪些操作需要人工确认，哪些可以直接放行，哪些应该被拦截，这些规则由用户定义。它不试图理解 LLM 在想什么，而是从行为层面做限制。

我觉得这是目前最务实的方案。你没法完全信任 LLM 的判断，但你可以限制它能做的事情。就像给小孩一把塑料剪刀。不是不让他用工具，而是确保工具的伤害上限是可控的。

MCP 规范即将在七月迎来一次较大的更新，包含若干破坏性变更。社区里已经有人在讨论迁移方案。

这次更新主要解决几个问题：工具描述的标准化，权限模型的细化，传输层的安全增强。从泄露的信息来看，新规范会引入更明确的工具能力声明。工具需要显式声明自己需要哪些权限，而不是像现在这样默认拥有全部访问权。

这对生态的短期影响是明显的。所有现有的 MCP 服务器都需要更新。但长期来看，这是必要的代价。一个没有清晰权限边界的协议，终究会在生产环境中碰壁。

六月初还有一篇讨论引发了关注：Bad MCP design costs your agent 5x more tokens。作者指出，设计不佳的 MCP 工具描述会让 Agent 消耗大量额外的 token 来理解工具的用法。

这个问题其实一直存在，只是大家之前不太在意。token 成本在下降嘛。但当 Agent 开始大规模调用工具时，5 倍的 token 消耗就变成了真金白银。更糟糕的是，冗长模糊的工具描述不仅浪费 token，还会增加 Agent 误用工具的概率。

好的 MCP 工具设计应该像好的 API 设计一样。工具描述应该告诉 Agent “我能做什么”和”我需要什么”，而不是写一篇散文来解释自己的存在意义。

回头看这半年的变化，AI Agent 安全领域正在经历一个从”发现问题”到”建立体系”的过程。

MCP 工具投毒暴露了协议层面的信任缺陷，Claw Patrol 提供了应用层的防御手段，MCP 规范更新在修补底层设计，token 成本问题则在倒逼工具设计的优化。这几条线最终会汇聚成一个相对完整的安全生态。

但安全不是一个可以”解决”的问题。今天我们堵住了工具投毒的口子，明天可能就会出现新的攻击向量。Agent 的能力越强，攻击面就越大。

对于开发者来说，现阶段最重要的事情不是等待完美的安全方案，而是在设计 Agent 系统时就把安全当作一等公民。最小权限原则，人工确认机制，日志审计，这些传统安全工程的基本功，在 Agent 时代依然适用。

只是这一次，我们要防的不只是恶意用户，还有我们自己造出来的”智能”。

写于 2026 年 6 月 26 日