当安全护栏也成为一种Skill：Agent运行时防御与安全策略自进化

模安局·共研计划

本文研究论文经「模安局·共研计划」推荐，由《模安局》独立完成解读。

随着 Claude Code、OpenClaw 等 Agent 产品的发展，Skill 正在成为扩展 Agent 能力的一种重要方式。开发者可以将操作指令、脚本、工作流程和领域知识封装成 Skill，让 Agent 在需要时加载和使用，而不必每次都从头编写复杂的 Prompt。

这种机制大幅降低了 Agent 的能力扩展门槛，却也带来了一个新的安全问题：如果 Skill 本身包含恶意指令，Agent 该如何判断哪些操作是用户真正授权的，哪些只是 Skill 诱导它执行的？

传统的解决办法通常是在安装 Skill 前进行安全扫描，或者通过外部护栏模型监测 Agent 的行为。但有些风险只有在具体任务执行过程中才会显现，静态扫描未必能够识别。

2026 年 9 月，上海人工智能实验室、复旦大学、哈尔滨工业大学（威海）等机构的研究者发表了论文《Defense-as-Skill: Evolving Runtime Guard Skill for Skill-Augmented Agents》，提出了一种很有意思的防御思路：既然 Agent 可以通过 Skill 获得新的工作能力，那么能否把安全防护本身也封装成一种 Skill，让 Agent 在执行任务时主动检查自己的行为？

https://arxiv.org/abs/2609.01487

研究者将这一范式称为 Defense-as-Skill（防御即技能），并开发了一个名为 SkillSonar 的运行时安全护栏。它不需要修改 Agent 的底层框架，而是与其他 Skill 一样被加载到 Agent 中，在敏感操作执行前，根据用户的任务意图判断行为是否越界。

更有意思的是，作者还引入了蒙特卡洛树搜索（MCTS），通过真实的攻击和防御反馈，自动优化安全 Skill 中的防护规则。

在主要实验中，SkillSonar 将 GLM-5 面对已见风险类别新攻击的成功率从48.2%降低到10.4%，面对训练时未见过的风险类别，攻击成功率也从60.6%降低到11.5%。

这项研究的价值不只是提供了一个新的安全工具，更重要的是，它探索了 Agent 安全护栏的另一种存在形式：安全策略不再只是部署在 Agent 外部的检测服务，也可以成为 Agent 自身可调用、可维护、可持续优化的能力模块。

恶意 Skill 的危险，往往发生在安装之后

要理解 Defense-as-Skill，首先需要弄清楚 Skill 带来的安全风险与传统提示注入有什么不同。

传统提示注入通常发生在 Agent 读取网页、邮件或外部文档时。攻击者把恶意指令隐藏在这些内容中，试图让模型把不可信数据误认为应当执行的命令。

Skill 则是一种更加持久的攻击载体。它可能包含 Markdown 指令、工具使用说明、可执行脚本和配置文件，并且会在整个任务执行过程中持续影响 Agent 的决策。

一个恶意 Skill 不一定需要在安装时立即表现出危险行为。它完全可以正常安装、正常加载，甚至先帮助用户完成一部分工作，直到某个特定任务出现时，再诱导 Agent 执行额外的操作。

论文给出了一个很典型的例子。

用户要求 Agent 收集 CI 构建失败的相关日志，并将故障报告提交到 Issue Tracker。为了完成任务，Agent 加载了一个 Log Helper Skill，负责整理错误信息、收集日志和生成报告。

这个 Skill 表面上完全符合任务需求，但恶意版本在工作流程中增加了一个步骤：读取项目 .env 文件中的 API Key，将其写入日志，再通过正常的故障报告流程发送出去。

对于 Agent 来说，这些操作很容易被理解为整个日志收集流程的一部分。读取文件、整理日志、提交报告，本来就是用户要求完成的事情。

但问题在于，用户授权的是收集构建失败信息，而不是将 API Key 一并发送给外部系统。

危险并不一定来自某条明显的恶意命令，而可能来自一个看似合理、实际上却超出了用户授权范围的操作。

论文把这条界限称为 Task Boundary，即任务边界。

同样是读取文件，在代码分析任务中读取源代码可能完全合理，但读取无关的私有凭证就可能越界。同样是发起网络请求，将脱敏后的故障报告提交到指定系统属于正常操作，而将敏感数据发送到未经授权的地址就可能构成信息泄露。

这意味着，判断一个 Agent 行为是否安全，不能只看它调用了什么工具、执行了什么命令，还必须理解用户原本想完成什么任务，以及当前操作与这个任务之间的关系。

