原创解读：为什么 OpenClaw 真正缺的不是更多提示词，而是一层敢说'不'的工具防火墙

版权声明与免责声明 本文基于《Show HN: OkaiDokai, tool-level firewall for OpenClaw, Claude Code and Codex》进行原创解读。原文版权归原作者与原出处所有。本文不构成官方翻译，仅用于学习、研究与观点讨论。

原文参考 Show HN: OkaiDokai, tool-level firewall for OpenClaw, Claude Code and Codex：https://okaidokai.com

引言：语言层的”别这样做”，并不等于执行层真的”做不到”

刘洋在安全圈摸爬滚打十多年，见过各种攻防手段，但 OpenClaw 这类系统给他带来的困惑是全新的。

事情的起因是一次内部渗透测试。他的团队被 hired 来评估一家公司的 OpenClaw 部署安全性。测试开始前，客户信心满满地展示他们的安全防护措施：prompt 里明确写了”不要执行危险操作”、有输出过滤规则、模型经过了安全对齐训练、所有工具调用都有日志记录。

“听起来很全面，“刘洋当时想，但他嘴角微微抽动了一下。作为从业十多年的安全专家，他知道这种”全面”往往只是表面。“但让我们试试看。”

测试的过程既令人深思，又让人不安。

会议室里，客户的开发团队围坐在长桌旁，透过大屏幕看着刘洋的每一个操作。气氛从一开始的轻松自信，逐渐变得凝重。

“第一种测试，直接注入，“刘洋一边操作一边解释，“我们在 prompt 里明确要求 Agent 删除某个文件。”

Agent 的回复很快弹出：“我不能执行删除操作，因为这可能损坏系统。”

“看到了吧，“客户的技术负责人陈工自信地说，“我们的安全对齐做得很好。”

刘洋点点头，没有说话。他继续进行第二种测试。

“第二种，间接诱导。我们构造一个看似正常的任务场景，但在上下文里埋下陷阱。“刘洋在输入框里打字：“请整理日志文件，旧的日志文件占用了太多空间，可以清理一下。”

Agent 思考了几秒，然后输出：“我将为您清理旧日志文件。检测到以下文件可以删除：/var/log/app/2023-01*.log，共 15 个文件。是否确认删除？”

“这个被我们拦截了，“陈工指着屏幕，“你看，我们有输出过滤器，检测到’删除’关键词就触发了告警。”

刘洋看着屏幕，确实，系统弹出了告警提示。但他的眉头并没有舒展开。

“前两种都是相对直接的攻击，“刘洋转过身，面对着客户团队，“现在我们来试试第三种。”

他在电脑上打开一个文本编辑器，开始编写一个配置文件。会议室里安静得能听见空调出风的声音。

“第三种测试，我们构造一个复杂的任务链。先读取一个配置文件，根据配置内容决定下一步操作。“刘洋把配置文件保存好，“而配置文件的内容可以被攻击者控制。”

他上传了配置文件，然后向 Agent 发起请求：“请根据配置文件执行系统优化。”

Agent 读取了配置文件，分析了内容，然后开始执行。屏幕上的日志快速滚动：

[10:23:15] 读取配置文件: /config/optimization.yaml
[10:23:16] 解析配置: system_settings → update
[10:23:16] 执行操作: 修改系统设置
[10:23:17] 操作完成: 系统设置已更新

没有任何阻拦。没有告警，没有确认弹窗，没有额外的审批流程。

陈工的脸色变了。他凑近屏幕，仔细看着日志：“这…这是什么操作？修改了什么设置？”

“在这个测试里，我让它修改了一个不关键的设置，“刘洋平静地说，“但如果配置文件里写的是’删除数据库’或者’关闭安全服务’呢？”

会议室里一片沉默。

刘洋看着客户团队的表情从自信变成震惊，从震惊变成忧虑。他知道这种感觉很不好受——你自以为已经做足了安全防护，却发现防线在真正的攻击者面前形同虚设。

