OpenClaw安全框架：10大攻击面与六段攻击链

今天介绍的这篇文章基于 OpenClaw 的 190 条安全通告，整理出了一套比较完整的安全分析框架：一边是 10 大攻击面，也就是漏洞会出现在哪一层；另一边是 六段攻击链，也就是攻击通常会沿着什么路径逐步推进。

https://arxiv.org/pdf/2603.27517

十大攻击面

1. 渠道输入接口

这是最外层的入口，也就是智能体从哪里接收消息。

比如聊天消息、外部平台输入、第三方渠道接入等，都属于这一层。问题看上去很基础，但其实非常关键：谁有资格把内容送进系统，系统又是如何识别”这个人是谁”的。

如果这一层对身份的判断依赖的是昵称、展示名、可变字段，而不是平台分配的稳定身份标识，那么授权边界一开始就可能是假的。

这类问题本质上不是”输入校验不足”，而是身份锚点不稳。

2. 插件与技能分发面

很多人谈智能体安全时，第一反应还是盯着运行时，比如工具调用是不是越权、命令执行是不是危险。

但这篇论文提醒我们：插件市场、技能分发、本地技能包，其实本身就是独立攻击面。

原因很简单。一个技能包如果自带说明文档、自带执行约束、自带提示模板，那么它进入系统后，很可能并不是以”普通文本”的身份存在，而是直接进入模型上下文，成为模型推理的一部分。

这意味着什么？意味着它不需要先经过执行策略引擎，也不需要先绕过命令拦截，就已经能先一步影响模型行为了。

所以插件和技能问题，不应只被看成”生态治理问题”，它其实是智能体时代一种很新的上下文供应链风险。

3. 智能体上下文窗口

这是整篇论文最有启发性的地方之一。

作者专门把”上下文窗口”单独抽出来，说明智能体的核心风险已经不只是输入内容本身，而是：这些内容进入上下文后，会不会被模型当成可以执行的指令。

这和传统提示词注入不同的地方在于，攻击者不一定直接面对模型说”请执行某个危险操作”。

他可以把恶意指令藏在文件里、藏在工具输出里、藏在插件说明里、藏在会话历史里，最后借由上下文拼接机制，被模型当成”系统允许参考的信息”。

所以在智能体里，真正危险的不只是输入内容，而是输入内容在上下文中的角色身份被混淆了。

用户的话、系统规则、工具输出、外部文件、技能说明，这些东西如果在上下文里没有被明确区分，模型就很容易”搞不清谁才是真正该服从的对象”。

4. 网关 WebSocket 接口

这一层对应的是智能体运行时与网关、远程节点或中间服务之间的连接通道。

论文指出，这种连接接口如果允许目标地址被动态篡改，或者允许连接到攻击者控制的端点，就会带来非常现实的风险，比如令牌泄露、会话劫持、远程控制链条被接管。

这类问题看起来不像大家熟悉的”提示词攻击”，但它很像传统系统安全里的连接目的地失控。

只是到了智能体这里，这种失控会和模型工具调用、节点通信、执行链路绑得更紧。

简单说就是：如果智能体可以被引导去连一个它本不该连的地方，那风险已经不只是”它看到了什么”，而是”它把自己的凭证和控制面送到了别人手上”。

5. 工具调度接口

工具调度接口，决定的是模型”想做什么”之后，系统怎么把这个意图落地。

很多人以为问题主要出在工具本身，其实不止。更大的问题是：模型产出的意图，是如何被解释成具体工具调用的。

如果这个映射过程缺少严格约束，那么系统就可能出现几类问题：

本来只是查询操作，却被扩展成写操作； 本来只该访问局部资源，却被调度成全局资源访问； 本来只该调用安全包装后的工具，却落到了底层原生命令接口。

所以工具调度层的核心问题，不是”工具有没有风险”，而是调度过程有没有做权限约束和语义收缩。

6. 执行策略引擎

这是论文里漏洞数量最多的一层，也是大家最容易本能关注的一层。

简单理解，就是系统负责判断：这个命令能不能执行、这个参数能不能通过、这个 shell 语句是不是危险。

OpenClaw 里的大量问题，就集中在这里。论文特别强调了一点：执行策略引擎反复被绕过，不是因为规则不够多，而是因为它的设计前提本身就不可靠。

很多策略引擎默认认为，只要把命令文本解析清楚，就能判断它安不安全，但真实世界不是这样。

shell 有续行语法，busybox 这类工具本身就是多路复用入口，GNU 长选项还支持缩写。也就是说，看起来”像安全”的文本，在真实执行语义里未必安全；看起来”不是危险命令”的字符串，在解释之后也可能变成危险行为。

