💡 一句话总结：SkillGuard 把每个 Agent Skill 当成「带权限的可执行制品」来治理——用清单声明它能干什么，用运行时访问控制保证它不越界，默认拒绝一切未声明的能力。一个被污染的 skill 即使骗过了 agent，也碰不到它没被授权的工具和资源。
一、Agent Skills 火了，但权限是个黑洞
2026 年，Agent Skills 成了扩展 agent 能力的主流方式。无论是 Claude Code 的 skills、各类 MCP server，还是各家 agent 平台的「技能市场」，思路都一样：把可复用的指令、脚本、工具绑定打包成一个「能力包」，让 agent 在需要时自动加载。开发者从社区下载一个 skill，agent 就立刻多了一项本领——体验确实丝滑。
但丝滑的背后藏着一个被普遍忽视的问题：这些 skill 到底有多大权限，谁在管？
SkillGuard（arXiv 2606.03024）一针见血地指出现状的漏洞：skill 能向 agent 注入指令、脚本、工具绑定和上下文依赖，而现有防御机制要么只做静态检查（加载前扫一眼内容），要么只管单次工具调用（每次调工具时审一下）。这中间留下了一个巨大的空隙——
没有人在管「一个 skill 究竟能向 agent 注入什么」和「它在运行时会造成什么实际后果」之间的关系。
类比一下就很清楚：这就像你装手机 App 时，既不看它申请了什么权限，运行时系统也不拦它访问通讯录和相册。在传统软件世界里这是不可想象的，但在 Agent Skills 生态里，这恰恰是默认状态。
二、威胁模型：一个被污染的 skill 能干什么
论文构建了针对 skill 的威胁模型，评估了两类注入攻击，给出的攻击成功率（ASR）相当扎眼：
| 攻击类型 | 攻击成功率（防护前） |
|---|---|
| 上下文注入（context injection） | 32.37% |
| 显式注入（overt injection） | 25.56% |
上下文注入指的是把恶意意图藏在 skill 的上下文依赖、示例、描述里，潜移默化地影响 agent 行为，隐蔽性高；显式注入则是更直白的恶意指令。三成左右的成功率意味着什么？意味着如果你的 agent 用了来路不明的 skill，攻击者有不小的概率能让它做出你没授权的事——读取敏感文件、调用危险工具、把数据外发。
更麻烦的是 skill 的复用性放大了风险。一次性的 prompt 注入打一发就没了，但被污染的 skill 会在每次触发该技能时反复生效，相当于一个常驻后门。
三、核心思路：把 skill 当成「带权限的可执行制品」
SkillGuard 的核心主张可以浓缩成一句话：
不要把 skill 当成无害的文本，要把它当成一个「承载权限的可执行制品」（permission-bearing executable artifact）来治理。
这个视角的转变是整篇论文的根。一旦你承认 skill 是「会执行、有副作用」的东西，传统软件安全里成熟的那套——权限声明、最小权限、默认拒绝、运行时监控——就都能搬过来用。skill 不再是个随便加载的 markdown，而是个需要被授权、被约束、被审计的执行单元。
四、双平面治理：清单 + 运行时
基于这个视角，SkillGuard 设计了双平面治理模型，把治理拆成「声明」和「执行」两个平面：
平面一：技能清单（skill manifest） 每个 skill 必须有一份清单，声明它需要的能力——能调用哪些工具、能访问哪些资源、能读写哪些路径。这相当于把「这个 skill 能干什么」从隐藏的、散落在脚本里的行为，提升成显式的、可审计的声明。
平面二：运行时访问控制（runtime access control） agent 真正执行 skill 时，SkillGuard 逐项核验它的行为是否在清单声明的范围内，默认拒绝一切未声明的能力。
围绕这两个平面，论文还配了四个关键机制：
- 默认拒绝强制（default-deny enforcement）：没声明的一律不放行，把安全的默认值定在「拒绝」而非「允许」。
- 能力推断（capability inference）：自动分析 skill 内容，推断它需要哪些权限，从而自动生成清单——解决存量 skill 没法逐个手写清单的落地难题。
- 用户授权中介（user authorization mediation）：高风险能力需要用户介入授权，把人放进决策回路。
- 行为监测（behavioral monitoring）：运行时持续观测 skill 实际行为，捕捉异常。
这套组合的精妙在于纵深：清单让风险可见，默认拒绝兜底越权，能力推断降低落地成本，用户中介处理高危操作，行为监测补上运行时的最后一道关。
五、实验数据怎么看
论文在 315 个真实世界 skill 和自建的 SkillInject 数据集上做了评估，几个关键数字：
- 权限分类覆盖率 99.76%：几乎所有需要保护的对象都被纳入了权限管控，没有大面积的盲区。
- 清单自动生成 F1 = 91.0%：能力推断相当准，存量 skill 可以先自动生成清单再人工复核，不必从零手写。
- 注入成功率显著下降：上下文注入从 32.37% 压到 23.02%，显式注入从 25.56% 压到 16.67%。
怎么解读「降到 23% 而非清零」？这正是权限框架的定位——它不负责消灭注入本身，而是限制注入得逞后的破坏半径。攻击者就算骗过了 agent，没在清单里声明的工具和资源它依然碰不到。所以 SkillGuard 是纵深防御的一层，要和输入侧的注入检测、输出侧的监测叠加，而不是单点银弹。论文自己带了行为监测，也正是承认了这一点。
六、对开发者的启示
即使不等官方实现，SkillGuard 的思想今天就能指导你怎么安全地用 skill 生态：
- 最小权限：给每个 skill / MCP server 只开它真正需要的工具和路径，别一把梭开全权限。
- 来源审查：从公共市场拿来的 skill 当成不可信代码看待，加载前确认它绑定了哪些工具、会跑什么脚本。
- 默认拒绝：把「未明确允许即拒绝」设成你 agent 系统的默认安全姿态。
- 运行时可见：开启工具调用日志和行为监测，让「某个 skill 在背后做了什么」可观测、可回溯。
结语
Agent Skills 把 agent 的能力扩展做到了极致丝滑，但 SkillGuard 提醒我们：任何能向 agent 注入指令和执行脚本的东西，都应当被当成需要授权的可执行制品，而不是无害文本。它把传统软件安全里验证过的权限治理范式，系统地搬进了 skill 生态。
随着 agent 越来越多地依赖第三方 skill 和 MCP，今天这种「装上就用、权限全开」的草莽阶段注定会过去。SkillGuard 给出的清单 + 默认拒绝 + 运行时监测的框架，很可能是 skill 生态走向成熟时绕不开的基础设施。