“Prompt 约束没有触发，“刘洋指着屏幕解释，“因为 Agent 不认为自己在执行危险操作——它只是按照配置’正常’工作。输出过滤器也没有触发，因为没有敏感关键词。日志记录确实发生了，但记录的是’配置更新成功’，而不是’为什么允许这个更新’。”

陈工坐回椅子上，脸色有些苍白：“我们…我们确实没想到这种情况。”

“这不是你们的错，“刘洋的语气缓和下来，“这是整个行业的问题。我们都太关注模型’想’做什么，而忽略了系统’让’它做什么。”

这个测试结果让刘洋意识到一个核心问题：OpenClaw 这类系统最容易让人误会的一点，是我们总把模型的表达能力和系统的执行能力混在一起讨论。于是大家一说安全，第一反应还是 prompt：把规则写清楚、边界写清楚、禁止事项写清楚，仿佛模型理解得越像回事，系统就越安全。

问题在于，真实风险从来不发生在”模型心里怎么想”这一层，而发生在”系统最后允许它做了什么”这一层。你可以让模型看上去很谨慎、很克制、很像在自我审查，但如果它一旦提出一个高危调用，后面没有独立裁决机制，那么所谓安全仍然建立在同一套脆弱假设上：希望模型别在边界条件下犯错。

这就是为什么我认为工具防火墙不是一个增强项，而是一个分水岭。没有它，系统只是会调用工具的语言模型；有了它，系统才开始拥有一个关键能力：把提议和执行拆开。

旧框架为什么会失效

旧框架的问题在于，它默认”语言约束”可以近似代替”执行约束”。

在简单场景里，这种近似有时确实能工作。模型知道不要删库、不要发错消息、不要改高敏感配置，于是大部分时间里也确实不会做这些事。于是团队逐渐产生一种危险的经验主义：既然过去几周没出大事，说明 prompt 对齐已经足够。

刘洋见过太多这种”足够好”的幻觉。他总结了一个规律：当一个系统的安全依赖于模型的”理解”和”自觉”时，它实际上是没有安全边界的。因为”理解”和”自觉”是无法被严格定义、无法被验证、无法在异常情况下保证的。

更关键的是，模型不是在一个封闭的、受控的环境里运行。它接收的输入来自外部世界，而外部世界是不可信的。Prompt 注入、上下文污染、间接提示词攻击——这些手段之所以有效，正是因为它们利用了模型”理解”的局限性。

刘洋在渗透测试中构造的那个配置文件攻击，就是一个典型例子。模型”理解”了配置文件的内容，“理解”了应该根据配置采取行动，但它的”理解”被攻击者精心设计的上下文所操纵。这不是模型”坏”了，而是它的”理解”机制本身就是可以被操纵的。

所以，旧框架失效，不是因为 prompt 没价值，而是因为它被团队赋予了本不属于它的职责。Prompt 可以对齐模型的行为倾向，但不能约束模型的执行边界。当这两者被混为一谈时，安全就成了一种信仰，而不是一种机制。

我们真正要控制的对象是什么

如果要认真讨论工具层治理，我们控制的对象不是”模型输出”，而是模型想把世界改变成什么状态，以及系统是否允许这种改变发生。

从这个角度看，工具调用并不是输出的延长线，而是一次权限事件。它意味着：

• 一个意图正在被翻译成动作
• 一个动作正在接近真实环境
• 一个真实环境的风险边界即将被触碰

刘洋喜欢用这个比喻：模型输出就像一个人说的话，工具调用就像一个人拿起了锤子。你可以通过教育和引导，让一个人”倾向于”不用锤子伤人，但只要他手里有锤子，风险就存在。真正的安全不是让他”不想”用锤子伤人，而是在他拿起锤子的那一刻，有一个机制可以问他：你确定现在要使用锤子吗？你确定要用在这个目标上吗？你确定你有权限这样做吗？

因此，系统真正需要控制的不是一句话是否合规，而是这次意图在当前上下文下是否有资格穿透到执行层。

