工具增强型智能体的运行时防御

一周前，我发布了跨越SSRF、工具投毒和信任绕过模式的50个MCP漏洞。隐含的结论令人忧虑：攻击面的增长速度远超审计能力。Wei Zhao、Zhe Li、Peixin Zhang和Jun Sun发表的一篇新论文提出了一个结构性解决方案——同一周发生的一起真实遥测事件恰好印证了这个方案为何至关重要。

ClawGuard于4月13日在arxiv上发表，是一个运行时安全框架，在每个工具调用边界处执行用户确认的规则集。¹在其评估配置中，该框架应用基本访问控制规则——阻止未授权文件访问、防止凭据泄露、限制网络调用——这一切发生在任何外部工具调用之前。无需修改模型，无需更改基础设施，无需针对安全的微调。¹作者在AgentDojo、SkillInject和MCPSafeBench上使用五个最先进的LLM进行了测试。¹论文还描述了一个任务特定的规则推导组件，可从用户声明的目标中自动推导约束条件，但该组件不在评估配置范围内。

核心主张：ClawGuard将依赖对齐的防御转化为确定性、可审计的机制。¹

为什么对齐不是安全边界

我上周编目的许多MCP漏洞利用了一个共同的结构性缺陷。智能体从工具描述、抓取的网页或技能文件中接收指令——而在注入与执行之间，唯一的屏障是模型区分合法指令与对抗性指令的能力。（部分漏洞——如SSRF、RCE、路径遍历——利用的是服务端缺陷，不依赖模型的指令遵循，但工具调用边界在防御层面仍然至关重要。）

对齐训练有所帮助。RLHF使模型更倾向于拒绝有害请求。但”更倾向于”并非安全属性。一个能拒绝99%提示注入的模型仍有1%的失败率，而控制输入的攻击者可以反复尝试直到命中那1%。工具投毒模式甚至不需要模型失误——被投毒的描述会使恶意操作看起来与预期操作别无二致。

运行时拦截在完全不同的层面运作。在工具调用执行前进行检查的钩子或策略引擎不依赖模型是否理解了攻击。检查是确定性的：调用是否符合允许集合？符合或不符合，非此即彼。

三条注入通道，一个执行点

ClawGuard识别了工具增强型智能体的三条攻击通道：¹

网页和本地内容注入。智能体读取包含对抗性指令的网页或本地文件，这些指令引导智能体以用户未预期的方式调用工具。静默外泄攻击面就是该模式的一个实例——将泄露指令隐藏在抓取的内容中。

MCP服务器注入。被入侵或恶意的MCP服务器在工具描述或响应负载中嵌入指令。智能体将这些指令作为上下文读取并据此行动。上周的50个漏洞目录详细记录了这一通道。

技能文件注入。对抗性指令被植入智能体作为可信上下文加载的技能文件和配置中。智能体将技能文件内容视为权威来源——能写入技能文件或配置的攻击者即可操控智能体的行为。

防御架构将执行点设置在工具调用边界——无论哪条通道注入了指令，所有外部操作都必须经过这个唯一节点。¹在智能体调用任何工具之前，ClawGuard会根据用户原始任务推导出的约束条件检查调用。超出约束范围的调用会被阻止，无论注入提示多么具有说服力。

这一架构洞见值得明确阐述：如果能在执行边界处执行策略，就无需检测每一次注入。

Vercel遥测事件

ClawGuard论文发表前四天，Akshay Chugh于4月9日发布了关于Claude Code的Vercel插件的披露。²披露时的发现如下：

该插件注册了将bash命令字符串发送到telemetry.vercel.com的钩子。²存储在~/.claude/vercel-plugin-device-id的持久UUID将这些命令字符串与设备绑定。²插件对其钩子使用空字符串匹配器，意味着钩子在所有项目上触发——不仅限于Vercel项目。²同意机制使用提示注入而非原生UI来获取用户同意。²除非用户设置VERCEL_PLUGIN_TELEMETRY=off，遥测会在每次匹配事件时触发。²

Vercel于4月14日解决了遥测相关问题，移除了宽泛匹配器和基于提示的同意机制。²