这也是传统 Skill 安装前扫描存在的局限。静态分析可以识别可疑代码和已知危险模式，却很难穷尽所有任务上下文。某个操作是否越权，往往只有等到 Agent 真正准备执行时才能判断。

因此，作者认为，对于能够持续加载 Skill 的 Agent，安全检查需要从安装前延伸到运行时。

Defense-as-Skill：把安全护栏装进 Agent 自己的工作流程

面对这种风险，研究者提出了一个相对轻量的解决方案：把运行时安全护栏封装成一个普通 Skill。

在传统架构中，安全能力通常由独立的审核模型、规则引擎、工具网关或平台权限机制承担。Agent 发起请求或准备执行某项操作时，外部系统负责判断是否允许继续。

SkillSonar 则采用不同的思路。它本身就是一个标准 Skill，与负责完成业务任务的 Skill 一起加载到 Agent 中。当 Agent 准备执行某个可能存在风险的操作时，先根据 SkillSonar 提供的规则检查操作是否仍然处于用户授权的任务边界内。

这套机制的核心不是简单识别某个命令是否危险，而是进行一次结合上下文的判断。

例如，Agent 准备执行 cat .env 命令。单独看这条命令，它只是读取一个文件，并不必然意味着攻击。如果用户明确要求检查环境变量配置，那么读取部分配置内容可能合理；但如果当前任务只是汇总 CI 报错日志，访问凭证文件就需要更加严格的审查。

SkillSonar 会结合用户请求、已加载的 Skill、当前执行步骤和历史操作记录进行判断，并把操作划分为四个风险等级。

具体执行时，SkillSonar 会将操作引导到三类处理结果：允许执行（Allow）、缩小范围或重新规划（Replan）、请求用户确认（Confirm）。对于明确不能执行的动作，则要求 Agent 放弃该动作，寻找替代方案。

这里的 Replan 非常重要。

假设用户要求 Agent 分析项目中的构建失败原因，而某个 Skill 建议删除整个日志目录后重新运行构建。简单的二分类护栏只能决定允许还是拒绝，但 SkillSonar 可以引导 Agent 重新规划：先读取必要日志、保留原始证据，再决定是否清理指定的临时文件。

这体现了 Agent 安全与传统文本内容安全的一个重要差异。

对于普通聊天模型，拒绝输出往往意味着一次安全干预已经完成。但对于 Agent，用户真正需要的是任务结果。如果护栏只能不断拒绝操作，就算阻止了攻击，也可能让 Agent 丧失实际使用价值。

因此，运行时防护需要尽可能在阻止危险行为的同时，让 Agent 继续完成原始任务。

SCOPE-R：重新定义 Skill 场景下的六类安全风险

为了系统评估这种运行时防护是否有效，研究者还构建了一套名为 SCOPE-R 的安全风险分类体系和评测数据集。

与一般的提示注入测试不同，SCOPE-R 关注的是恶意 Skill 如何在真实任务执行过程中影响 Agent 的行为，以及这些行为最终造成了什么后果。

作者将 Skill 引发的风险划分为六大类别，共21个子类别。

S：规格完整性（Specification Integrity）。 关注 Skill 对外声明的功能与实际行为是否一致。例如，Skill 的 Manifest 声称只负责读取日志，但内部脚本还包含上传文件的功能；或者通过工具 Schema、隐藏指令和元数据描述误导 Agent 的判断。

C：能力与权限控制（Capability Control）。 关注 Skill 是否诱导 Agent 突破最小权限原则，包括伪造用户授权、申请不必要的高权限、调用未经授权的工具，以及绕过正常审批流程。

O：操作副作用（Operational Side Effects）。 关注 Agent 对外部环境造成的持久化影响。例如，未经授权修改代码仓库、写入日历或 CRM 系统、改变 CI/CD 配置，或者通过持久化存储机制留下后续影响。

P：隐私与数据流（Privacy & Data Flow）。 关注敏感数据的访问、存储和传输过程，包括获取密钥、泄露对话上下文、偷偷缓存敏感信息，以及将数据发送到未经授权的目标。

E：执行安全（Execution Safety）。 主要涉及 Shell 命令滥用，以及在运行时动态下载和执行外部代码等行为。

R：资源与可靠性（Resource & Reliability）。 关注恶意 Skill 诱导 Agent 消耗过多 Token、无限重试、产生死锁，或者持续占用计算资源和网络带宽等问题。

这套分类值得关注的地方，在于它没有局限于恶意指令本身，而是沿着 Skill 影响 Agent 的过程，把风险从功能声明、权限使用、环境修改一直延伸到数据流、代码执行和系统可靠性。

