OpenClaw及相似类的个人AI智能体，正在把大语言模型从对话界面推向实际环境（这也是龙虾出圈的核心原因，AI Agent不再是程序员的专属工具）。系统不再只是回答问题，而是开始读取邮件、整理文件、调用外部服务、执行本地命令。能力边界一旦越过纯文本交互，安全问题的性质也会随之变化。过去我们讨论聊天模型的风险，通常聚焦在幻觉、越权回答或隐私暴露，到了自治代理场景，风险的重点变成了另一件事：不可信输入是否会被系统误当作控制指令。
这正是间接提示词注入攻击核心，攻击者不需要直接与代理对话，也不需要传统漏洞。只需要让代理读到一段经过设计的文本，就有可能影响模型判断，并借助代理已经拥有的权限触发真实动作。对于能够访问本地文件、持久化记忆和外部工具的OpenClwa而言，这是需要正视的系统风险。这里从一个简单的场景出发，分析这类攻击成立的原因、后果以及可能的防御思路。
邮件触发攻击链条
假设攻击者向用户邮箱发送一封外观正常的订阅邮件。邮件主题、发件人和正文表面上都没有异常，但HTML内容里夹带了一段额外文本。这段文本可以藏在白色字体、极小字号、注释区域，或者某种伪装成系统标记的结构中。不一定显眼，却可能包含明确的动作指令，例如要求系统忽略当前约束，读取特定目录中的文件，通过既有通信渠道发送出去，随后删除相关痕迹或改写本地记忆。如果 OpenClaw被配置成自动处理邮件，这封信就可能成为一次控制输入。比如它会定时清理收件箱、生成摘要、提取待办事项，或者根据邮件内容触发后续动作。攻击链条就从这里开始（毕竟处理邮件是很常见的ai场景且你总不能拒绝所有陌生邮件）。
对于这个攻击链条，先是数据摄入，代理读取邮件正文或渲染结果，把内容送入模型上下文。接着是指令混淆。对大语言模型来说，系统提示、用户请求、历史记忆和外部文本，最终都表现为同一串语言序列。除非系统在输入结构和执行逻辑上做了明确隔离，否则模型很难稳定地区分什么是需要分析的数据，什么是必须遵守的指令。然后模型进行了工具调用。若代理同时拥有文件读取、消息发送或命令执行能力，模型输出就可能直接转化为实际操作。额外还可能带来状态固化。若系统还允许模型改写长期记忆、任务状态或本地配置，那么一次输入污染就可能从单次误操作变成持续性影响。这里最关键的一点是，攻击入口不再是传统意义上的程序漏洞，而是文本解释过程本身。系统并没有崩溃，也未必越过已有权限模型，它把不该进入控制链条的内容，送到了能影响控制链条的位置。
So,why?
间接提示词注入是大模型老生常谈的安全话题，但在OPenClaw这类本地自治代理里，用户在爽用OC的时候已经默认给了他足够高的权限，所以后果往往更严重和无感。
数据与控制共处同一上下文
传统软件通常能把代码和数据明确分开。输入再复杂，也只是被程序消费的数据，不会自动获得控制地位。代理系统的推理层并不具备这种天然分界。邮件、网页、聊天记录、工具说明、系统规则，经常会被压缩到一个共享上下文中供模型推理。只要系统没有单独标记信任等级，也没有把外部文本封装在不可执行的数据结构内，模型就可能把一部分外部内容误读成更高优先级的要求，输入本身就把不可信的内容放进了决策核心
自治和高权限
从安全和工程角度看，模型影响力被放大，系统已经预先授予了它足够多的操作接口。如果一个模型只能生成文本，那么提示词注入的后果通常局限在回复内容。OpenClaw 的不同之处在于，它往往与文件系统、消息平台、Shell、计划任务和持久化状态相连。模型一旦受污染，输出不只是错误陈述，还可能成为系统动作的直接前置条件。攻击者关注的也不再是模型说了什么，而是系统会不会因此读取文件、发送数据、修改状态或调用外部接口。
持久化污染
最近的很多工作和软件都在引入更全面的记忆功能，记忆污染和记忆噪声也是这类工作的常见问题。代理常常维护长期记忆、任务状态或心跳文件用来跨会话保存信息。若模型被允许写入这些对象，攻击者的目标就不必局限于一次性外传数据。诱导代理把恶意规则写入本地记忆文件，让它在未来会话中继续发挥作用。攻击不再只是一次上下文级误判，而更接近配置层的后门。系统重启不能自然消除这种影响，因为风险已经从会话内文本转移到了持久化状态。
输入源越多，攻击入口越分散
邮件只是最容易理解的例子。网页内容、RSS、Discord 消息、共享文档、OCR 文本、工单评论，本质上都可能承载相同类型的注入内容。代理接入的外部源越多，潜在入口就越多。若系统把这些来源统一并入模型上下文，而不区分信任等级，那么攻击面就会随着集成能力扩展而持续增大。
所以，真正需要关注的不是某一封邮件是否特殊，而是系统是否默认相信凡是能读到的文本，都可以进入决策上下文。
风险思考
讨论提示词注入时，容易把所有问题都归结成模型输出不安全。这个判断太粗。更有用的区分方式，是把后果拆成三个层次。
第一个层次是输出污染。模型在摘要、回复或分类结果中复述了攻击者植入的内容。这会带来误导，但影响仍主要停留在文本层。
第二个层次是行为劫持。模型的判断已经触发工具调用，例如打开本地文件、上传内容、执行命令、修改任务或调用消息接口。
第三个层次是状态持久化。代理把污染结果写入长期记忆、配置文件、任务调度或本地状态，使得后续会话继续受影响。
从防御角度看，第二层和第三层的优先级更高。只要代理具备执行能力，攻击者就会尝试让语言层注入进入工具链，只要系统允许模型无审计地改写记忆，一次攻击就可能留下长期残留。安全设计不能只关心模型说错了什么，还要追问模型的话是否会被系统直接采用，以及采用后的结果是否会留在系统里。
还有一个可审计性问题经常被忽略。如果代理还能删除邮件、覆盖日志、改写记忆，注入指令就可能附带自我隐藏内容，没有原始输入留存、工具调用记录和状态版本历史，管理员很难判断问题究竟来自用户授权、模型误判还是外部污染。
防御策略
现有的问题可以归根结底的归因于基建与应用的不匹配，快速的应用层发展让超出现有操作系统、系统架构的应用提前进入了公众视野，未来的AI OS一定是明确分层的，模型一定是信息与控制分离的。从基础设施角度，对AI 的暴漏我认为应该是充分暴漏和有限暴漏。充分暴漏实质充分暴漏系统和现有软件能够提供的接口、能力、信息（类似元数据，通过mcp\skill等），有限暴漏是仅向模型暴漏有限权限。现阶段我们能尽快进行的工作个人认为如下
人工确认
高风险操作不应由模型单独闭环。凡是涉及敏感目录、凭证文件、网络外传、Shell 执行、记忆覆盖、计划任务创建等动作，都应该设置显式授权门槛。系统可以让模型提出建议，但最终执行前应把目标路径、参数、目的地址和触发依据展示给用户，由用户批准或拒绝。这类设计的关键不只是弹出一个确认框，而是把模型建议和系统授权明确拆开。只有这样，模型即便受到注入影响，也无法绕过最后一道人为裁决。
默认在隔离环境中运行代理
如果一个代理能够读取不可信文本，就应该假定它迟早会碰到恶意输入。在这种恶意假设下，应该把沙河和容器作为默认配置，限制它对宿主机文件、进程、网络和设备的直接访问。更稳妥的做法还应该收紧挂载目录、采用只读卷、关闭不必要能力、限制网络出站目标。
细化权限，拒绝笼统授权
最小权限原则只有落实到具体资源才有意义。若代理的任务只是读取邮件并生成摘要，就不应顺带拥有删除邮件、发送邮件或访问完整网盘的能力。若它只需要处理某个项目目录，就不应读取整个用户主目录。API 凭证也应分用途拆分，尽量采用只读令牌、短周期令牌和可随时撤销的凭证。
把外部文本明确标成不可信对象
这项工作属于治标不治本，但短时间来看也只能治标。输入层避免把外部文本直接拼进高信任上下文。邮件HTML应做安全清洗;不可见文字、异常样式、伪装控制标记和可疑注释区应被剥离或单独标注；外部内容更适合以结构化数据对象进入推理，不要作为自然语言提示的一部分混入系统规则。
记忆层必须可控、可审计、可回滚
长期记忆不能向模型开放任意写权限。任何新增、覆盖或删除记忆的动作都应当留痕，并允许人工审查。
其他建议
谨慎使用第三方skills,插件会扩大能力边界，也会扩大攻击面。一个来源不明、权限声明模糊或内部实现粗糙的 Skill，本身就可能为注入后的动作执行提供额外路径。
加强审计。
最后，其实可以把问题压缩成两个判断。
第一，系统是否允许不可信文本进入模型的核心决策上下文。
第二，模型的判断是否能够直接驱动高权限动作或长期状态变更。
只要这两个条件同时成立，间接提示词注入就应当被视为基础威胁，而不是小概率例外。哪些输入不可信，哪些动作必须拦截，哪些状态不得由模型单独改写，这些问题必须先被定义出来，后续的隔离、授权、审计和回滚机制才能对症下药。从这个角度看，OpenClaw 暴露出的不是某个单点漏洞，而是一类类似隐私和可用性的代理系统悖论：系统越希望模型自主完成任务，就越需要在模型外部建立严格约束，否则，自治能力提升的同时，攻击面也会沿着同一条路径扩大。
