PyCache Trap 利用 Python 缓存替换绕过七款 Agent Skill 扫描器，攻击成功率 94–100%

核心问题：智能体技能（Agent Skills）安全扫描器在准入时仅审查可见文档和源代码，而 Python 运行时可能直接加载行为不同的预编译字节码缓存（__pycache__/*.pyc），造成准入审查与实际执行脱节（Inspection–Execution Gap）。

• 场景与重要性：智能体技能将自然语言指令、脚本和可执行资源打包供智能体按需调用，第三方技能包准入安装建立在运行环境与发布者的信任边界上，准入审查决定了本地执行的安全性（第 1 节）。
• 现有方法的不足：现有扫描器主要依赖文本匹配、行为分析、静态与语义审计等手段检查文档、元数据与源码，假设准入审查的对象与运行时执行的代码完全一致；PEP 552 和时间戳检查仅验证缓存合法性，并不保证缓存编译自受检源码（第 1、2 节）。
• 核心观察与假设：作者指出，Python 导入机制在缓存头部通过检查时优先加载编译好的字节码，攻击者可将恶意逻辑藏匿于缓存，使扫描器审查并放行良性源码，而运行时执行被替换的可执行体（第 1、3.1 节）。
• 提出的解决方案：论文提出了评估该差距的攻击方法 PyCache Trap，以及在准入时追踪运行时选定工件并进行确定性可信复现的防御框架 EAV（Execution-Aware Validation）（第 1 节）。
• 威胁模型：
  • 攻击者目标：绕过技能扫描器的准入审查，使智能体在执行任务时加载并运行隐藏在字节码缓存中的目标行为（第 3.1 节）。
  • 攻击者知识：掌握提交的技能包内容与目标任务，了解 Python 导入与缓存加载机制，并通过扫描器反馈获取违规类别、严重度与源码片段（第 3.1、3.2 节）。
  • 攻击者能力：控制提交技能包内的文档、源码、脚本和捆绑缓存；无法修改扫描器、智能体模型、解释器或沙箱（第 3.1 节）。
  • 受害系统：由扫描器把关准入、运行在标准 Python 环境中并具备本地调用能力的 LLM 智能体系统（第 3.1 节）。

论文在相关工作中主要讨论了三个领域的研究，并给出了基线对比：

• 智能体技能与安全性：Anthropic（2025）规范了 Agent Skills，OpenClaw 等社区建立了分发中心；Liu et al.（2026b）针对技能仓库进行了大规模漏洞实证测量，Schmotz et al.（2026）测量了技能文件中的提示注入漏洞，Jia et al.（2026a）与 Liu et al.（2026a）研究了恶意指令优化与无载荷技能利用；Zhang et al.（2025）、Ling et al.（2026）和 Kolluri et al.（2026）评估了智能体规划与工具执行面临的非可信输入风险。作者称本文工作与这些研究互补，关注指令引导至调用后运行时选定的可执行体。
• 扫描与来源追踪：Cisco AI Defense（n.d.）结合模式匹配与行为分析，Snyk（n.d.）扫描智能体与 MCP 服务，fedrov2025（n.d.）提供权限审查，Liu et al.（2026b）与 Ying et al.（2026）进行静态与语义审计，Bhardwaj（2026）提供形式化能力验证；Jia et al.（2026b）展示了多模态隐藏指令攻击 SkillCamo 并提出了执行模拟防御 ExecScan，但作者指出 ExecScan 排除了 pycache 分析；Torres-Arias et al.（2019）提出了构建来源系统 in-toto，DAS Lab（n.d.）结合静态与动态分析检测包缓存异常；Python 官方规范与 Peterson（2017）的 PEP 552 定义了确定性 pyc 与失效规则，但作者指出其并未建立可执行代码的来源保证。
• Python 缓存投毒：Ohm et al.（2026）研究了 Python 生态中源码与编译工件分歧的缓存投毒威胁。作者称本文贡献在于展示该机制如何破坏智能体技能扫描工作流中的准入假设。
• 对比基线与基准：基线方法包括 CISCO、HSS、AUDITOR、SLOWMIST、VETTER、SKILLFORTIFY 以及 EXECSCAN；评测基准基于 SkillScanner 基准（Jia et al., 2026b）整理的 100 个清理基础技能（来自 CLAWHUB、skill0.io 与 GitHub）、200 个良性技能、100 个合法缓存测试夹具以及 MalSkillBench 子集（Guo et al., 2026）。

作者将本文工作定位为：现有扫描器默认准入时评估的表示与运行时选择的表示一致，本文通过对运行时可达工件施加基于确定性可信复现的可执行来源验证，填补了这一审查与执行差距。

整体思路上，论文形式化了可执行来源健全性，提出利用源码与缓存不匹配的攻击框架 PyCache Trap，并提出了基于类型化执行图与确定性来源闭包检验的防御框架 EAV（Execution-Aware Validation）。

问题形式化与可执行来源健全性

技能包 S 包含文档 M、源码与脚本 C 及编译缓存等工件 B。扫描器给出准入决定，在任务 u 与运行时配置 ρ 下，Eρ(S, u) 为被选中的可执行体。作者将可执行来源健全性（Executable-provenance soundness）形式化为： D(V_scan(S)) = ACCEPT ⟹ E_ρ(S, u) ∈ Recon(V_scan(S)) 该定义要求扫描器 D 准入技能包时，运行时选定的可执行体必须属于扫描器从其视图重构出的可执行体集合；当该蕴涵关系失败时即出现审查–执行差距。

PyCache Trap：缓存替换与反馈自适应改写

• 缓存隐藏构建：将测试行为编译进运行时兼容的字节码缓存（__pycache__/stub.pyc），并使其头部满足检查，而可见源码 stub.py 保持良性且与执行体脱节；采用同源码正常编译的缓存作为阴性对照。
• 任务相关调用：在现有脚本路径（100 个技能中有 13 个支持）或新插入的显式入口处建立调用。
• 自适应改写目标：固定源码缓存对 P=(s,b)、加载器头部与命令 c0，通过语言模型优化描述文案：

min_{n ∈ N, w ∈ W} J_D(S′(n, w))   s.t.   cmd(w) = c₀,   E_ρ(S′(n, w), u) = b 该式表示在保持调用命令和字节码执行体不变的前提下，最小化扫描器报告的违规严重度之和 JD。改写器轮换采用语言软化、位置平移、叙事整合与解耦四种策略，每个节点允许改写 κ=3 次，总候选迭代预算 K=5 次。附录 E 给出了改写提示词。

EAV 阶段 I 与 II：执行图构建与效应投影

• 构建类型化执行图：构建图 Gρ(S)=(N, E, τ)，节点集 N 包括指令阶段、脚本、源码模块、缓存与效应节点；边集 E 包含调用边 Einvoke、导入边 Eimport、加载边 Eload 与通道边 Echannel（经由临时文件或环境变量）。通过 AST 和加载器分析解析调用与导入，未解析的动态目标标记为待审查。
• 投影类型化效应：将散文、代码、图像与字节码映射到 7 种效应类型 K={read, write, net, exec, env, persist, agent}。证据投影结合确定性提取（显式命令、OCR 恢复命令、字节码常量与操作码）与基于源码锚定的语言模型提案；未严格锚定到源码行与操作汇的提案被舍弃。

EAV 阶段 III 与 IV：三大准则判定与上下文分类

• 三大判定准则：
  1. 可达性（Reachability）：污点在图中传播至释放或执行汇；
  2. 禁用组合（Forbidden compositions）：检查效应序列是否包含预设有害模式（如反向 shell）；
  3. 来源闭包（Provenance closure）：要求任务可达的每个缓存必须与其匹配源码在受信环境下的重编译结果匹配。规范化函数 ν 递归比较 co_code、常量类型与精确值、变量名、参数量等，排除文件名和行号表。缺少源码的孤立缓存直接判定为高危违规。
• 上下文相关分类：依据扫描器策略配置独立的主机与端口依赖获取白名单（16 个 HTTPS 源），数据发布默认需显式授权；目的审查可豁免符合声明用途的启发式告警，但无法豁免来源闭包违规；加权风险分阈值固定为 0.55。附录 E 给出了审核提示词。

实验设置

• 被测系统与模型：测试了七款基线扫描器 CISCO、HSS、AUDITOR、SLOWMIST、VETTER、SKILLFORTIFY、EXECSCAN，以及作者提出的 EAV。运行时自适应验证使用由 MiniMax-M3 驱动的 Claude Code 智能体环境。
• 数据集与规模：基于 SkillScanner 基准整理的 100 个清理基础技能（来自 CLAWHUB、skill0.io 与 GitHub）；5 个攻击家族共 500 个对抗候选样本（每个家族 100 个）；200 个良性技能（用于评估 FPR）；100 个跨 7 类兼容性测试的合法缓存夹具；异构 MalSkillBench 子集 556 个技能。
• 基线方法：攻击对比包括文本注入 SKILLJECT 与图像隐写攻击 SKILLCAMO 及其变体 Cloze、Split；工件验证对比了缓存存在性规则、头部一致性检查、纯字节码语义检测及可信复现。
• 指标定义：攻击成功率 ASR（未被扫描器标记拦截的比例）、良性误报率 FPR、分类 Precision、Recall（攻击集上为 1 - ASR）与 F1、失配真阳率 Mismatch TPR、弃权判定率 Abstain、端到端命中与执行数。
• 判定与打分方式：扫描器在记录配置下单次查询；语义识别采用固定书面评分规则，要求告警直接指出替换的缓存工件、隐藏行为或承载文件；运行时判定要求通过扫描器准入且在智能体沙箱中观测到运行时行为签名；EAV 决策阈值固定为 0.55。
• 样本量与重复次数：主攻击测试每类 100 个技能，跨扫描器迁移测试每源 50 个候选样本，改写预算为最多 5 次候选迭代（每个节点 κ=3），运行时确认每扫描器 100 个受害样本（每候选 1 次智能体试验）。

主结果

下表呈现了各扫描器在 100 个良性技能与 5 类攻击下的未拦截率/ASR（数据出自 Table 1）：

表格较宽，可左右滑动

被测扫描器	None (未拦截 %)	SKILLJECT ASR (%)	SKILLCAMO ASR (%)	SKILLCAMO-Cloze ASR (%)	PyCache Trap ASR (%)
CISCO	99	90	100	40	95
HSS	97	0	87	33	95
AUDITOR	99	0	92	39	100
SLOWMIST	99	0	78	55	100
VETTER	99	0	87	60	100
SKILLFORTIFY	97	100	100	64	96
EXECSCAN	98	0	8	31	94
EAV (ours)	99	6	11	9	0

（注：据 Table 1，未在表中展示的 SKILLCAMO-Split ASR 分别为：CISCO 54%、HSS 20%、AUDITOR 48%、SLOWMIST 42%、VETTER 43%、SKILLFORTIFY 97%、EXECSCAN 17%、EAV 10%）

• 作者对主结果的解读：PyCache Trap 在七款基线扫描器上达到 94–100% 的 ASR，包括在排除了 pycache 分析的 ExecScan 上达到 94% ASR（Table 1）。
• 语义识别为零：作者报告，七款基线扫描器在 100 个受测技能上的语义识别数均为 0，未放行的少数样本仅因封面文本或缓存存在性告警被阻断，未识别出被替换的代码体（Table 1、Section 4.2）。
• EAV 防御效果：作者称，EAV 凭借确定性来源验证将 PyCache Trap 的 ASR 降至 0%，并在文本与图像攻击上保持 6–11% 的 ASR（Table 1）。

端到端运行时确认与跨扫描器迁移

• 测了什么：在 Claude Code + MiniMax-M3 智能体环境中测试准入后的实际执行情况（Table 2），以及在 7 款基线和 EAV 之间无目标侧自适应的跨扫描器攻击迁移率（Figure 5，每源 50 个样本）。
• 结果：在最多 5 次改写迭代下，CISCO、EXECSCAN、HSS、SKILLFORTIFY 的准入率分别为 95%、94%、95%、96%，准入且执行成功率分别为 77%、76%、83%、81%（Table 2）。在跨扫描器迁移中（Figure 5），基线源样本在 CISCO 上达 94–100% ASR、EXECSCAN 上达 96–100%、SKILLFORTIFY 上达 92–94%；三款 Claude 扫描器准入全部基线源候选（100% ASR）；EAV 检出全部 350 个基线候选（0% ASR）；以 EAV 为源生成的样本在基线目标上达到 50–100% ASR（HSS 最低为 50%）。
• 作者的解读：作者称，文案自适应消除了表层告警，隐藏行为在 76–83% 的受害者中得以实际执行；基于 Claude 的扫描器对其他基线自适应生成的样本完全缺乏防护，而 EAV 提供的基于来源闭包校验能阻断跨扫描器迁移。

工件验证机制对比

• 测了什么：在 100 个存在源码的替换缓存包与 100 个合法缓存测试夹具上，对比缓存存在性规则、头部一致性、纯字节码语义、可信复现与集成 EAV 五种校验机制（Table 3）。
• 结果：头部一致性对 100 个替换缓存的检出率（Mismatch TPR）为 0.000，且在合法缓存上产生 0.140 的 FPR；缓存存在性规则虽检出全部替换（TPR 1.000），但将合法缓存全部误报（FPR 1.000）；纯字节码语义检测 TPR 为 1.000，但产生 0.170 的 FPR；可信复现与集成 EAV 对 100 个替换全部检出（TPR 1.000），在 86 个可检验源码/缓存配对上 FPR 均为 0.000（可信复现对 14 个无源码夹具弃权 Abstain=0.140，集成 EAV 按策略直接拒绝无源码缓存，总拒识率为 14%）。可信复现的中位/p95 延迟为 2.15/2.37 ms，集成 EAV 为 39.82/190.93 ms。
• 作者的解读：作者称，仅检查 PEP 552 头部一致性无法防御缓存替换；基于源码确定性重编译的可信复现能够精确识别替换，同时将来源对应正确性与要求源码的兼容性代价区分开。

综合防御效果与加载器覆盖对比

• 测了什么：在包含 5 个攻击家族（500 个候选样本）和 200 个良性技能的测试集上对比独立检测器性能（Table 4），并在命名空间包、动态导入和自定义 importlib 钩子等加载器场景下测试覆盖率（Section 4.4，各 50 个夹具）。
• 结果：Table 4 中，EAV 取得 92.8% Recall、95.9% Precision、94.3 F1 与 10.0% FPR；EXECSCAN 的 Recall 为 70.0%、FPR 37.5%；SKILLFORTIFY 的 Recall 仅为 8.6%；HSS 的 FPR 达 97.0%。在加载器覆盖测试中，50/50 夹具均执行了缓存，可信复现检出全部 50 个命名空间与 50 个动态导入替换，但对 50 个无源码自定义钩子夹具弃权。
• 作者的解读：作者称，EAV 在保持较低良性误报的同时优于现有扫描器；对于无法通过源码解析闭包的无源码自定义加载路径，EAV 遵循故障闭合（fail-closed）原则将其保留为待审项。

其他消融与分析

• 移除可达性准则：Recall 从 93.0% 降至 79.0%，FPR 从 8.5% 降至 3.5%（Table S3）。
• 移除来源闭包准则：Recall 从 93.0% 微降至 92.8%，FPR 保持 8.5%（Table S3，反映准则重叠）。
• 移除字节码检查发现：Recall 保持 93.0%，FPR 从 8.5% 降至 6.0%（Table S3，消融离线重算）。
• 缓存重构修复评估：从受检源码重新编译并替换缓存，使全部 99 个含代码包的替换字节码被消除（第 4.4 节）。
• 异构输入泛化：在 MalSkillBench 556 个技能子集上，EAV 达到 96.0% Precision、97.9% Recall、96.9% F1 与 9.6% FPR（第 4.4 节）。
• 单技能扫描开销：EAV 中位耗时 15.6 s、消耗 10,214 tokens，约为 EXECSCAN 耗时的三分之一（Table S2）。

作者指出的局限与后续方向

• 评估环境与配置范围：评估涵盖固定的技能集、扫描器配置和 Python 运行时（附录 D）。
• 自适应改写模型设定：自适应协议对应能够观察扫描器反馈的持久发布者模型，匹配部署于市场平台的威胁场景（附录 D）。
• 非受支持加载路径的保守处理：EAV 对可达性解析采取保守策略，受支持集合之外的动态导入和自定义加载器路径被保留供人工审查而非静默准入（附录 D）。
• 端点授权与出站控制协同：端点授权归部署方所有，来源级策略需要配合部署侧出站流量控制（egress controls）以强制执行重定向和 DNS 变更（附录 D）。
• 运行时确认覆盖范围：运行时确认仅覆盖了 Cisco、ExecScan、HSS 和 SkillFortify 四款扫描器（附录 D）。
• 故障闭合设计的拒识代价：EAV 采取故障闭合设计，对缺少受检源码的提供缓存拒绝准入，使准入决策在缺乏证据时保持保守并将结果限制在所评估的样本群中（附录 D）。

实验覆盖范围

• 被测基线扫描器共 7 款（CISCO、HSS、AUDITOR、SLOWMIST、VETTER、SKILLFORTIFY、EXECSCAN），攻击生成与防御测试共涉及 500 个对抗候选样本（5 个家族各 100 个）（第 4.1 节）。
• 缓存构建与运行时验证环境统一为 Python 3.11 解释器，自验证于解释器匹配的容器中（第 4.1、4.3 节）。
• 运行时端到端执行测试在 Claude Code 框架下使用 MiniMax-M3 智能体进行，仅对 4 款扫描器各测试 100 个技能，每个候选样本仅执行 1 次智能体试验（第 4.2 节、附录 A）。
• 合法缓存兼容性评估覆盖 7 个类别的 100 个夹具，其中 14 个为无源码夹具（第 4.3 节、附录 B.3）。
• 替代加载器覆盖测试了 PEP 420 命名空间包、importlib 动态导入和 sys.meta_path 自定义钩子各 50 个夹具；论文未报告多版本 Python 交叉混用及无扫描器反馈黑盒查询预算下的表现（第 4.4 节、附录 B.5）。

这篇论文研究了智能体技能（Agent Skills）安全扫描中的“审查–执行脱节”问题，并提出了对应的攻击验证与防御方案。

• 一句话定位与核心问题：论文针对智能体技能生态中安全扫描器只验证可见源码而 Python 运行时优先加载字节码缓存的机制断层，指出了准入信任无法约束实际执行体的安全隐患。
• 攻击方法要点：设计了 PyCache Trap 攻击，在技能包中保留良性源码的同时植入兼容且包含测试行为的字节码缓存，并利用扫描器反馈以每次最多 3 次、总计 5 次的预算迭代修改描述文案，在固定调用命令与缓存字节码的前提下消除表层警报。
• 防御方法要点：提出了执行感知验证系统 EAV，将技能的多模态输入解析为类型化执行图，把文本、代码与字节码映射为统一的系统效应，并通过解释器匹配的源码可信重编译与规范化比对，确定性检验运行时可达缓存的代码来源闭包。
• 关键实验结果：在 100 个清理基础技能上，PyCache Trap 对七款基线扫描器取得 94–100% 的 ASR，且所有扫描器对隐藏行为的语义识别数均为 0；在由 MiniMax-M3 驱动的 Claude Code 智能体沙箱中，76–83% 的技能在准入后成功执行隐藏行为；EAV 在 5 个攻击家族和 200 个良性技能上取得 92.8% Recall、95.9% Precision 与 10.0% FPR，检出了全部 100 个替换缓存。
• 作者的结论与启示：作者认为，审查可见源代码并不等同于验证实际执行代码的来源，将审查对象扩展至运行时选定的可执行工件是技能准入的必要条件；利用确定性重编译能够以毫秒级开销建立来源验证，而无法解析来源的工件应当遵循故障闭合原则予以拦截。