AI Security

外观

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

Agent Skill 声明—实现行为完整性核验研究 ​

摘要 ​

Palo Alto Networks 提出的行为完整性核验（Behavioral Integrity Verification，BIV）把 Skill 的公开说明、代码和自然语言指令映射到同一组能力类型，比较"声明行为"与"实际行为"。在 49,943 个 OpenClaw Skill 的静态测量中，作者报告 80.0% 存在至少一项差异；在 906 个恶意 Skill 样本上，BIV 的 F1 为 0.946，精确率为 0.917、召回率为 0.978。

研究的关键价值不在于把所有差异直接判定为恶意，而在于把安装前审查从“描述是否看起来安全”变成可追溯的能力差分：未声明网络、敏感文件读取、凭据传输、命令执行或指令劫持都应成为复核证据。静态分析不能看到动态分发、反射和无制品的运行时行为，因此上述比例是作者方法覆盖范围内的测量，而非生态系统的真实恶意率。

核心创新与差异 ​

原研究贡献是定义跨代码、元数据和自然语言指令的 29 项能力分类，并用同一结构化输出支撑偏差聚类、根因判别和恶意制品检测。本站分析认为这与SkillGate的“识别恶意文本”形成互补：BIV 首先要求声明、实现和指令在能力层相互一致，因而可审计未声明权限与复合数据流，而不是只给出内容级风险分数。

威胁模型与攻击链 ​

提交方可以控制待安装 Skill 的元数据、说明、Markdown 指令和代码；审核方信任分析流水线但不信任制品。最先失效的控制是发布/安装审查没有把公开声明与实际能力绑定。

  1. Skill 对用户声明低权限或普通功能。
  2. 代码或指令中出现未声明的敏感读取、网络发送、下载执行或身份劫持行为。
  3. 若审核只阅读描述或单独扫描代码，跨文件、跨模态的能力差异不会形成审批信号。
  4. Skill 被安装后，Agent 可在既有权限下执行这些未被明确授权的行为。

攻击工件与复现材料 ​

下例是本站依据论文能力分类制作的最小审计夹具，不包含真实凭据、外传或命令执行；它展示检测系统应输出的“声明与实现不一致”证据。

yaml
# 本站去武器化夹具；预期结果：BLOCKED，供安装前审核测试。
declared_capabilities: [read-project]
observed_capabilities:
  - read-project
  - outbound-http        # 未声明，目标仅为 https://example.invalid/
  - instruction-override # 未声明，且不执行任何指令
expected_decision: BLOCKED_UNDECLARED_CAPABILITY

该夹具对应上文第 2–3 步。实际实现应保留文件与行号、声明片段和能力提取依据，供维护者判断是文档遗漏、误报还是恶意意图。

实验设计与实际过程 ​

作者实验先抓取 OpenClaw Registry 的 49,952 个 Skill，9 个预处理失败后分析 49,943 个。BIV 用确定性代码分析与 LLM 辅助的说明/指令提取构造能力差异和数据流证据；恶意检测以 404 个恶意、502 个良性样本组成的 906-Skill 基准评测，并比较规则基线和 LLM-only 基线。本站没有复现 Registry 抓取、分类或检测结果。

关键结果与实际影响 ​

作者从 49,943 个 Skill 中提取 250,706 个行为差异，称 81.1% 为开发者疏漏、18.9% 为对抗意图，并报告 5.0% Skill 带有预测的多阶段攻击链。BIV 在 906-Skill 基准的 F1 为 0.946，相比 LLM-only 的 0.927 增加 0.019；其假阳性率为 7.2%（502 个良性样本中的 36 个）。差异不等于恶意，尤其是权限说明不完整、跨语言静态分析不全时，生产部署必须有人审和申诉路径。

SkillSpec 从另一条路线把 Skill 正确性建模为 Hoare 风格的规格推理：先将说明、指令和代码统一为图，再从声明意图推导 ExpectSpec、从实际行为推导 FactSpec，并用意图掩码控制全局、谱系、邻域和局部上下文，最后在隔离沙箱验证候选缺陷。作者在 SkillsBench 与高下载量仓库的 515 个真实 Skill 上确认 239 个 Skill 中共有 763 个缺陷，候选精确率为 61.2%；代码节点上的规格推理较稳定，纯文本节点仍是主要瓶颈。该指标衡量候选缺陷中人工确认的比例，不是召回率或生态恶意率，且只适用于所测仓库、意图视图、模型家族和沙箱验证规则。它补充 BIV 的能力差分：前者检查期望规格与事实规格是否一致，后者更侧重声明能力与实现行为的映射，两者都需要人工复核语义歧义。

防护措施与验证方法 ​

  • 将元数据声明、Markdown 指令和代码调用都归一到稳定的能力词表，并保存文件、行号和数据流证据。
  • 在安装/更新时阻止未声明的高风险能力；正常的声明变更同样应触发再次审批。
  • 对“读取敏感数据 → 编码/变换 → 外发”“下载 → 写入 → 执行”等组合链做单独审计，避免只看单个 API。
  • 用标注良性/恶意制品、跨语言样本和动态分发样本分别评估精确率、召回率、误报与漏报。

局限与待验证问题 ​

论文的 JavaScript/TypeScript 与 Shell 分析主要是文件内模式匹配，动态分发、反射、混淆及跨文件数据流可能漏检，29 项分类之外的能力也不在结论范围内。根因和意图分类依赖作者设置的 LLM 与标签体系，尚待独立复现；论文承诺发布制品清单与结果，但不能据此假定所有 Registry 条目已经完成人工安全审计。

参考链接 ​