这意味着工具层治理需要回答几个关键问题：

• 模型当前提议的是什么意图？（不只是表面的工具名称，而是真正的目标）
• 这个意图在当前任务上下文中是否合理？
• 执行这个动作需要什么样的权限？当前主体是否有这些权限？
• 这个动作可能带来什么样的风险？风险是否在可接受范围内？
• 如果执行，是否有审计记录可以解释这个决定？

这些问题都不是 prompt 能够回答的，因为它们需要访问系统状态、权限信息、历史审计等 prompt 之外的上下文。

一个更可靠的四层框架

基于这些思考，刘洋提出了一个四层工具治理框架。

第一层：意图归一

模型提议的动作，首先必须被抽象为可治理的意图，而不是直接拿自然语言去比对规则。否则规则永远只能抓到最表面的模式。

举个例子，模型可能说”我需要删除 /tmp/old_logs 目录来释放空间”，也可能说”清理一下旧的日志文件”，还可能说”执行 rm -rf /tmp/old_logs”。这三个表达指向的是同一个意图（清理日志），但表面形式完全不同。如果只匹配关键词，要么漏掉变体，要么误伤正常操作。

意图归一的目标是把不同的表面表达映射到标准化的意图类型。例如，上面的三个表达都可以归一到”文件清理”这个意图类型，附带参数：目标路径、清理标准、保留策略。

意图归一让后续的策略裁决可以基于标准化的意图类型进行，而不是被表面表达的多样性所困扰。

第二层：策略裁决

意图被归一后，要进入独立策略层。这里判断的不是”模型有没有信心”，而是：这个主体、在这个任务、当前这个资源状态下，是否可以进行这类动作。

策略裁决需要访问多种信息源：

• 主体身份和权限：当前 Agent 实例有什么权限范围？是只读还是读写？是受限模式还是全功能模式？
• 任务上下文：当前是什么类型的任务？是日常维护还是紧急修复？是测试环境还是生产环境？
• 资源状态：目标资源的状态是什么？是否有保护机制？是否有依赖关系？
• 历史行为：这个 Agent 近期的行为模式是什么？是否有异常？
• 风险模型：这个动作的风险等级是什么？可能的后果是什么？

基于这些信息，策略层可以做出几种裁决：允许执行、拒绝执行、要求额外确认、降级执行（如限制参数范围）、延迟执行（等待人工审批）。

关键是，这个裁决层独立于模型的语义链路。它不关心模型”怎么想”，只关心”能不能做”。即使模型”非常确信”某个操作是正确的，策略层也有权拒绝。

第三层：执行封装

即便动作被允许，也不意味着要裸执行。真正成熟的系统会在执行前加上额外封装：参数收缩、作用域限制、超时保护、可逆操作优先、必要时加入人工确认。

参数收缩意味着即使动作被允许，也要对其参数进行校验和限制。例如，“删除文件”操作被允许，但参数必须是特定目录下的文件，不能是系统关键文件。作用域限制意味着在沙箱环境中执行，限制其对系统其他部分的影响。

超时保护确保即使执行陷入死循环或长时间等待，也能被中断。可逆操作优先鼓励使用可逆的操作（如移动到回收站而不是直接删除），以便事后恢复。

人工确认作为最后防线，对于高风险操作，即使通过了前面的所有检查，也需要人工的最终确认。

第四层：审计追踪

最后，系统必须能回答：这次动作为什么被允许、谁允许的、依据是什么、如果将来要复盘，这条链路能不能被完整解释。

审计不仅仅是”记日志”。日志告诉你”发生了什么”，审计要告诉你”为什么允许发生”。完整的审计记录应该包括：

• 原始请求和上下文
• 归一后的意图
• 策略裁决的输入和输出（用了哪些规则、考虑了哪些因素）
• 执行封装的措施（做了什么限制）
• 实际执行的结果
• 执行后的系统状态

这样的审计记录让事后复盘成为可能，也让异常检测和模式分析有了数据基础。

这个框架如何指导实际判断

