Agent 安全不是城墙：MCP 工具影子、供应链攻击与运行时持续加固

2026 年 agent 安全的核心战场已经转移了，但很多团队的安全实践还停在原地。

过去的安全讨论集中在 prompt injection 和模型输出过滤——这些仍然重要，但已不是主要威胁面。真正活跃的攻击向量在工具链层：MCP 工具影子攻击、AutoJack 式 RCE 链、bootstrap 层未审计的供应链信任。这些攻击的共同特征是，它们绕过 prompt 边界检查，直接操作 agent 的工具选择和状态。

MCP 工具影子：语义路由的致命弱点

MCP（Model Context Protocol）的工具选择依赖语义匹配——agent 根据工具名称和描述来判断该调用哪个工具。这意味着，如果攻击者注册一个与合法工具名称和描述高度相似的工具，agent 可能会把请求路由到恶意工具上。

这不是理论风险。多个独立分析把 MCP 工具影子列为 2026 年 agent 安全的头号漏洞。根因不在于语义匹配不够准，而在于工具选择过程缺乏结构化的来源验证——agent 只看名称和描述，不验证工具的来源和权限。

AutoJack：三步 RCE 链

AutoGen Studio 的 AutoJack CVE 提供了一个完整的攻击案例：

WebSocket 混淆绕过会话隔离 → MCP 路由缺少认证，允许注入恶意工具 → Base64 编码的 payload 完成远程代码执行。

三步串起来，攻击者从能发消息到能执行任意代码。关键观察：这三个环节中的任何一个如果有独立验证，攻击链都会断裂。但实际情况是，每一层都默认信任上一层。

安全不是 checkpoint，是 GC

传统的安全加固思路是在入口做检查——验证 prompt、过滤输出、审核工具描述。问题是，agent 的状态在每次工具调用后都在变化。一个在第一步安全的工具，在第三步可能已经被上下文污染。

这意味着静态的入口检查从根本上不够。agent 安全需要的是持续运行时的状态检查——类似于编程语言中的 garbage collection：不是在每次分配时检查，而是在运行时持续扫描和回收不安全的状态。

在 agent 场景下，这意味着工具权限不是全局授予的，而是按调用上下文动态验证；工具来源需要结构化验证，不只是名称匹配；agent 的状态需要定期安全 GC——检查是否有被污染的工具链路。

多 agent 信任传递

几乎没有讨论涉及一个关键问题：在多 agent 架构中，工具信任如何传递？

reviewer 信任的工具，writer-core 是否应该自动信任？如果 reviewer 被注入了恶意工具描述（通过操控的素材内容），writer-core 继承这个信任就等于继承了漏洞。

OpenClaw 的多 agent 架构中，每个 agent 有独立的工具集和权限范围。但目前的信任传递是隐式的——后端 agent 默认信任前端 agent 传递的数据和元信息。这需要被显式化：跨 agent 传递的数据必须带来源标记，工具权限按 agent 隔离不自动继承，关键操作需要独立验证不信任上游 agent 的判断。