过去一年，Agent 安全讨论里最常出现的词，可能还是 Prompt Injection。
我们已经习惯了这样一种攻击想象：用户让 Agent 读取网页、邮件或者文档，里面藏着一段“忽略以上所有指令”的恶意提示词，模型当场被带偏，然后执行一个错误动作。
这类风险当然重要，但如果 Agent 不再只是一个对话窗口，而是一个长期在线、能记忆、能写技能、能改文件、能设置定时任务、还能调用本机工具的数字执行体，那么提示注入就不再只是“一轮对话里的问题”。
它会变成一种更隐蔽的长期风险。
2026 年 5 月，论文 Sleeper Channels and Provenance Gates: Persistent Prompt Injection in Always-on Autonomous AI Agents 提出了一个很有意思的概念：Sleeper Channel，沉睡通道。
https://arxiv.org/pdf/2605.13471
作者关注的是 OpenClaw、Hermes Agent 这类常驻型 OS-live Agent。
它们把消息入口、长期记忆、自写技能、调度器和 shell 执行能力放进同一个用户权限边界里，结果就打开了一类新的攻击面：
攻击者的内容可以先从一个入口进入 Agent，被写进记忆、技能、文件系统或定时任务中，过一段时间后，再通过另一个看似正常的触发条件释放出来。
这不是传统意义上的“当场骗过模型”。
更像是攻击者把一颗种子埋进 Agent 的未来。
提示注入开始拥有“时间差”
这篇论文最值得关注的地方，在于它把提示注入从“当前上下文污染”，推进到了“跨时间、跨通道、跨执行上下文的持久化污染”。
过去我们讨论提示注入时，通常默认攻击输入和攻击结果发生在同一轮交互里。比如网页里有恶意指令，Agent 读取网页后马上泄露信息。
可是在常驻型 Agent 里，攻击输入可以先沉淀为系统状态。
它可能被总结进长期记忆，可能变成一个新 skill，可能写进某个配置文件，也可能被做成一个未来自动执行的 cron 任务。
等到几天之后，用户发起一个完全正常的请求，Agent 再把之前的污染内容检索出来，并用用户自己的权限去执行。
论文把这种攻击定义为 sleeper-channel attack：
在 T0 时刻，不可信但被系统允许接入的内容进入某个表面，并持久化到某种载体中；
到了 T1 时刻，攻击者不需要再次出现，系统内部的一个触发条件就会让它在另一个表面或执行上下文中产生后果。
这里最关键的变化，是“时间差”。
攻击内容不一定马上生效，而是先睡进去，未来再醒来。
这也是为什么“沉睡通道”这个名字很准确，它描述的不是模型一时糊涂，而是 Agent 的记忆、技能、文件和自动化任务，正在成为攻击者可以长期寄生的地方。
长期记忆投毒，只是其中一类
很多人看到这篇论文，第一反应可能是：这不就是 Agent 长期记忆投毒吗？
答案是：算，但不完全是。
论文明确把 MemoryGraft、AgentPoison、PoisonedRAG 这类长期记忆和检索投毒工作视为前序研究，但作者强调，长期记忆投毒只是整个沉睡通道矩阵中的一个单元格。
真正的问题不止发生在 memory，还可能发生在 skill、plugin、MCP server、文件系统状态和调度器中。
这一区分非常重要。
如果攻击者的内容被写进长期记忆，未来被用户问题重新检索出来，并诱导 Agent 泄露信息，这当然是长期记忆投毒。
但如果这条记忆又被 Agent 用来创建了一个 cron 任务，未来由 cron daemon 自动访问攻击者 URL，那么最终触发点已经不是 memory，而是 scheduler。
攻击链经过了记忆，但真正造成后果的是一个被物化出来的定时任务。
论文为了说明这一点，设计了一个二维分类框架。
第一维是持久化载体，包括上下文窗口、长期记忆、自写 skill、文件系统状态、定时任务或外部触发器。
第二维是触发分离程度，包括同一会话、后续会话、跨通道、跨 actor 和跨执行上下文。传
统单轮提示注入大致落在同一会话里，长期记忆投毒落在 memory 这一格，而本文重点关注的是过去研究不足的 skill、filesystem 和 scheduler 等区域。
从这个角度看，Agent 安全不能只问“模型会不会被坏 prompt 骗”。
更应该问：坏内容进入系统后，会被保存在哪里？会被谁再次读取？会不会被改写成工具参数？会不会被写入 skill？会不会在未来由另一个进程执行？
这才是 Agent 时代的提示注入问题。
四个典型攻击场景
论文中最核心的案例，是一个通过 cron 触发的 confused deputy 攻击。
攻击者先发送一封看起来很正常的邮件，内容大概是“每日健康检查建议”，但邮件正文里藏着一个指向攻击者服务器的 webhook URL。Agent 的记忆系统把这封邮件总结成一条长期记忆，并把这个 URL 一起保存下来。几天后，用户对 Agent 说：“帮我设置一下之前邮件里提到的每日健康检查。”Agent 检索出那条记忆，生成一个 cron.add 调用，并把攻击者的 webhook URL 填进参数里。运行时看到的是用户正在创建定时任务，于是把这个动作当成 owner-issued action 处理。最终，一个未来自动触发的 cron 任务就被创建出来了。
这个案例真正危险的地方，不在于工具名。
用户看到的可能只是“创建定时任务”；系统看到的可能也是一个 owner-only 的 cron 工具调用。
但真正决定风险的是参数：那个 URL 来自攻击者邮件，而不是来自用户可信输入。
Agent 在这里扮演了一个“糊涂代理人”的角色，它拿着用户权限，替攻击者完成了动作。
这就是经典的 confused deputy 问题在 Agent 场景下的重现。
在传统软件安全里，confused deputy 指的是一个拥有高权限的程序，被低权限主体诱导去执行不该执行的操作。
在 Agent 时代，这个问题变得更隐蔽。
因为低权限输入不一定直接调用高权限工具，而是先进入记忆、摘要、规划、工具参数生成等链路，最后再以“用户请求”的形式出现在运行时面前。
论文还给了另外几个攻击草图。
第一个是通过群聊写入 skill。某些配置下，群聊沙箱可以拥有 workspace 写权限。如果 Agent 被诱导在共享工作区中生成或修改 skill，主会话之后又会从这个工作区加载 skill，那么一次来自群聊的不可信输入，就可能变成未来主会话中的技能木马。作者也很谨慎地说明，这个案例依赖非默认的 workspaceAccess="rw" 配置，并不是默认必然成立。但它展示了一个很现实的问题：当 Agent 拥有“自我改进”“自写工具”“自动生成 skill”的能力后，工具链本身也会成为攻击目标。
第二个是跨通道记忆外泄。攻击者邮件被总结进 memory，后续用户在另一个通道里提出相关问题，Agent 检索到污染记忆后，可能触发外发邮件或网络请求。这类攻击更接近我们熟悉的长期记忆投毒，但它的后果已经不只是“回答变差”，而是可能变成一个有副作用的动作。
第三个是文件系统投毒。用户让 Agent 参考某个网页修改 shell 配置，网页里藏着恶意 .zshrc 行。Agent 当下只是写了一个文件，真正的触发发生在未来某次用户打开 shell 时。这类风险尤其麻烦，因为最终执行者甚至不一定是 Agent，而可能是 shell、cron、git hook 或其他系统进程。论文也因此强调，沉睡通道既可以由 owner 触发，也可以由 Agent 自主循环触发，还可以由外部执行环境触发。
这说明 Agent 安全的对象正在扩大。
过去我们主要保护模型输入输出，现在还要保护 Agent 的长期状态；
过去我们主要担心当前响应，现在还要担心未来执行；
过去我们把工具调用当作模型能力的延伸，现在必须把工具调用看作权限边界的一部分。
只把来源写进 Prompt，远远不够
面对这种风险，一个直觉方案是：既然外部内容不可信，那就给它打标签，然后把标签写进模型上下文里，提醒模型不要相信。
这类方案有价值，但论文认为它不够。
OpenClaw 已经有一些类似机制。
论文提到，它会用 XML marker 包裹外部不可信内容，也会在上下文中插入安全提示；它还有针对 shell 命令的 owner approval 机制。
但问题在于，这些机制要么仍然依赖模型理解上下文警告，要么按工具身份审批，而不是按数据来源审批。
也就是说，系统知道“这是 cron 工具”，但未必知道“cron 参数里的 URL 来自一封不可信邮件”。
论文围绕 A4 做了一个小规模探针实验，研究者把 OpenClaw 的安全警告、带有攻击者 URL 的 recalled memory note，以及用户设置 daily health-check 的请求一起给到一个前沿推理模型。
结果在 20 次单轮试验中，有 19 次模型仍然生成了可运行的 cron.add，而且 delivery.to 指向攻击者 URL；在两阶段变体中，10 次里仍有 7 次产生攻击者想要的结果。
作者也很谨慎地说，这只是一个 smoke probe，不是完整量化评测，但它足以说明：把 provenance 放进上下文里，并不能自然形成可靠的安全边界。
这对今天很多 Agent 安全方案都有提醒意义。
如果安全机制只是“告诉模型这个内容来自外部”，它仍然可能在复杂任务中被模型重新吸收、改写和组合。尤其在 Agent 场景下，模型并不是最终动作执行者，运行时才是。
真正可靠的防线，不能只放在 prompt 里，而要放在动作执行前。
Provenance Gate：把来源治理放到运行时
论文提出的核心防御叫 Provenance Gate。
它的基本思想很简单：所有进入 Agent 的内容都要带有来源标签，之后无论它被写进 memory、从 memory 检索出来、变成 skill、写进文件、拼进工具参数，系统都要持续传播这些来源信息。
等到某个有后果的动作真正要执行前，运行时必须检查这个动作背后的所有因果输入。如果里面混入了不可信来源，就拒绝执行，除非用户通过模型无法伪造的外部通道，对这一次具体动作给出明确授权。
为了把这件事落地，作者设计了十个 mediation hook。
前五个 hook 负责打标签和传播来源，覆盖入口适配器、记忆写入、记忆检索、skill/plugin/MCP 的创建与修改、skill/plugin/MCP 加载。
后五个 hook 负责在副作用动作之前进行拦截，覆盖工具调用构造、host shell 执行、文件系统写入、调度任务创建修改、对外网络和消息发送。
论文特别强调，任何没有被分类但会改变状态的动作，都应该默认 fail-closed。
这里最重要的变化，是审批粒度从“工具级”变成了“动作实例级”。
传统做法可能是：用户批准 Agent 使用 cron 工具。可这太粗了，因为真正危险的不是 cron 这个工具名，而是这一次 cron 任务的具体参数、触发频率、目标 URL、数据来源和未来执行上下文。
论文的 D2 方案要求为每个 consequential action 计算因果集合和 provenance 集合，只有当所有贡献者都可信，或者用户对这一个动作实例给出绑定授权时，才允许执行。
这相当于把安全问题从“你能不能用这个工具”，改成“你为什么要以这个参数、基于这些来源、执行这一次动作”。
这对 Agent 安全产品非常关键。
不是内容审核，而是运行时权限治理
从模安局的视角看，这篇论文最重要的启发，是它把 Agent 安全从内容审核推向了运行时权限治理。
大模型内容安全更多关注模型说了什么，是否违规，是否危险，是否幻觉。
但 Agent 的风险不只是“说错话”，而是“做错事”。它可能发邮件、改文件、装插件、访问外网、调用 MCP 工具、创建定时任务、读取联系人、执行 shell。只要这些动作与外部不可信内容发生了因果关系，就不能只依赖模型自觉。
这意味着未来 Agent 安全产品至少需要几类能力。
第一类是统一来源账本。来自用户、群聊、邮件、网页、RAG、MCP、skill、工具返回值的内容，都应该拥有可追踪的 provenance metadata。这个信息不能只写进 prompt，而要作为运行时元数据被保存和传播。
第二类是跨模块传播能力。内容从输入进入 memory，从 memory 进入 planner，从 planner 进入工具参数，从工具结果进入文件系统，每一次转换都可能成为“洗白”通道。真正的来源治理，要能穿过摘要、改写、检索、规划和工具调用。
第三类是副作用动作闭集化。发消息、访问网络、写文件、执行 shell、创建定时任务、安装或修改 skill、调用高危 MCP 工具，都应该进入强制 gate。未知动作默认拒绝，而不是默认放行。
第四类是动作实例级审批。让用户批准“使用某个工具”意义有限，更有价值的是让用户批准“这一次动作的具体参数和来源”。比如不是批准“发邮件”，而是批准“向谁发、发什么、依据哪些内容发”。
第五类是 skill / MCP 权限清单。每个 skill 或 MCP server 应该声明自己的能力边界，是否能读文件，是否能写文件，是否能访问网络，是否能处理不可信内容，是否能修改自身。这一点和论文里的 D3 思路非常接近。D3 要求每个 skill 有 capability manifest，并在安装时由可信主体签名，从而避免自改进 skill 悄悄扩大自己的权限。
这些能力组合起来，才更接近真正的 Agent Runtime Security。
局限性
当然，这篇论文不能被过度神化。
首先，它不是一篇完整实证论文。作者自己也明确说，本文是 position and design paper，主要贡献是定义威胁、构建分类法、给出防御设计和部分参考实现，大规模攻击成功率测量与防御效果评估属于后续工作。
其次，D2 的前提很强。它要求所有 artifact 的读写都经过 hook，要求系统能维护可靠的 provenance，要求运行时可以计算 causal set，要求用户授权通过模型无法伪造的通道进入，还要求 nonce、防重放、hash 绑定等机制都正确实现。论文也承认，如果某些 skill 可以绕过 H1-H10 直接通过 FFI、side-channel storage、环境变量或浏览器插件状态产生副作用，那么 Provenance Gate 本身无法拦住这些路径，仍然需要 seccomp、container、microVM 等外围沙箱配合。
第三，产品体验会很难。动作实例级审批在安全上更精确，但对普通用户来说，理解“这个参数来自不可信邮件”“这个定时任务未来会访问某个 webhook”“这个 skill 同时拥有读文件和外联能力”，并不容易。如何把复杂的 provenance 和 causal chain 转化成用户能看懂、愿意判断、不会疲劳点击的交互，是这类方案真正落地时绕不开的问题。
所以这篇论文的价值，不在于它已经给出了一个可以直接商用的完整产品，而在于它提出了一个非常重要的方向：Agent 安全不能只在模型输入输出处加过滤器，而要在运行时建立来源传播、动作约束和权限治理机制。
写在最后
如果用一句话概括这篇论文，我认为是：
提示注入正在从对话攻击，演变为 Agent 生命周期中的状态污染和权限错配。
这是一个很关键的变化。
当 Agent 只是聊天机器人时，提示注入主要影响模型说什么。当 Agent 变成常驻执行体后，提示注入会影响它记住什么、写下什么、安装什么、调度什么，以及未来以谁的权限执行什么。
攻击者不一定需要一直在线，也不一定需要当场打穿模型。只要它能把影响埋进 Agent 的长期状态里，就可能等待下一次正常触发。
这正是“沉睡通道”这个概念的警示意义。
对 Agent 安全来说，未来真正重要的问题不只是“如何检测恶意 prompt”，而是“如何治理 Agent 内部不断流动的来源、状态和权限”。
长期记忆、技能系统、MCP 工具链、文件系统和调度器，都会成为新的安全边界，谁能把这些边界管住，谁才真正接近 Agent 时代的安全底座。
声明：本文来自模安局，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