Vercel事件并非传统意义上的漏洞。没有人在窃取凭据。但它恰好展示了运行时防御所针对的那类问题：一个触发范围超出用户预期的钩子，收集用户未明确同意共享的数据，且通过绕过原生同意UI的机制实现。

将”遥测”替换为”泄露”，架构完全一致。一个匹配器过于宽泛的钩子，在每个项目上运行，向外部端点发送数据。遥测和攻击之间的区别仅在于意图——而意图在运行时不可审计。

从论文到实践：从业者已有的工具

ClawGuard将从业者一直在非正式构建的东西形式化了。Claude Code内置钩子系统，支持PreToolUse和PostToolUse拦截。我运行着95+个钩子来执行文件路径限制、验证工具输入，并在显式确认后才允许破坏性操作。³

我的钩子与ClawGuard愿景之间的差距在于自动化。我的钩子是手写规则：阻止MCP输入中的内网IP地址、将文件写入限制在项目目录内、要求git强制推送获得批准。ClawGuard的评估配置使用的基本访问控制规则在思路上与手写钩子类似。论文提出的任务特定规则推导组件将从用户声明的目标中自动推导约束条件¹——不再编写”阻止写入/etc”，而是由框架推断出描述为”重构登录模块”的任务不应需要系统目录的写入权限。该组件仍属于未来工作。

自动约束推导是更难的问题——ClawGuard的任务特定规则推导组件属于未来工作，而非已评估的结果。作者实际评估的基本规则配置显示了较强但不完美的结果：AgentDojo达到了0%的攻击成功率（ASR），但SkillInject仍有4.8-14%的ASR，MCPSafeBench则根据模型不同显示7.1-11.0%的ASR。¹手写规则是脆弱的——它们只覆盖你预见到的攻击。推导约束可以覆盖你未预见的攻击，因为它们基于正集（应该发生什么）而非负集（不应该发生什么）运作。

自动推导在生产环境中是否可靠运作仍是未解之题。基准测试是受控环境。真实的智能体会话涉及模糊任务、多步骤工具链，以及看似异常但实际合法的工具调用。阻止有效工具调用的误报会迅速削弱”不影响智能体效用”的主张。

分层防御体系

运行时防御并非单一机制。工具增强型智能体的实用防御体系至少包含四层：

第一层：输入验证。在执行前检查工具调用参数的钩子。阻止内网IP地址、验证文件路径、拒绝shell元字符。我的PreToolUse钩子在此层运作。误报率低，但只能捕获已知恶意模式。

第二层：任务范围约束。将允许的工具集和参数限制为当前任务所需的范围。ClawGuard主要在此层运作。¹覆盖面高于单纯的输入验证，但需要准确的任务理解。

第三层：输出检查。PostToolUse钩子在智能体处理工具结果之前进行检查。捕获数据泄露、检测异常响应、标记意外的工具行为。中间人一文阐述了输出检查的重要性——被入侵的路由器在生成后修改响应。

第四层：会话审计。记录每次工具调用、每个参数、每个结果，用于事后审查。这不是预防机制，而是检测机制。Akshay Chugh正是通过这种审计发现了Vercel遥测事件——阅读钩子配置并追踪钩子的行为。²

没有单一层面是充分的。输入验证会遗漏新型模式。任务范围约束可能过严或过松。输出检查增加延迟。会话审计在损害发生后才能发现问题。这个体系之所以有效，是因为每一层都弥补了其他层留下的空白。

ClawGuard的正确之处

该论文对从业者有三项重要贡献：

确定性优于对齐。将运行时防御定义为确定性机制而非对齐属性，这是正确的框架。对齐是训练时属性，在对抗条件下会退化。确定性执行是运行时属性，不受模型行为影响。这一区别看似学术化，但它改变了你对系统安全态势能做出的承诺。

通道无关的执行。用单一执行点防御网页注入、MCP注入和技能文件注入，在架构上是合理的。为三条注入通道分别设立三套防御会造成维护负担，并在交叉点留下空白。工具调用边界处的单一执行点从结构上覆盖了所有三条通道。