尤其是操作副作用和资源可靠性这两个维度，很容易被传统大模型内容安全体系忽略。因为它们未必会产生明显违规的文本输出，却可能对真实业务系统造成影响。

在数据集构建方面，研究者从 PinchBench 中选择了15种基础任务，并为这些任务生成正常 Skill。随后让攻击 Agent 修改 Skill，通过隐藏指令、修改脚本或调整元数据等方式植入恶意行为，再由受害 Agent 执行原始任务，最后交给 Judge 判断攻击目标是否真正实现。

如果攻击未成功，攻击 Agent 会根据反馈继续修改 Skill。只有经过运行验证、确认攻击成功的实例才会进入最终恶意数据集。

最终，SCOPE-R 包含206个攻击成功实例和43个良性任务实例。其中95个恶意样本用于训练阶段的策略优化，52个用于同分布测试（ID），另外59个用于分布外测试（OOD）。

这里的 OOD 测试并不是简单抽取一些没有见过的攻击样本，而是将能力与权限控制（C）、隐私与数据流（P）两个完整风险类别排除在训练之外。

这样做的目的，是检验安全 Skill 究竟学会了某些具体攻击模式，还是形成了能够跨风险类型使用的安全原则，例如最小权限、明确授权、数据最小化和外发目的地控制。

让安全 Skill 自我进化：MCTS 如何优化防御规则？

如果说把安全护栏封装成 Skill 是这篇论文的架构创新，那么利用蒙特卡洛树搜索（MCTS）自动优化安全 Skill，就是它在技术方法上最值得深入研究的部分。

安全规则的编写一直存在一个矛盾：规则太宽松，容易漏掉新的攻击手法；规则太严格，又会阻止大量正常操作。

对于能够执行复杂任务的 Agent，这个矛盾更加突出。因为 Agent 的操作具有上下文依赖性，同一个工具调用在不同任务中的风险可能完全不同，很难通过一组固定规则覆盖所有情况。

研究者因此提出了 Runtime Guard-Skill Evolution，即运行时防御 Skill 进化机制。

它并不是通过强化学习重新训练一个安全模型，而是直接将安全 Skill 文件作为优化对象，通过真实任务执行反馈，逐步改进其中的规则和决策流程。

整个优化过程从一个人工设计的初始 Guard Skill 开始。

系统首先让 Agent 携带这个安全 Skill 执行一批攻击和良性任务，记录攻击是否成功、原始任务是否完成、用户确认次数和 Token 开销等指标，同时由 Judge 分析具体的失败原因。

假设某次攻击成功诱导 Agent 将 API Key 写入日志，那么反馈不仅会指出攻击成功，还会说明防御失败发生在哪个环节：是安全 Skill 根本没有触发，还是触发后没能识别风险，或者虽然识别出风险，Agent 却没有正确执行防御建议。

接下来，由一个负责策略优化的模型根据这些反馈修改安全 Skill。

例如，增加对敏感数据进入日志文件的检查规则，或者强化外部数据传输之前的授权确认要求。但修改不能只追求更严格，还需要尽可能保留已经有效的规则，避免因为修复一个问题而影响其他正常任务。

每轮优化可以产生多个不同的候选 Skill。作者使用 MCTS 组织这些候选版本，构建一棵搜索树。

树中的每个节点都是一份实际存在的安全 Skill 文件，不同分支代表不同的修改方向。系统通过 UCT 策略，在已经表现较好的候选版本与尚未充分测试的新版本之间进行选择，再使用真实运行结果评估它们的效果。

为了控制搜索成本，作者还区分了低成本评估和完整评估。前者为搜索树提供初步评分，后者在更完整的任务集合上验证候选版本，再利用详细的运行反馈继续生成新的修改方案。

经过多轮搜索，系统最终选择综合表现最好的安全 Skill。

这里还有一个很关键的设计：安全不是唯一的优化目标。

作者采用以攻击成功率为主、任务完成能力和运行开销为辅的评分机制。

简单理解，就是优先选择能够降低攻击成功率的候选版本；当多个版本的安全表现接近时，再比较哪个版本能让 Agent 完成更多正常任务、减少用户确认次数，并降低 Token 消耗。

这避免了一个极端情况：如果只优化攻击成功率，那么最简单的防御策略就是拒绝所有工具调用，虽然攻击可能无法成功，但 Agent 本身也无法正常工作。

从技术本质上看，这种方法更接近基于运行反馈的安全策略自动搜索与修订。它优化的是 Agent 可以读取和执行的规则，而不是底层模型的参数。