这就是为什么单纯靠 allowlist、denylist、正则匹配，最后总会出问题。

从这个角度说，执行策略引擎最大的问题，不是漏了一条规则，而是它一直试图用”字符串理解”去管理”真实执行语义”。

7. 容器边界

很多智能体系统都会用容器做隔离，这当然是对的，但论文提醒我们：“用了容器”不等于”有了边界”。

真正的问题是，容器启动时到底允许传哪些参数，挂载了什么目录，用了什么网络模式，隔离策略有没有被收紧。

如果系统把底层容器运行参数几乎原样透传给上层，那么容器就很容易从”安全边界”退化成”看起来像边界”。

比如危险挂载、宿主网络模式、宽松安全配置，本质上都可能把原本应该存在的隔离层直接打穿。

所以容器边界真正的关键词，不是 Docker，不是沙箱，而是：创建时有没有严格验证。

8. 宿主机操作系统接口

这是离真实系统权限最近的一层。

一旦攻击链成功穿过前面的上下文、调度、执行、容器等环节，最终就会落到宿主机接口上。这里的风险包括命令执行、进程控制、文件读写、环境变量、敏感路径访问、主机资源操控等等。

这一层之所以重要，不是因为它”新”，而是因为它是最终影响面。很多智能体安全问题前面看起来像逻辑错误，最后却会在这里变成真正的系统级后果。

9. 大模型服务提供接口

这一层在当前论文的实证里还不算最丰富，但作者已经把它提前列出来了。

因为随着智能体越来越依赖外部模型服务，模型调用链本身也会变成风险传播的一部分。比如路由错误、模型响应污染、服务端策略变更、上下文返回异常等，都可能通过这一层反向影响上游智能体行为。

这部分现在还更像一种前瞻性风险建模，但未来很多安全问题，不一定来自”本地工具”，也可能来自”被默认信任的上游智能服务”。

10. 智能体间通信

这是另一个很值得关注的前瞻方向。

单智能体已经够复杂了，多智能体系统只会把问题进一步放大。

一个智能体如果把另一个智能体的输出当成可信输入，那么提示注入、权限混淆、角色伪装、错误传递都会沿着代理链继续扩散。

换句话说，多智能体场景下，风险不再只是”人攻击模型”，而可能变成：一个被污染的智能体，继续去污染另一个智能体。

这就是为什么作者把”智能体间通信”也列成独立攻击面。今天它也许还不是通告最多的一层，但它几乎一定会是未来越来越重要的一层。

六段攻击链

如果说前面的 10 大攻击面，回答的是”哪里会出问题”，那么六段攻击链回答的就是”攻击怎么往下走”。论文把整条攻击路径拆成了六段：

第一段：初始进入

也就是攻击者先找到入口，把内容、连接、请求、技能包或者伪装身份送进系统。

这一段看似普通，但它的重要性在于：智能体系统的入口远比传统聊天机器人复杂。输入不只来自用户消息，还可能来自文件、渠道、工具输出、插件、远端连接和中间服务。

所以”入口”本身已经不是一个点，而是一组分散的外部接触面。

第二段：上下文操控

这是论文最关键的创新之一。

作者认为，在智能体系统里，攻击链里必须单独加入”上下文操控”这一段。因为攻击者并不一定在初始进入阶段就直接拿到执行权限，他完全可以先污染模型看到的上下文，让模型在后续判断里逐步偏向攻击者的意图。

这其实非常贴近今天很多智能体风险的本质：

不是程序直接被黑，而是模型先被”带偏”； 不是权限接口一开始就失守，而是模型先误以为某条指令是合法的； 不是系统立刻执行恶意命令，而是先改变了”它怎么看世界”的方式。

某种意义上，这一段就是智能体时代最有代表性的安全阶段。

第三段：执行

到了这一步，攻击者的目标已经不只是影响模型想法，而是要把影响真正落到工具调用和系统行为上。

比如命令执行、脚本运行、文件操作、网络请求，都属于这一段。

很多人平时最熟悉的”危险命令""shell 绕过""allowlist 绕过”，主要都发生在这里。

但论文的价值恰恰在于提醒我们：执行层往往只是中后段，不是整个问题的起点。

第四段：凭证获取

一旦系统开始执行，下一步就很可能是获取令牌、会话信息、连接凭证、配置密钥等敏感数据。

这一步之所以危险，是因为智能体系统常常天然具备”代人操作”的特征。

它本来就要保存某些连接信息，本来就要访问某些外部服务，本来就要代表用户去做事。这样一来，一旦凭证泄露，攻击者拿到的就不是普通数据，而是进一步扩张权限的钥匙。

