OpenClaw 安全复盘：“龙虾”漏洞到底发生了什么？

大家好，我是子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、CSDN、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出

我的内容主要围绕前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

引言

每一个“爆火”的开源项目，都会经历一次现实检验：

不是性能，不是功能，而是——安全。

最近，围绕OpenClaw的一起被称为“龙虾漏洞”的事件，把一个问题彻底暴露出来：

系统能跑 ≠ 系统安全 AI 能做 ≠ AI 应该做

很多人只看到了“漏洞”，但真正值得复盘的，是：

这个漏洞是怎么“被允许发生”的？

一、事件本质：不是漏洞，是“默认信任”

先说结论：

“龙虾漏洞”不是传统意义上的代码 bug，而是架构级问题。

表面现象

AI Agent 可以执行高权限操作 缺少限制 缺少确认 缺少审计

实际问题

系统默认信任 AI 的输出

一句话总结

不是 AI 越权了，而是系统一开始就给了它权力。

二、漏洞是怎么一步步发生的？

我们把整个过程拆开来看。

第一步：AI 生成行为

{"action":"modify_world","target":"global_state"}

第二步：系统直接接受

没有校验 没有策略判断 没有风险评估

第三步：执行层直接运行

行为生效 系统状态改变

第四步：没有日志 / 审计

事后难以追踪 问题难以复现

整个链路的问题

Plan → Execute（直接跳过中间层）

正确应该是

Plan → Policy → Guardrails → Confirmation → Execute

三、为什么这个问题很容易被忽略？

因为在开发阶段，这种设计“很好用”。

开发者体验

AI 能直接操作系统 效率极高 调试方便 快速验证

但这是一个陷阱

开发阶段的“便利”，会在生产环境变成“风险”。

四、核心缺失的四个能力

这次事件，本质上暴露了四个“缺失”。

1、缺少 Policy Engine

没有：

上下文判断 行为约束 动态策略

结果

所有行为默认允许

2、缺少 Guardrails

没有：

危险操作拦截 权限控制 执行限制

结果

AI 可以做任何事

3、缺少确认机制

没有：

关键操作确认 用户授权 风险提示

结果

错误直接变成结果

4、缺少可观测性

没有：

日志 行为追踪 执行记录

结果

出问题 → 无法定位

五、为什么叫“龙虾漏洞”？

这个名字其实很有意思，它反映了一种典型现象：

系统像龙虾一样 外壳很硬（功能强） 内部很脆（安全薄弱）

或者换一种理解：

看起来很强，但一碰“安全边界”就暴露问题。

六、这不是个例，而是“AI 系统通病”

不要把这个问题只归结到OpenClaw。

在很多 AI 系统中，都存在类似问题：

模型输出直接驱动行为 缺少中间控制层 默认信任 AI

本质原因

AI 开发者更关注“能力” 而不是“约束”

七、如何修复？不是“打补丁”

很多人第一反应是：

加一个 if 判断 限制某些操作

但这解决不了根本问题。

正确方式是：重构执行链路

1、引入 Policy Engine

if(env==="prod"&&action==="modify_world"){deny();}

2、增加 Guardrails

if(action.isDestructive){block();}

3、加入确认机制

是否修改全局状态？

4、强制日志记录

{"action":"modify_world","user":"agent","result":"denied"}

八、一个更安全的执行模型

升级后的架构

AI → Plan ↓ Policy Engine ↓ Guardrails ↓ Confirmation（必要时） ↓ Execution Gateway ↓ OpenClaw Engine

特点

每一步都有控制 每一步都可观测 每一步都可拦截

九、最关键的教训

这次事件最重要的，不是“漏洞本身”，而是一个认知转变：

错误认知

AI 是工具 → 可以信任

正确认知

AI 是“行为生成器”，必须被约束。

十、一个现实建议

如果你正在做 AI 系统，一定要问自己：

三个问题

AI 能做什么？ AI 不能做什么？ 谁来决定？

如果这三个问题回答不清楚：

你的系统，迟早会出现“龙虾漏洞”。

总结

“龙虾漏洞”告诉我们的不是：

某个地方写错了

而是：

整个系统默认信任了不该信任的对象。

在OpenClaw这样的系统中：

AI 很强 执行能力很强 扩展性很强

但如果没有：

Policy Guardrails Confirmation Observability

一句话总结

AI 的风险，不来自“不会做”，而来自“做得太多”。