这也给企业安全产品提供了一种新的思路：安全策略不一定只能依靠专家手工维护，也可以通过自动化红蓝对抗、执行轨迹评估和策略回归测试，形成持续改进的闭环。

实验结果

研究者在 Claude Code 和 OpenClaw 两种 Agent 运行环境中开展了实验，并使用 GLM-5、Claude Haiku 4.5、GPT-5.4 等模型进行测试。

主要实验使用攻击成功率（ASR）衡量安全效果。ASR 越低，表示恶意 Skill 越难诱导 Agent 实现目标攻击行为。

在 GLM-5 上，论文进行了10次重复实验。没有任何防护时，ID 测试集的平均攻击成功率为48.2%，OOD 测试集为60.6%。引入 SkillSonar 后，这两个数字分别下降到10.4%和11.5%。

相比之下，仅在 System Prompt 中增加安全要求，ID 攻击成功率仍然达到41.4%，OOD 为48.9%。

实验还对比了 Claude Code 原生的 AcceptEdits 权限控制机制。

严格的 AcceptEdits 在 ID 和 OOD 测试中的攻击成功率分别为12.2%和7.3%，确实能够阻止不少危险操作。但代价是 Agent 的任务完成率明显下降。在 ID 测试中，任务完成率从无护栏时的81.1%降低到65.0%。

SkillSonar 则在实现10.4%攻击成功率的同时，将任务完成率维持在77.9%。

这组数据说明，基于任务语义的运行时防护，有机会在安全性和任务可用性之间取得更好的平衡。

但这里不能简单理解为 SkillSonar 在所有指标上都优于传统权限控制。尤其是 OOD 测试中，严格 AcceptEdits 的攻击成功率比 SkillSonar 更低，两者的任务完成率则相同，均为71.5%。

因此，论文证明的是 SkillSonar 在多种测试条件下具有较好的综合表现，而不是语义护栏可以全面替代现有权限机制。

跨模型实验也体现了这种差异。

在 GPT-5.4 上，SkillSonar 将 ID 攻击成功率从58.8%降低到1.9%，OOD 从55.9%降低到3.4%，安全改善非常明显。但 ID 任务完成率也从73.1%降低到了53.3%。

这意味着安全 Skill 的效果仍然受到基础模型行为特征的影响。同样一套规则，放在不同模型中，可能得到不同的安全性和可用性结果。

一个关键发现：安装安全 Skill，不代表它一定会生效

作者还做了一个很有价值的消融实验。

如果仅仅把 SkillSonar 安装到 Agent 环境中，却不明确要求 Agent 调用，那么 ID 和 OOD 攻击成功率仍分别达到40.0%和58.2%。

只有在明确为 SkillSonar 分配持续的安全检查职责之后，攻击成功率才会显著降低。在这组消融实验中，ID 和 OOD 分别降至10.4%和10.9%。

这背后的原因并不复杂。

普通 Skill 通常有明确的任务语义，例如处理 PDF、生成代码、分析数据。Agent 可以根据用户请求自动选择相应 Skill。

但安全 Skill 不一样。用户通常不会专门告诉 Agent“请先检查自己的行为是否安全”，因此正常的 Skill 检索机制很可能不会主动加载和使用它。

所以，安全 Skill 不能仅仅作为一个被动等待调用的能力存在，还必须有可靠的触发和执行机制。

作者在实验中采用明确的调用指令来解决这个问题，但这种机制仍然依赖 Agent 自己遵循要求，并不具备强制执行的保证。

另一个发现：相同的安全规则，封装方式也会影响效果

研究者进一步将 SkillSonar 中所有与决策有关的规则合并成一个始终加载的 System Prompt，并与原有 Skill 版本进行对比。

这是一个很重要的控制实验，因为两种方案使用相同的安全策略内容，主要区别在于规则如何组织和加载。

结果显示，展平后的 Prompt 在 ID 和 OOD 测试中的攻击成功率分别为35.3%和43.7%，而 SkillSonar 对应为10.4%和10.9%。

同时，SkillSonar 的 Token 消耗还减少了约21%。

这表明，大模型对安全规则的执行效果，不仅取决于规则写了什么，也可能受到规则组织方式、加载机制和上下文结构的明显影响。

对于越来越复杂的 Agent 系统，这个发现很有启发性。与其无限增加 System Prompt 的长度，不如考虑将安全能力组织成清晰、模块化、可以在适当时机调用的策略组件。

这项研究距离真正的 Agent 安全架构还有多远？

虽然实验效果不错，但 Defense-as-Skill 仍然存在一个非常根本的限制：安全 Skill 和不可信的业务 Skill，最终都是由同一个 Agent 模型来理解和执行的。