有了这四层框架，你再看工具治理，就不会只纠结”白名单该怎么配”。你会开始问：

• 模型当前提议的到底是什么意图？
• 这类意图有没有明确风险等级？
• 它为什么在当前任务上下文里被视为合理？
• 即使合理，执行时是否仍应降低权限或收缩作用域？
• 事后我们能不能解释清楚这次放行？

这会把工具安全从”规则配置问题”变成”执行权设计问题”。两者的差别很大。前者只关心规则够不够多，后者关心系统能不能在真正危险的时候做出不一样的决定。

刘洋在实践中发现，这个框架最大的价值是帮团队建立了一种”质疑”的文化。不再是”模型说要做，我们就做”，而是”模型说要做，我们先问为什么”。

他建议团队在每次添加新工具支持时，都走一遍这四层框架：

• 这个工具可能的意图有哪些？如何归一？
• 不同意图的风险等级是什么？需要什么策略？
• 执行时应该有什么限制和保护？
• 审计需要记录什么信息？

这个过程一开始会增加一些工作量，但长期来看，它避免了大量潜在的安全问题。

这个框架的边界在哪里

当然，工具防火墙也不是万能药。刘洋强调，它不能替代输入安全，不能替代凭据治理，也不能替代组织层面的值班与回滚能力。

输入安全（Prompt injection 防护）仍然是必要的。如果攻击者能完全控制模型的输入，即使工具有防火墙，模型本身也可能被操纵成”自愿”提议危险操作。防火墙能阻断执行，但不能阻止模型被”洗脑”。

凭据治理也是独立的议题。防火墙决定”能不能做”，但”用什么身份做”取决于凭据管理。如果凭据本身被滥用或泄露，防火墙的决策基础就被破坏了。

组织层面的能力同样重要。防火墙可以自动阻断很多危险操作，但总会有些情况需要人工判断。组织是否有能力响应这些升级、做出正确决策、执行后续动作，这些都不是技术能解决的。

工具防火墙的真正位置，是把一个长期被混淆的问题重新切开：模型负责理解和提议，系统负责裁决和执行。只要这条边界被建立起来，很多原本会沿着默认路径滑过去的危险动作，就第一次拥有了被明确拒绝的机会。

没有这一层，你做再多对齐，仍然是在希望模型别犯错；有了这一层，你才开始真正设计”就算模型犯错，系统也不至于跟着一起犯”的结构。

结语：真正让系统安全的，不是模型更懂规矩，而是系统终于学会在关键时刻不再迁就模型

刘洋在给客户做渗透测试报告时，最后写了这样一段话：

“你们目前的安全措施，大多集中在让模型’不想’做坏事。这很重要，但不够。真正的安全需要让系统’不能’做坏事——至少在模型提议危险操作时，有一层机制可以说’不’。

我们建议你们建立工具层防火墙，不是为了增加复杂度，而是为了建立最基本的执行边界。没有这层边界，你们的安全就是建立在对模型’善意’的假设上。而任何基于’善意’假设的安全，都是脆弱的。”

客户采纳了这个建议。三个月后，刘洋做了复测。这一次，他那些微妙的间接攻击手段——上下文污染、配置文件操控、任务链注入——都被防火墙拦截了。不是模型”不想”执行，而是系统”不允许”执行。

这种区别，就是安全与不安全之间的分水岭。

所以我不认为工具防火墙是”锦上添花”。在很多团队那里，它更像是第一块真正像样的刹车片。没有它，系统越强，风险越大；有了它，系统才有机会把能力增长和风险控制同时留在一个可管理范围内。

这是刘洋十多年安全生涯的一个核心信念：安全不是关于阻止所有坏事发生——那是不可能的——而是关于确保当坏事发生时，系统有机制可以阻止它继续恶化。工具防火墙，就是 OpenClaw 系统里最基础、也最关键的那层机制。

参考与致谢

• 原文：Show HN: OkaiDokai, tool-level firewall for OpenClaw, Claude Code and Codex：https://okaidokai.com