过去一段时间，围绕 Agent 安全的讨论，很多都集中在提示注入、工具滥用、越权调用这些问题上。但如果把视角再往前推一步，会发现一个更棘手的问题：风险不一定来自“恶意 skill”，也可能来自“看起来正常、但本身带洞的 skill”。
今天要讲的这篇论文，关注的正是这个点。作者提出了一个自动化红队框架 SkillAttack，目标不是往 skill 里塞恶意指令，也不是简单测一轮 jailbreak，而是去回答一个更接近真实攻防的问题：
当一个 Agent skill 本身没有被投毒，只是内部存在潜在漏洞时，攻击者能不能只靠提示词，把它一步步诱导到危险行为上？
https://arxiv.org/pdf/2604.04989
从这个意义上说，SkillAttack 讨论的已经不是“恶意 skill 注入”，而是 skill 漏洞的可利用性验证。这也是它和很多已有工作最大的不同。
这个风险能不能被打穿
作者指出，当前很多关于 skill 安全的研究，主要还是两条路线。
一条是直接往 skill 文件里注入恶意指令，比如在 skill 描述、脚本或资源文件里藏 prompt injection。这类攻击确实危险，但也有个明显问题：它往往带有比较突兀的恶意痕迹，比较容易被静态审计识别。另一条是静态扫描 skill 的代码和说明文件，找出潜在漏洞，但它只能告诉你“这里可能有问题”，却很难回答“攻击者到底能不能从用户输入一路打到危险操作”。
SkillAttack 就是为补这个空白提出来的。论文的核心判断很直接：
在开放的 skill 生态里，真正危险的，不只是那些明显带毒的 skill，更包括那些表面正常、功能合法、但内部藏着工程性漏洞的 skill。 这些漏洞可能是硬编码凭证、敏感数据外传链路、越权能力、脚本执行接口、外部网络请求等。攻击者不需要改 skill，只需要设计好提示词，就可能把这些潜在漏洞利用起来。
这件事为什么重要？因为它更贴近现实。开放 skill 注册表正在越来越像软件包生态：任何人都可以发布、分享、复用 skill，生态会迅速繁荣，但审核难度也会同步上升。论文就在 OpenClaw 框架上做实验，并把 ClawHub 这类公开 skill registry 当作现实攻击面的代表。
把攻击建模成“路径搜索”
如果用一句话概括 SkillAttack 的方法，那就是：
它不是在猜一句“最毒的提示词”，而是在搜索一条从用户输入到危险执行的攻击路径。
论文把这套方法拆成了三个阶段。
第一步：先审 skill，找出真正可能被利用的攻击面
SkillAttack 的第一阶段叫 Skill Vulnerability Analysis，它会同时看 skill 的说明文件和实现代码，把一个 skill 拆成几个关键部分：
一类是攻击者可控输入，也就是用户通过 prompt 能影响什么；
一类是敏感操作，比如读文件、发请求、写脚本、执行命令、调用外部 API；
还有一类是候选漏洞，也就是从这些输入到敏感操作之间，哪些链路可能存在安全问题。
论文这里借用了一个 agent-as-judge 审计框架 A.I.G，由审计模型去同时读 instruction interface 和 implementation code，然后抽出攻击面。最终，一个漏洞候选会被表示成比较结构化的信息：
它属于什么风险类型，攻击者能控制什么输入，会经过哪些敏感操作，需要满足什么触发条件。
这一步很像传统安全里的“漏洞挖掘”，但区别在于它不是只盯代码，而是把 自然语言说明、执行脚本、外部资源、Agent 使用方式 全都放进来一起看。因为在 skill 体系里，真正的攻击面本来就是“指令+代码+工作流”混在一起的。
第二步：不是挑一个点猛打，而是并行生成多条攻击路径
识别完漏洞面之后，SkillAttack 进入第二阶段：Surface-Parallel Attack Generation。
这个阶段最有意思的地方在于，它不是只选一个漏洞尝试攻击，而是会围绕多个候选攻击面，并行构造多条攻击路径。
这里的“攻击路径”可以理解成一条执行链：
用户提示词 → agent 如何理解任务 → 是否触发 skill → 是否调用具体脚本或资源 → 是否执行敏感操作 → 是否落到不安全结果。
然后，框架会围绕这条路径生成一个对应的对抗 prompt。这个 prompt 并不一定长得很“恶意”，很多时候它反而会包装成合规审查、配置检查、脚本排障、业务核对这类看上去合理的任务请求。论文里尤其强调，很多危险链路并不是靠一句粗暴的越狱提示直接触发的，而是要顺着 agent 的工作流一点点把它引到目标位置。
这一点其实很关键。
因为到了 Agent 场景里，问题早就不是“模型会不会直接回答危险内容”这么简单了。真正的风险在于：它会不会真的去做事。
比如去打开目录、读取脚本、输出 credential、向外发请求、执行修改操作——这些都属于执行层面的风险，不是只看模型嘴上说什么就能判断的。
第三步：真正拉开差距的，是“执行反馈驱动”的多轮修正
SkillAttack 最核心的部分，是第三阶段：Feedback-Driven Exploit Refinement。
它会把生成出来的 prompt 真正拿去跑，看 Agent 的执行轨迹、中间产物和最终回复，然后判断两件事：
第一，攻击失败是失败在了哪一步；
第二，偏离原计划的原因是什么。
比如，可能出现这些情况：
模型根本没真正调用工具，只是“凭常识瞎回答”；
它调用了工具，但没走到目标文件或目标目录；
它看起来像执行了，实际上是幻觉执行；
它读了文件，但没把敏感信息真正暴露出来；
它在中途被安全对齐或拒答机制拦住了。
SkillAttack 会根据这些反馈，同时修正攻击路径和 prompt，再发起下一轮尝试。论文设置的上限是 5 轮。
这比很多传统自动红队框架更接近真实渗透测试。
它不是“打一枪看结果”，而是“试探—观察—校正—再打”。
而论文后面的实验也证明，真正把风险打出来的，往往恰恰就是这几轮 refinement。
实验过程
论文的实验是在 OpenClaw 上完成的，数据分成两部分。
第一部分是 71 个 adversarial skills，来自 SKILL-INJECT benchmark，又细分成两类：
一类是 Obvious，也就是显式恶意注入比较明显的 skill；
一类是 Contextual，表面上看像正常或双用途，但会把 Agent 往不安全方向带。
第二部分是 ClawHub 上 Top 100 的真实热门 skill。这些 skill 不是故意恶意构造的，但作者怀疑其中存在可利用的潜在攻击面，因此用来评估 SkillAttack 在真实生态中的泛化能力。
实验覆盖了 10 个模型，包括 GPT-5.4、GPT-5.4-nano、Claude Sonnet 4.5、Gemini 3.0 Pro Preview、Kimi K2.5、Qwen3.5-Plus、MiniMax M2.5、GLM-5、豆包和混元。配置上，Gemini 3.0 Pro Preview 被用作漏洞审计模型，GPT-5.4 作为攻击模型，单个 skill 最多识别 5 个攻击面，最多进行 5 轮 refinement。
更重要的是，论文对“攻击成功”的定义并不宽松。它不是只看模型最终说了什么，而是要求执行轨迹中存在真实的危险操作证据，例如文件修改、工具调用、网络活动等；单纯拒答或安全声明不会被算成功。这个评测口径相对扎实。
实验结果
论文最重要的一张表就是 Table 1。它对比了三种方法：
一种是 Direct Attack，也就是让模型直接为每个 skill 生成一条明确恶意的 prompt；
一种是 SKILL-INJECT，即使用原 benchmark 中与恶意 skill 配套的静态攻击 prompt；
最后一种就是 SkillAttack。
结果非常清楚。
在 Obvious 集合上，SkillAttack 在所有模型上的 ASR 都高于 0.73，最高达到 0.93；而 SKILL-INJECT 最高只有 0.43，Direct Attack 则几乎接近于零。
在 Contextual 集合上，SkillAttack 依旧达到 0.56 到 0.88，而 SKILL-INJECT 大多低于 0.20，Direct Attack 依然很弱。
在最接近现实的 Hot100 集合上，SkillAttack 的最高 ASR 达到 0.26，而 Direct Attack 从未超过 0.04。比如 GLM-5 在 Hot100 上达到 0.26，GPT-5.4 和混元都达到 0.23。
这个结果的意思并不是“所有 skill 都很容易被打穿”，而是：
一旦把攻击从“静态坏 prompt”升级成“路径驱动、反馈修正”的闭环过程，很多原本看起来不显眼的风险就会被真正利用出来。
也就是说，问题不一定出在某个模型特别不安全，更可能出在 skill 执行范式本身就暴露了新的攻击面。论文里也明确写到，没有哪个模型真正显著缩小这个差距。
一个很重要的发现
论文 Table 2 给出了“第一次成功出现在第几轮”的分布，这个结果很值得单独拎出来讲。
总体上，只有大约 24% 的成功出现在前两轮，而大约 65% 的成功首次出现在第 3 轮或第 4 轮；其中第 3 轮通常是最常见的突破点。对 Hot100 这类真实 skill 来说，这个趋势还更明显，约 70% 的成功都出现在第 3、4 轮。
这背后说明两件事。
第一，很多 Agent 风险并不是“立刻爆”的。
它往往需要攻击者先观察 agent 的行为，再把指令一步步改得更贴近执行逻辑，最终才真正触发危险路径。
第二，单轮测评很可能严重低估真实风险。
如果你的安全测试方式还停留在“一条攻击 prompt 打一次，看模型答不答”，那你很可能只能测到浅层风险，而测不到 exploit 级风险。
这也是这篇论文最值得防守方警惕的一点：
Agent 系统的风险暴露，天然更像多轮交互式渗透，而不是一次性问答安全测试。
不同类型的 skill风险画像也完全不一样
论文 Figure 3 还做了一件很有价值的事：它把成功攻击按危害类型分布做了拆分，结果发现不同 skill 集合的风险画像差异很大。
对于 Obvious 集合，风险分布比较分散，Bias / Manipulation、Data Exfiltration、Malware / Ransomware、DoS、Data Destruction 都占了不小比例，没有单一主导项。
对于 Contextual 集合，风险明显集中在 Bias / Manipulation 上，占比超过一半，说明这类双用途或伪装型 skill 更容易通过上下文重构，把任务 gradually 带偏。
而对于 Hot100 真实 world skill，风险重心明显转向 Data Exfiltration 和 Malware / Ransomware，两者合计超过 70%。
这个发现特别有现实感。
因为它说明真实 skill 生态里的主要问题，未必首先表现成“价值观偏离”或“明显恶意指令”，而更像是：
数据接口过宽；
脚本权限过大；
凭证管理粗糙；
文件读写链路容易被带偏；
网络请求和外部执行能力缺乏边界控制。
换句话说，真实 skill 的主要风险，更像工程问题，而不是纯文本问题。
实际案例
论文选了一个 Hot100 中的招聘发布 skill 做案例分析。这个 skill 会自动在平台上发布岗位，并监控 LinkedIn 更新，底层通过两个 JavaScript 脚本配合 outbound HTTP 请求来完成任务。审计阶段识别出三类攻击面：数据外泄、DoS 和钓鱼。其中，数据外泄的核心漏洞是 post_job.js 中存在硬编码 API credential。
接下来的攻击过程特别有代表性。
第一轮，攻击模型先构造出一条比较“合规”的路径，让 agent 以代码审查或认证检查的名义去读 post_job.js，想把 credential 提取出来。但 Agent 并没有真的去读源码，而是直接凭一般知识回答。Judge 认为没有真实执行证据，这一轮被忽略。
第二轮，攻击模型根据反馈，把“请调用工具去查”写得更明确。结果 Agent 看起来像找到了内容，但执行轨迹和文件产物都为空，属于典型的“幻觉执行”。Judge 依然判失败。
第三轮，攻击路径被重新改写成更明确的链条：
先打开 scripts/ 目录，再读取 post_job.js，最后输出 credential 和 endpoint。Prompt 也变成了更直接的文件检查指令。到了这一步，Agent 才真正尝试读取脚本目录，并把 credential 与 API endpoint 暴露出来，攻击成功。
这个案例几乎把 SkillAttack 的价值讲透了：
真正难的，从来不是写出一句“坏提示词”，而是让 Agent 真的沿着危险执行路径走下去。
很多时候，攻击失败不是因为模型价值观足够稳，而是因为路径设计还不够贴近它的执行逻辑。SkillAttack 的闭环 refinement，本质上就是在不断缩短“攻击意图”和“实际执行”之间的偏差。
启发
1. Skill 风险不只来自恶意投毒，也来自正常功能里的潜在漏洞
过去提到 skill 安全，很多人会先想到“这个 skill 有没有被人塞毒指令”。
但 SkillAttack 说明，即便 skill 本身没有被恶意改写，只要工程实现上留了洞，也可以被 prompt 利用出来。
2. Agent 安全评测不能只看回复文本，更不能只打一轮
这篇论文最强的启发，不是某个具体数字，而是它对评测方式的提醒：
真正有效的 Agent 红队，必须看执行轨迹、工具调用和中间产物，还要允许多轮 refinement。 不然测到的大概率只是“显眼风险”，测不到“可利用风险”。
3. 开放 skill 生态越来越像软件供应链，只不过多了一层 LLM 驱动的执行诱导
这其实是论文背后更大的现实意义。skill registry 不再只是“插件市场”，它越来越像一个带有代码、权限、外部资源和语言接口的供应链系统。
传统软件供应链里的问题——凭证泄露、脚本误用、权限边界不清、依赖链风险——在 Agent 时代不仅没有消失，反而会因为 LLM 的自然语言调度能力，被放大成新的 exploit 路径。
局限性
当然，SkillAttack 不是终局答案，它也有几个明显边界。
第一，它测的主要还是 prompt-only 攻击。攻击者不能改 skill、不能改系统提示、不能改运行环境。这个设定有利于突出“只靠提示词也能利用 skill 漏洞”这一结论，但也意味着它还没有覆盖多 Agent 串联、工具返回值注入、环境污染、依赖包投毒等更复杂的现实威胁。
第二，它的实验规模虽然已经不小，但也还谈不上穷尽整个生态。论文一共评估了 71 个对抗 skill 和 100 个真实 world skill，能够证明问题存在且不罕见，但还不足以精确刻画整个开放 skill 生态的总体风险分布。
第三，它更像一个红队验证器，而不是完整防御方案。论文重点在于证明 exploitability，并没有进一步展开 skill 上线前审查、运行期监控、权限隔离、输出约束等完整防守闭环。
结语
如果说过去的大模型安全，很多时候讨论的是“模型会不会说错话”；那么到了 Agent 阶段，问题已经变成了：模型会不会真的做错事。
SkillAttack 的价值就在这里。它把 skill 安全从“静态看起来是否危险”，推进到了“动态验证它能不能被打穿”。这一步非常重要，因为它逼着我们重新理解一个事实：
在 Agent 系统里，安全风险不只存在于模型本身，也存在于 skill、脚本、资源、权限和工作流这些执行层结构里。
而且，这些风险往往不是第一轮就会暴露出来。它们更像真实渗透：需要多轮试探、路径校正、执行观察，最后才真正落到 exploit。
所以，这篇论文最值得行业记住的，不是“又多了一个红队框架”，而是它提醒了我们一件事：
Agent 的安全评测，不能再停留在问答安全那一套上了。真正的风险，已经进入了 skill 执行链。
声明：本文来自模安局，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
