🛡️ 安全风险

Loopjacking(人机回环审批劫持)

别名:循环劫持审批劫持人机回环审批劫持Loopjacking审批-效果绑定失效
分类🛡️ 安全风险
阅读时间⏱️ 16 分钟
更新时间📅 2026-10-26
条目编号ENC-SECURITY-21-loopjacking
人机回环审批劫持:人类批准的是其理解中的操作A,系统实现却把这次批准用于实质不同的操作B,即「审批所见」与「实际执行」之间的绑定失效。

关键要点 ✦

术语界定与判定要件

论文把 Loopjacking 定义为「人机回环审批到授权效果」这一绑定的失效:人类基于对操作A的理解作出批准,而产品实现把该决定用于实质不同的操作B。一个成立的判定需要满足若干要件:存在真实的人类决定且其理解为A、操作B与A存在实质性差异、攻击者影响可达待决状态、产品自身消费了这次批准并用于B、最终落入有实际影响的执行端,且攻击者没有绕过审批直达B的等效路径。

这一界定有意排除了若干相邻情形:人类明知内容仍被说服批准的普通诱导、与人类决定无关的通用可变状态篡改、没有人类决定参与的确认伪造,以及不复用批准结果的提示注入。作者同时声明其贡献不同于既有研究中的误导性对话框、会话走私、动作绑定与授权连续性等方向。这个边界让术语保持可测试性,避免把一切审批失效都装进同一个名词。

两种攻击变体

表征型攻击中,危险操作在批准时刻就已经编码在完整请求里,但审批界面只展示了一个不完整的片段或对参数作了错报——人类真诚地同意了屏幕上的内容,而屏幕上的内容只是载荷的部分投影。审批后状态替换型攻击则不同:界面如实呈现操作A,人类审阅无误后批准,随后某个有权限修改待决任务、线程、会话或延续状态的角色把A换成B,产品拿着仍然有效的批准决定去执行B。

论文给出的示意场景:管理员审批向合规供应商转账 20 个单位,批准被消费前,待决参数被替换为向攻击者控制的地址转账 2000 个单位——放大百倍,而审批记录上是一笔小额合规转账。替换型之所以更棘手,在于审阅者当时做对了所有事,批准却只是被系统事后兑付成了另一份「货」。

复现结果与阴性对照

受测对象为一批已正式发布的智能体产品路径。审批后状态替换在 Agno AgentOS 七个受测发布版(截至 3.0.9;复现归档标注受影响区间自 2.5.6 起、2.5.5 为对照边界)和 LangGraph Agent Server 特定内存组合的十二个受测版本(0.7.5 至 0.14.0)中复现;后者依赖被测的内存配置与授权策略——当策略允许非审批者编辑待决线程时才可复现,受支持的拒绝策略可阻止攻击,论文也未对默认或基于 Postgres 的生产部署作出断言。表征错配在 OpenClaw 2026.2.23 复现,且在 2026.2.24 被修复,对应公开漏洞 CVE-2026-32052(OpenClaw 官方评级为中等)。

阴性对照是这项研究里信息量最大的部分:OpenAI Agents SDK 0.22.0 与 0.22.2 在同样的审批后状态替换测试中拒绝执行被篡改的B——普通按调用审批会保留精确调用的规范化记录,序列化延续把批准对象原样带到执行时刻。这说明「可恢复、可序列化」本身不等于「会复用过期批准」,问题出在从活动状态重建操作的实现方式上。需要说明的是,论文也明确该对照不覆盖应用层自建的「始终批准」策略或攻击者能伪造全部受信规范化字段的情形,且未对表征型变体测试该 SDK。

防御设计要点

论文验证了两条互补的防线。其一是完整规范化呈现与精确用时比对:审批界面渲染操作的完整权威形态(全部参数与影响面),执行时刻将实际待执行调用与批准记录精确比对,不一致即拒绝。其二是授权策略:阻止不可信主体修改待批准状态,从源头切断替换路径。两者都不需要更聪明的模型、更好的提示词或新产品形态,属于纯粹的系统设计决策。

序列化延续值得单独强调:把批准的调用作为固定对象随执行链携带,而不是在执行时从可变状态重建,天然免疫替换攻击。这与本站人机回环条目(ENC-ARCH-20)给出的审批门设计形成互补——那一篇讲「门要设在哪里」,这一篇讲「门本身可能被绕过」。

与相邻安全议题的边界

与工具投毒攻击(ENC-SECURITY-20)相比:工具投毒污染的是智能体可见的能力目录,诱导模型主动选择恶意工具;Loopjacking 攻击的是人类审批环节自身的绑定机制,模型行为甚至可以完全正常。与混淆代理人问题(ENC-SECURITY-17)相比:混淆代理人滥用的是既有合法授权,Loopjacking 则瞄准「人类决定到系统授权」的转换瞬间。

对安全团队的启示是把「审批-执行一致性」加入测试清单:审批界面是否完整呈现、批准记录是否随调用序列化、待决状态谁能改、执行时刻有没有比对。据论文与第三方分析,Agno 与 LangGraph 的复现结果截至其证据截止日无厂商修复版本,也无 CVE/CVSS 评级,后续进展目前官方及行业暂未披露更多细节,后续将持续跟进迭代动态。

🎯 应用场景

企业审批流水线
低权限用户发起、管理员审批的资金调拨、数据导出等操作,防止待决参数在批准与执行之间被调包。
编码智能体工具门控
shell 执行、文件写入等敏感工具的人工批准场景,确保批准记录只对应当次调用、不可被复用。
安全评估与红队
把审批-执行绑定一致性纳入智能体产品安全测试基线,验证渲染完整性与用时比对机制。

✅ 最佳实践

  • 审批界面渲染完整规范化操作(含全部参数与影响面),不做摘要式或片段式呈现。
  • 执行时刻将待执行调用与批准记录精确比对,不一致即拒绝,而非信任「已批准」标记。
  • 用授权策略禁止非审批者修改待决会话、线程或延续状态;优先采纳序列化延续而非从活动状态重建操作。
  • 为每次批准留存防篡改审计记录,出现替换痕迹可告警与回溯。
  • 关注上游框架版本与配置动态:复现结论依赖特定版本与授权策略配置,升级或改用拒绝策略会改变风险面。

🔮 未来展望

审批绑定有望从界面约定下沉为运行时保证:批准对象以不可变结构随执行链传递、由平台统一校验,逐渐成为智能体框架的默认行为。评估侧预计会出现把审批-执行一致性纳入常规红队清单的标准化测试方法;审计与合规也会要求批准记录与实际执行可逐一对账。

📖 相关条目

🛠️ 相关产品

🏷️ 标签安全风险人机回环审批劫持漏洞研究智能体框架授权绑定