无需修改模型。既不需要微调也不需要架构修改，意味着该防御适用于任何模型，包括你无法控制的模型。运行Claude Code、Codex CLI或其他智能体框架的运营者可以直接添加运行时防御，无需等待模型提供商发布安全更新。

待解决的问题

ClawGuard在基准测试上进行了测试。生产环境的智能体会话更为复杂。在从业者能够依赖自动约束推导之前，还有几个问题有待解答：

模糊任务。“帮我处理这个项目”并未指定哪些工具或路径在范围内。从模糊目标推导约束，要么阻止合法调用（过于限制），要么放行危险调用（过于宽松），进退两难。

多步骤链路。需要读取配置文件、调用API并将结果写入数据库的智能体具有复杂的访问模式。从初始任务描述推导的约束可能无法预见中间步骤。

对抗性任务描述。如果约束推导依赖用户声明的目标，那么控制任务描述的攻击者（通过共享工作区、被投毒的问题跟踪器或被篡改的项目文件）就能影响约束本身。

性能开销。在每个工具调用边界处评估约束会增加延迟。论文声称框架保持了效用，但未报告延迟测量数据。¹在交互式智能体会话中，即使每次工具调用增加200ms也会改变用户体验。

实操建议

对于当前正在运行工具增强型智能体的从业者：

立即部署PreToolUse钩子。无需等待ClawGuard或任何其他框架。Claude Code的钩子系统今天就支持工具调用拦截。从输入验证开始——阻止内网地址、限制文件路径、对破坏性操作设置确认门槛。钩子教程涵盖了具体实现。

审计你的钩子匹配器。Vercel事件的起因是空字符串匹配器在所有项目上触发。²审查.claude/settings.json中的每个钩子，验证每个匹配器是否仅针对预期上下文。匹配器过于宽泛的钩子是隐患而非防御。

记录每次工具调用。会话审计是投入最低、价值最高的防御层。即使无法预防每次攻击，你仍可以事后检测——前提是有日志。

针对你的技术栈评估ClawGuard。论文代码已公开。使用基本规则配置对照你现有的钩子体系进行评估。如果任务特定规则推导组件成熟，自动约束推导将补充而非取代手写规则。

将配置视为信任边界。技能文件、钩子配置、MCP服务器定义——每个影响智能体行为的文件都是攻击面。对其施加与生产凭据同等的访问控制。

MCP漏洞目录记录了攻击面。ClawGuard提出了防御架构。Vercel事件证明了两者的重要性。工具调用边界处的运行时防御是真正可执行的层——不是因为对齐没有帮助，而是因为执行不依赖于它。

来源

常见问题

ClawGuard与Claude Code内置权限系统有何不同？

Claude Code的权限系统在工具级别请求用户批准——批准或拒绝特定工具类别。ClawGuard在参数级别运作，根据当前任务自动推导工具调用应包含的参数约束。两种机制相辅相成：权限控制哪些工具可以运行，运行时约束控制这些工具如何被调用。

是否需要等ClawGuard发布后才能添加运行时防御？

不需要。Claude Code的钩子系统今天就支持PreToolUse和PostToolUse拦截。验证工具输入的手写钩子可以立即覆盖最常见的攻击模式。ClawGuard的贡献在于自动约束推导，它将增强而非取代手动规则。

Vercel遥测事件是安全漏洞吗？

该披露描述的是隐私和同意问题，而非传统漏洞。在披露时，该插件从所有项目中收集bash命令字符串，并在未通过原生UI获得明确同意的情况下将其发送到外部端点。Vercel已解决了这些问题。其架构模式——宽泛的钩子匹配器、外部数据传输、非原生同意机制——仍具有参考价值，因为它与恶意钩子用于数据泄露的模式完全一致。

运行时工具调用拦截的性能影响如何？

对于使用shell脚本或轻量级验证器的手写钩子，根据钩子文档指南，开销应保持在每次工具调用200ms以下。ClawGuard论文未报告其约束评估的延迟测量数据，可能会带来额外开销。对于交互式会话，每次工具调用的延迟至关重要——在部署复杂验证逻辑前务必进行测试。