SkillSonar 本质上是一套策略层防御，而不是独立的强制执行机制。

它没有引入新的沙箱、内核监控器或强制访问控制系统，也没有保证敏感工具调用一定会经过独立安全服务的审批。

如果恶意 Skill 成功影响了 Agent 的决策，模型仍然可能忽略安全规则，或者虽然进行了风险识别，却没有正确执行防御建议。

论文在自适应攻击实验中也暴露了这个问题。

当攻击者能够针对最终优化完成的 SkillSonar 继续修改攻击策略时，经过三轮迭代，攻击成功率虽然从无护栏时的45.1%下降到了22.9%，但仍有相当一部分攻击能够绕过防御。

在外部评测集上，结果也没有主要实验那么理想。

例如，SkillSafetyBench 中，SkillSonar 将攻击成功率从93.3%降低到了52.9%。虽然改善明显，但超过一半的攻击仍然能够成功。

这说明，SkillSonar 在论文构造的测试环境中取得了很好的效果，却还不足以作为企业 Agent 系统唯一的安全边界。

我认为，Defense-as-Skill 更适合与现有安全基础设施结合，而不是直接取代它们。

如果将论文思路扩展到企业级 Agent 安全架构，可以形成几个互相配合的层次。

首先，在 Skill 安装和更新阶段，检查来源、依赖关系、脚本内容、权限声明和潜在的恶意行为，减少不可信 Skill 进入系统的可能性。

其次，在 Agent 任务执行过程中，引入类似 SkillSonar 的语义风险判断能力，持续检查用户授权范围、操作对象、数据流向和可能产生的副作用。

再次，在工具调用和资源访问层面，保留独立于 Agent 的强制执行机制。例如通过 Tool Gateway、文件和网络权限控制、沙箱隔离等措施，确保未授权操作不会因为模型忽略安全指令而直接执行。

最后，将运行过程中发现的攻击成功案例、误拦截情况和任务失败原因重新送回安全评测与策略优化系统，持续生成和验证新的防护规则。

在这套架构中，SkillSonar 主要负责理解任务语义与判断风险，独立安全执行层则负责落实不可突破的权限边界。

这样既能够利用大模型处理复杂上下文的能力，也可以避免把所有安全责任都交给一个可能受到恶意指令影响的模型。

当然，这部分属于基于论文研究提出的工程延伸，并不是作者已经实现的完整产品架构。

从静态安全规则，到可持续进化的 Agent 安全能力

回过头看，这篇论文实际上讨论了两个相互关联的问题。

第一个问题是，Agent 的安全判断应该发生在哪里？

传统内容安全主要检查用户输入和模型输出，而随着 Agent 开始操作文件、调用工具、访问外部系统，真正的风险越来越多地发生在任务执行过程中。

一条命令本身可能完全合法，却未必符合用户当前任务的授权范围。因此，未来的 Agent 护栏需要从识别危险内容，进一步发展到理解任务意图、操作权限、执行状态和行为后果。

第二个问题是，安全策略能否像其他软件能力一样持续进化？

过去的安全规则通常依靠人工维护，或者通过训练新的检测模型进行更新。SkillSonar 则提供了另一种可能：让安全策略本身成为可编辑、可测试、可回归验证的软件资产，通过自动化红蓝对抗和真实运行反馈不断改进。

这种机制不一定需要重新训练底层模型，却有机会缩短安全策略从发现问题到完成修复的周期。

不过，自动进化并不等于自动可信。策略搜索可能产生过拟合，也可能在修复某种攻击时引入新的误拦截。因此，真实部署中仍然需要独立评测集、回归测试、版本管理和必要的人工审批。

从更长远的角度看，我认为 Defense-as-Skill 代表了 Agent 安全研究中一个值得关注的方向：安全能力正在从外围的检测组件，逐渐进入 Agent 的任务规划、执行决策和能力管理体系。

但安全能力进入 Agent 内部，并不意味着外部安全边界就不再重要。

恰恰相反，当 Agent 能够执行的操作越来越多、影响的系统越来越广时，我们需要同时回答两个问题：Agent 是否理解自己应该做什么，以及系统能否确保它不会执行不该做的事情。

SkillSonar 在前一个问题上迈出了有价值的一步，后一个问题仍然需要独立、可信的执行机制来解决。

或许，这也是未来 Agent 安全架构的一条重要演进路径：让 Agent 拥有更好的安全判断能力，同时让真正的权限边界不再依赖 Agent 自己的自觉。

声明：本文来自模安局，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。