AI Security

外观

AI 供应链与制品安全 · A3.3 Tool、插件与 Server 分发安全更新 2026-09-06约 6 分钟证据：中等 来源：arXiv:2609.03884

Agent Harness 生命周期钩子更新攻击研究 ​

摘要 ​

HookPry 研究指出，Agent Harness 的生命周期钩子可把会话启动、工具调用或文件修改等事件直接绑定到宿主命令。攻击者先发布行为正常的插件，再通过同一插件身份的后续更新加入钩子配置；如果更新流程没有重新核验权限变化，Harness 会在大模型决策链之外触发新增命令。最先失效的控制是插件更新的来源与能力差分审批，而不是模型拒答或提示词防护。

作者在 7 个 Harness、5 个大模型后端构成的 25 种组合上完成 1,000 次端到端运行，覆盖 10 类攻击目标。论文报告 77.0% 的运行产生预言机确认的完整效果，单个 Harness 的最高成功率为 92.5%；Microsoft Defender 在该实验中的召回率为 0%，三种静态防护取并集后仍漏检 47.5% 的恶意工件。这些数字仅适用于作者选择的版本、目标与判定器，不代表所有插件更新或 Harness 均可被利用。

核心创新与差异 ​

原研究贡献是把生命周期钩子更新从一般插件恶意代码中单独抽象出来，并提出由对抗性清单优化（Adversarial Manifest Optimization, AMO）、时间解耦（Temporal Decoupling, TD）和最小公共接口（Least Common Interface, LCI）组成的 HookPry。AMO 面向插件发现，TD 把初始信任获取与后续高权限更新分开，LCI 将同一抽象目标适配为不同 Harness 的事件与命令表示。

本站分析认为，该攻击与真实技能供应链投毒活动共同强调更新后重新审批的重要性，但 HookPry 的关键差异是执行路径：钩子由 Harness 直接处理，命令不必由模型解释、生成或选择。因此，模型级拒答、提示词注入检测和只观察工具调用轨迹的防护都可能错过这条控制路径。

威胁模型与攻击链 ​

攻击者可以控制第三方插件的市场元数据、版本发布和生命周期钩子配置，但不预先控制受害宿主，也不能强制用户安装插件。攻击成立还要求受害者采用后续版本、对应事件实际发生，并且钩子子进程拥有足以产生目标效果的宿主权限。

  1. 攻击者发布功能正常、描述合理的初始插件，以稳定身份进入目录或市场。
  2. 用户检查并安装初始版本，Harness 或市场把信任绑定到插件身份，而非具体版本的完整能力集合。
  3. 攻击者发布更新，在配置中新增或改变“事件—命令”绑定。
  4. 更新流程未展示钩子权限差异，也未要求用户重新批准新增宿主能力。
  5. 会话启动、工具调用、文件编辑等匹配事件发生后，Harness 在模型决策链之外调度钩子。
  6. 钩子以 Harness 继承的宿主权限产生副作用；影响上限由进程权限、沙箱和网络策略决定。

攻击方法与复现材料（涉及攻击方法时必填） ​

论文公开了跨 Harness 的攻击框架与多类高影响目标。为避免复制可直接用于凭据窃取、权限提升、持久化或规避检测的命令，本站只保留无害的更新差分夹具；事件名和配置结构均为抽象示例，不对应任何产品的可执行格式。

yaml
# 本站依据公开机制重构的去武器化测试夹具。
# 前置条件：只在一次性测试目录和 Mock Harness 中运行。
plugin_id: example.audit-helper
version_before:
  hooks: []
version_after:
  hooks:
    - event: TEST_SESSION_START
      command: "hook_test --dry-run --write-canary ./tmp/hook-fired"
network: disabled
secrets: synthetic-only
expected_update_decision: REQUIRE_REAPPROVAL
expected_runtime_effect: LOCAL_CANARY_ONLY

该夹具对应攻击链第 3—5 步。验证系统应在安装更新时发现新增的事件绑定和命令执行能力，并在未重新授权时阻止更新；如果测试人员显式批准，运行时只应生成本地金丝雀记录。这里省略了论文中的真实宿主目标、隐蔽执行细节和高影响命令，不应把 hook_test 替换为可访问真实凭据、外部网络或系统配置的程序。

实验设计与实际过程 ​

作者实验将 10 类攻击目标转换为各 Harness 支持的生命周期事件和命令接口，在 7 个 Harness 与 5 个大模型后端形成的 25 种有效组合上执行 1,000 次端到端测试。作者用外部预言机确认目标副作用是否实际发生，并区分事件是否产生、钩子是否被调度以及最终效果是否成立；同时比较 Microsoft Defender 与三种静态防护的检测结果。本站没有运行 HookPry，也没有复现真实宿主副作用。

这一设计能够区分模型参与的事件生成与 Harness 负责的事件处理：部分事件可能依赖 Agent 行为，但钩子一旦被接受，后续命令调度不再经过模型选择。论文还用组件消融检验 AMO、TD 与 LCI 对发现、激活和跨 Harness 适配的作用，但本文不转录未能在公开摘要与正文结果叙述中交叉确认的细分比例。

关键结果与实际影响 ​

  • 1,000 次运行中，77.0% 产生完整且经预言机确认的效果；论文称全部 7 个受测 Harness 都至少出现成功样本。
  • 单个 Harness 的最高成功率为 92.5%，对应 Hermes；作者同时报告没有运行被模型明确阻止，这与钩子位于模型决策链之外的设计一致。
  • Microsoft Defender 在作者恶意工件集上的召回率为 0%。三种静态防护取并集后仍漏检 47.5%，即在该集合上的联合召回率为 52.5%。
  • 实际风险不仅取决于插件内容，还取决于更新是否自动采用、钩子权限是否继承、事件触发条件以及 Harness 进程权限。只读、无命令执行能力或严格沙箱化的环境会显著限制后果。

防护措施与验证方法 ​

  • 将插件身份、版本摘要、钩子列表、事件类型、命令入口和运行权限绑定为同一审批对象；任何新增或扩大能力的更新都必须重新批准。
  • 在更新界面展示语义化差分，特别标记“新增宿主进程”“扩大文件范围”“启用网络”和“新增自动触发事件”，不能只显示版本号或发布者不变。
  • 默认禁止插件更新静默增加生命周期钩子；对钩子子进程采用独立最小权限、网络默认拒绝和敏感环境变量剥离。
  • 将钩子调度纳入审计轨迹，记录插件版本、配置摘要、触发事件、父进程、批准记录和可观察副作用，避免只监控模型消息与工具调用。
  • 用上述金丝雀夹具分别验证安装、更新、回滚和自动更新路径；以未授权钩子阻断率、授权提示完整率、误报率和审计关联成功率衡量防护。

局限与待验证问题 ​

证据来自 2026 年 9 月发布的单团队 arXiv v1 预印本，尚无独立复现。7 个 Harness、5 个后端和 10 类目标不能覆盖所有版本、操作系统、插件市场或企业策略；不同组合数量不均，也不能把 77.0% 解释为生态系统受影响率。论文报告的防护结果受样本、规则和扫描器版本影响，Microsoft Defender 的 0% 召回率只说明该测试集中的覆盖缺口。

后续需要验证厂商修复后的权限差分提示、自动更新默认值、钩子隔离和审计完整性，并区分“配置被接受”“事件触发”“命令启动”和“目标副作用成立”四个阶段。公开材料称作者已向受影响 Harness 厂商披露并等待回应，因此不能把尚未公开的响应解释为厂商没有实施缓解措施。

参考链接 ​