第五段：权限提升

拿到凭证后，攻击者往往不会满足于当前权限，而是继续往更高层走。

比如从普通工具权限提升到网关控制权限，从容器内权限向宿主机扩展，从低风险接口逐步进入高风险系统操作。

这一步在传统安全里并不陌生，但在智能体系统里，它会和”工具组合""上下文误导""代理链路”结合得更紧，所以路径往往更隐蔽。

第六段：最终影响

最后一段，就是攻击真正产生后果的地方。比如：

宿主机被控制； 敏感数据被窃取； 外部服务被滥用； 智能体执行了本不该执行的操作； 整个运行环境被进一步利用去攻击别的系统。

到了这一步，风险已经不再只是”模型行为异常”，而是真实世界的安全后果。

这也恰恰说明，智能体安全绝不能只当成模型安全的一个子话题。因为它最终落地的，是系统安全、业务安全和环境安全。

真正危险的，是跨层串联

这篇论文最值得重视的，不是哪个攻击面排第一，也不是哪个案例最惊悚，而是它揭示了一件事：

OpenClaw 的很多安全问题，单独看未必都算毁灭性漏洞，但一旦跨层串起来，就会形成完整攻击链。

这点特别关键。

因为在真实系统里，很多团队都喜欢做”局部自证安全”：

输入层说，我已经做了鉴权； 上下文层说，我只是传递文本； 调度层说，我只是转成工具调用； 执行层说，我已经做了 allowlist； 容器层说，我已经上了 Docker； 宿主层说，我本身没暴露接口。

每一层都觉得自己已经尽责了，但问题是，没有任何一层真的在为整条链路负责。

于是结果就变成：每一层都”局部合理”，整条链却”不再安全”。

这正是智能体安全最麻烦的地方。因为模型本身就承担着”把上游信息解释成下游动作”的桥梁作用，一旦这个桥梁没有被严格约束，跨层串联几乎是必然的。

5条启发

如果把这篇论文的价值落到工程上，至少有五条非常实用的启发。

1. 身份判断一定要绑定不可变标识

不要拿昵称、展示名、可编辑字段做授权锚点。在多渠道、多平台接入的智能体系统里，授权必须绑定到稳定、不可伪造、不可随意修改的身份标识上。

2. 上下文不是缓存区，而是安全边界

今天很多团队还把上下文窗口当成一种”模型运行材料池”，觉得只要把信息塞进去，模型自己会判断。但这篇论文实际上在告诉我们：上下文本身就是最重要的安全边界之一。

谁写入、从哪来、属于什么角色、是否可信、能不能参与工具决策，这些都必须被明确标注。

3. 命令策略不能只看字符串

只靠正则、allowlist、denylist 管命令，是不够的。更稳的方向应该是：

尽量收缩到结构化参数执行； 尽量绕开 shell 解释层； 尽量减少”自由拼接命令文本”； 尽量把权限控制放到工具语义层，而不是命令字符串层。

一句话说就是：不要再假设”看懂命令文本”就等于控制住了执行风险。

4. 容器隔离要看创建时验证，而不是只看有没有容器

有没有容器，只是起点。真正决定隔离是否成立的，是启动参数、挂载策略、网络模式、安全配置是不是被严控住了。

很多看起来”已经容器化”的系统，其实只是把风险换了个包装。

5. 插件和技能市场要按供应链去治理

插件不是普通内容，技能说明也不是普通文档。它们会直接进入上下文，甚至直接影响模型的行为边界。

所以未来做智能体平台，技能生态必须纳入正式安全治理体系，包括：来源审核、内容审查、权限声明、签名校验、风险分级、上下文来源标注。

不然的话，运行时护栏做得再厚，也可能被”合法装进来的恶意能力”绕过去。

局限性

当然，这篇论文也不是没有短板。

第一，它更像一篇高质量系统复盘，而不是提出了一个全新的安全机制。它擅长总结、归纳、抽象和建模，但没有给出一个经过完整验证的新防御系统。

第二，它的数据基础主要还是来自 OpenClaw，所以它对别的智能体框架虽然有很强参考意义，但终究还是一种”从一个代表性样本向外推广”的分析，而不是跨多个框架的全面实证。

第三，论文里有些攻击面，比如”大模型服务提供接口""智能体间通信”，目前更像是前瞻性风险预判，而不是已经在通告中被大量验证的高频问题。

不过，这些局限并不妨碍它的重要性。因为智能体安全现在最缺的，恰恰不是又一个零散 case，而是一套能够把风险重新组织起来的分析语言。这篇论文，至少在这件事上，做得是比较到位的。