夜雨聆风最近两个月，围绕 OpenClaw 一类智能体的讨论，很多都集中在“会不会被提示注入攻破”“会不会乱执行命令”“某个恶意 skill 到底多危险”这些具体问题上。今天要介绍的这篇文章把问题往上提了一层：类 OpenClaw 智能体的安全，本质上不是单点漏洞问题，而是系统工程问题。 因为这类系统把不可信输入、自主执行、插件扩展和真实权限，放进了同一个运行闭环里，所以它天然不是“默认安全”的。
https://arxiv.org/pdf/2603.13151
这篇论文标题叫 Defensible Design for OpenClaw: Securing Autonomous Tool-Invoking Agents。作者没有把 OpenClaw 当成某一个孤立产品，而是把它当作一类“环境交互型智能体”的代表：它们不只是聊天，而是会浏览网页、读写本地文件、调用外部工具、连接 API，并且在真实操作环境里持续完成任务。也正因为如此，安全问题不能只看模型回答对不对，而要看它在什么权限下运行、如何调用工具、如何加载扩展、如何被审计和约束。
论文给出的一个非常关键的判断是：能力已经不能和执行上下文分开来看。 同样一句模型输出，在普通聊天机器人里可能只是“说错了一句话”；但在类 OpenClaw 智能体里，它可能会直接变成读文件、发请求、装插件、调用命令、修改状态的一连串动作。也就是说，真正需要治理的，不只是“模型内容”，而是“模型输出如何进入执行链条”。
从这个角度看，这篇论文最核心的贡献，就是给出了一套非常清晰的框架：四类风险，四个工程防护原则。 这套框架最大的好处，是它把大家过去零散讨论的提示注入、误操作、插件投毒、部署漏洞，统一收束到了一个完整的安全视角里。
类OpenClaw智能体“默认不安全”
论文开宗明义地指出，类 OpenClaw 智能体之所以危险，不是因为某一项能力本身不可控，而是因为四种特征叠加后，形成了结构性风险：
第一，它会持续摄入网页、文档、截图、文件、邮件等混合信任输入；
第二，它不是只给建议，而是会自主继续执行任务；
第三，它可以通过 skill、plugin、tool integration 等方式不断扩展能力；
第四，它通常还持有文件、凭证、API、系统功能等现实权限。这四点单独看都不算新鲜，但放在一个统一控制环里，就会彼此放大。
论文中的架构图也很说明问题：用户请求、网页文档截图、本地工作区、记忆状态、云端 LLM、工具调用、浏览器和系统执行，以及权限、监督、日志这些治理信号，都被纳入同一个操作闭环。换句话说，这已经不是一个“文本生成系统”，而是一套具备感知、决策、执行和状态积累能力的操作系统雏形。 一旦其中任一环节被污染、误导或越权，问题就会沿着整个链条放大。
这也是为什么，论文反复强调：OpenClaw 安全不能只理解为“模型安全”，而应该理解为“软件安全工程”。因为真正需要回答的问题，不是“模型会不会乱说话”，而是“一个能够持续读取环境、自动决策、并调用真实能力的智能体，如何被设计成可约束、可治理、可审计”。
四类风险
第一类风险：提示注入
论文把 Prompt Injection 放在第一类，而且定义得非常准确：它不是一般意义上的“坏内容污染”，而是混合信任输入改变了智能体的有效控制流。隐藏在网页、文档、邮件、截图、本地笔记甚至元数据里的文本，可能会在预处理后依然保留下来，并被系统当成合法任务指令，从而与用户原始目标竞争。
这一定义非常重要。因为它直接把 Prompt Injection 从“内容合规问题”提升成了“指令通道劫持问题”。论文明确说，问题核心不是 hallucination，而是通过不可信输入实施的间接指令劫持。在普通聊天系统里，恶意文本可能只是让模型给出错误答案；但在环境交互型智能体里，同样的文本却可能把一个自主且有权限的执行闭环，重定向到秘密读取、危险跳转、未授权传输等真实动作上。
论文还特别指出，提示注入的影响不只是当下这一轮。它还可能进入历史记录、检索结果、缓存状态和长期记忆，形成持续上下文污染，在后续计划和执行中继续发挥作用。也就是说，对类 OpenClaw 智能体来说，提示注入不是“一次性绕过”，而更像是一种能够跨轮次、跨状态残留的控制污染。
从“模安局”的视角看，这里最值得强调的一点是：不要再把提示注入简单理解为“让模型说了不该说的话”。 对 Agent 来说，它更接近控制流劫持。文本只是载体，真正被接管的是后续动作链条。
第二类风险：有害误操作
论文第二类风险叫 Harmful Misoperation，这是很有价值的一类。它专门强调：这类事故不一定需要攻击者。很多时候，用户目标本身就带有歧义，环境状态又不完整，智能体会在不确定下继续推断、扩展任务范围、自动补全意图，最后把一个原本模糊但无害的请求，执行成了真实世界里的有害动作。
论文在表述中用了一个很有意思的词，叫 authority drift。意思是说，智能体会在连续执行中逐渐漂移：它以为自己理解了用户意图，于是继续做、继续扩、继续调工具，结果权限和行为边界也跟着一路扩大。到了执行面，这种误操作还会进一步表现为过度授权工具、危险命令构造、未经检查的外部动作，最终把模型输出直接转化为系统 compromise。
这类问题为什么特别值得单独拎出来？因为它提醒我们，Agent 安全不只是对抗攻击者，很多时候还要对抗系统自己的“过度自信”。模型不是被坏人骗了才会出错，它可能在“好心帮忙”的过程中就把事情做坏。对于企业场景尤其如此：不是每一次越权删除、错误发送、误调用接口，背后都有恶意攻击；更多时候，是系统在高自治下把模糊目标执行过头了。这个判断，其实比单纯讨论越狱攻击更贴近真实落地。
第三类风险：扩展供应链风险
第三类风险是 Extension Supply-Chain Risk。论文对这一点的表述很硬核：扩展、插件、工具封装、工作流组件、更新通道，都不应该被当作安全模型之外的“便利层”。因为每新增一个 extension，系统引入的不只是新功能，而是新的 prompt、新的代码、新的权限、新的行为假设，整个可信计算基都在跟着扩大。
论文列举的失败模式很典型：安装或调用恶意插件导致本地数据被外传；任务经由被攻陷的工具封装转发，访问范围被悄悄扩大；一次更新改变执行行为，朝着更有利于攻击者的方向演化；或者导入一个工作流组件，里面藏着足以篡改用户任务的隐含指令。这些问题麻烦的地方在于，Agent 不是“建议你去装插件”，而是会把这些组件直接装进自己的自治闭环里。
所以，插件风险在 Agent 体系里和传统软件还不完全一样。传统软件装了恶意插件，可能只是某个功能被污染；但类 OpenClaw 智能体一旦加载了有问题的 skill，它继承的是已有的浏览、读写、调用工具、访问状态等现实能力。于是，一个看起来“挺好用”的第三方扩展，实际上可能变成长期数据外流、工作流操纵和权限滥用的持久入口。
这也是为什么，未来的 skill 生态一定不只是“谁功能多谁赢”，而会迅速演变成“谁的来源可信、声明清楚、权限可控、能被吊销”的治理竞争。
第四类风险：部署漏洞
论文第四类风险是 Deployment Vulnerabilities。这一类表面上看有点“传统”，但恰恰说明作者没有把 Agent 安全窄化成模型安全。论文指出，网关认证与路由、会话绑定、暴露端点、返回内容传播、日志和持久化存储等环节，都可能出现控制面信任失败、敏感外泄和取证污染。
比如网关层若认证弱、端点暴露、session 绑定错误，未授权请求就可能继承合法执行上下文；响应阶段如果把本地状态、秘密或危险内容向外返回，又被继续转发到下游聊天、平台或工作流中，风险会继续扩散；日志和持久化阶段如果记录被污染，甚至会让攻击内容在后续会话中再次被读到和复用。
为什么这些“老问题”在 Agent 场景里更危险？因为 Agent 通常是持续在线、连接外部服务、带有记忆状态、持有系统权限的。一个普通聊天机器人就算部署不严，很多时候伤害面还停留在文本层；但一个会自动执行、还能长期累积凭证和工件的环境交互型智能体，一旦部署面失守，拿到的就不再只是一个对话窗口，而是一套能持续替你做事的自动化系统。
风险执行链
这篇论文还有一个特别值得借鉴的点，是它没有只停留在“四类风险”的标签层，而是又给出了一张按执行阶段重排的风险表。也就是说，它提醒我们，这四类风险不是并列摆在 PPT 上的四个框，而是会沿着同一条运行链条发生：消息摄入、上下文拼装、运行时规划、工具执行、插件加载、响应输出、日志留存，每一步都有不同主导风险，但它们之间是连着的。
这其实比“分类”本身更重要。因为很多团队今天做防护，还是按问题类型堆补丁：这里加个提示过滤，那里加个人工审批，再给插件做个黑白名单。可论文真正想说的是：Agent 风险是链式积累的。 输入污染、计划漂移、工具越权、插件投毒、部署薄弱，往往不是谁单独致命，而是一路串起来后才致命。
四个工程防护原则
第一个工程原则：最小权限
在风险分类之后，论文提出第一个工程原则：Least Privilege。作者强调，对环境交互型智能体来说，最小权限和能力边界控制，是基础中的基础。因为这类系统会浏览、读文件、调工具，并在没有人工重新授权的情况下连续执行任务，所以它只能拿到当前任务所需的最小权限、最小资源和最小动作范围。即便碰到异常输入，或者它对用户意图只有部分理解，这个边界也不能失效。
为什么这一条这么重要？因为它能同时对两类问题起作用。一方面，提示注入再厉害，如果智能体压根拿不到广泛的文件、网络和账号访问，就很难把文本操纵转成大范围破坏；另一方面，误操作再频繁，如果系统一开始就把动作边界卡得足够窄，错误分支的伤害半径也会被限制住。
很多团队现在一提权限控制，想到的还是“要不要弹个确认框”。但论文的意思并不是再多做几个弹窗，而是要把权限设计做到架构层：智能体到底能读哪些目录、调用哪些接口、访问哪个知识库、执行哪类动作，这些要在任务开始之前就被限定清楚。对类 OpenClaw 智能体来说，确认框不是权限架构，能力边界才是权限架构。 这也是这篇文章最值得企业 Agent 产品经理认真吸收的一点。
第二个工程原则：运行时隔离
第二个原则是 Runtime Isolation。论文指出，这类系统的部署环境里，浏览器、工具调用、文件访问、凭证使用，往往都在同一个运行路径上。因此，系统必须有明确的隔离边界：不同 session、不同 tool、不同 extension，到底能访问什么，必须被隔开；secret 也应该按需暴露，而不是默认放进智能体的环境上下文里。
这条原则的意义，是把很多本来“局部”的问题限制在局部。无论是传统软件漏洞、错误部署配置、提示注入，还是恶意插件，如果它们可以自由接触 token、本地状态、邻近服务和更多上下文，就很容易从一个点扩成整面。论文说得很清楚：类 OpenClaw 智能体不是单进程的小程序，而是跨 session 持续运行、连接外部服务、积累凭证、日志和工件的部署系统。如果没有真正的隔离和严格的 secret hygiene，一个被攻陷的浏览器 session、一次过度授权的工具调用、一个不安全的扩展，都可能从局部失败升级成更大范围的组织级 breach。
换句话说，Agent 再聪明，也不该直接继承宿主运行时的全部 blast radius。浏览器隔离、文件系统隔离、容器/沙箱隔离、临时令牌、最小可见 secret，这些在 Agent 时代都不再是“安全加分项”，而是基本盘。
第三个工程原则：扩展治理
第三个原则是 Extension Governance。论文认为，扩展的信任、来源和权限治理，应该被视为一等公民的工程原则。因为环境交互型智能体的大部分实用性，恰恰就来自 skills、plugins、tool wrappers、packaged workflows 和 update channels；而这些机制每引入一次，就在扩大可信计算基。
论文在这里的态度非常鲜明：可扩展性不是安全模型之外的便利层。 每一个扩展路径，导入的都是新的 prompt、新的代码、新的权限和新的行为假设。如果 provenance 弱、权限治理模糊、更新通道不可追踪，那么一个恶意或被静默修改的依赖，就会成为长期的数据外流和权限滥用通道。
因此，未来真正靠谱的 Agent 平台，不会只比拼“有多少 skill”，而会比拼有没有发布者身份、权限声明、来源证明、完整性校验、attestation 和吊销机制。论文在研究议程里甚至明确提到，signed extension manifest 是值得探索的设计方向。这个思路很像移动应用商店、浏览器扩展商店、容器制品签名那一套，只不过现在要被迁移到智能体技能生态里。
第四个工程原则：可审计性
第四个原则是 Auditability。这部分很容易被低估，但其实特别关键。论文强调，日志、审计和取证可见性，对自治环境交互型智能体来说不是附加功能，而是基础能力。因为这类系统的失败往往不是一个孤立 bug，而是一连串多步动作：它读了什么混合信任内容，走了哪条决策路径，用了哪种权限，调用了哪个外部组件，最后在哪里越过了边界，这些都必须能被追溯。
论文明确指出，没有决策轨迹，就很难在事后区分到底是 prompt injection 还是 harmful misoperation；没有组件可见性和 provenance，就很难定位扩展滥用和供应链入侵；只有普通 debugging logs，没有安全相关证据，也很难处理部署和运行时 compromise。也就是说，没有可归因执行轨迹，就没有真正意义上的运营治理。
这一点尤其值得企业场景重视。很多团队做 Agent 日志，今天还停留在“调用了哪个 tool、返回了什么结果”这种粗粒度记录上。但论文真正要求的是：输入来源、上下文拼装、权限使用、决策路径、工具调用、外部组件影响，都要形成可观察、可归因的执行链。这种能力，既服务于问责和取证，也服务于后续的规则优化和风险处置。
四个研究方向
论文最后没有停在原则层，而是把这些内容进一步转成了四个研究方向：评测基础设施、权限架构、扩展治理、自适应监督与可归因遥测。它希望未来的环境交互型智能体，不是靠一次次补漏洞维持运转，而是从一开始就被设计成testable、bounded、governable、auditable。
这个收束其实很漂亮。因为它说明，论文最关心的不是“怎么多挡住几个攻击样本”，而是怎么把智能体安全真正制度化、工程化。尤其是在权限架构这部分，作者明确提出：下一步不是继续堆 warning，而是要研究如何把自然语言层面的任务目标，映射成受边界约束的 delegated authority。说白了，未来真正难的不是让 Agent 更会做事，而是让它只在该做的范围内做事。
结语
如果用一句话概括这篇论文的价值，那就是：它把类 OpenClaw 智能体的安全问题，从“模型会不会出错”，升级成了“一个会持续看、持续想、持续调工具、还能直接操作系统的自治体，如何被设计在可治理的权力边界里”。
这也是为什么，论文给出的答案不是继续做更强的内容过滤，也不是指望模型本身永远不犯错，而是回到四个最硬的工程原则：最小权限、运行时隔离、扩展治理、可审计性。它想告诉行业的是，Agent 的问题从来不只是“说什么”，而是“看什么、信什么、调什么、能做什么、出了事怎么追”。
对今天所有想把类 OpenClaw 智能体推向企业、工作流和真实业务系统的人来说，这篇论文最大的提醒也许就是：没有权限架构，就没有真正的 Agent 落地；没有隔离和治理，自治能力就只是在放大事故半径；没有可审计性，所谓安全运营也无从谈起。
