skill 是 Agent 的行为封装层，也是现实世界攻击面真正落地的一层。对 OpenClaw、Claude Code、Cursor/Codex、VS Code 这类生态来说，skill 不只是一个描述文件，它常常还绑定了权限声明、依赖、脚本、配置和执行逻辑。换句话说，skill 不是“提示词模板”，而是“可执行的行为包”。
OWASP 最近发布的 Agentic Skills Top 10（AST10），本质上就是想把这一层单独拎出来：模型负责思考，MCP 负责连接工具，而 skill 负责定义“这个 Agent 到底会怎么干活”。
https://owasp.org/www-project-agentic-skills-top-10/
需要说明的是，这个项目目前仍处在 OWASP 新项目/Incubator 阶段。官方 proposal 页面把它标成 “New Project Proposal”，目标是在 2026 年继续完善 v1.0、补全 10 个风险页面、通用 Skill 格式、清单和配套材料。所以，严格来说，它现在更像一个正在成形中的行业框架，而不是已经完全定型的最终标准。
OWASP 在总表里给出了 10 个风险项：
AST01 恶意技能
AST02 供应链妥协
AST03 过度授权
AST04 不安全元数据
AST05 不安全反序列化
AST06 弱隔离
AST07 更新漂移
AST08 扫描不足
AST09 缺乏治理
AST10 跨平台复用
其严重度上，AST01 和 AST02 是 Critical，AST03 到 AST06 是 High，AST07 到 AST10 是 Medium。
十大安全风险
AST01：恶意技能
AST01 指向的是最直接、也最容易被低估的一类风险：skill 本体就是恶意的。
它伪装成一个正常的能力包，看起来像在帮你接入搜索、邮箱、文档、浏览器、数据库，实际上却在借 Agent 的权限读文件、拿密钥、写记忆、出网外传。OWASP 在总表里把 AST01 设成 Critical，并把 Merkle root signing 和注册表扫描列为关键缓解措施。
这类风险之所以危险，不在于“skill 里有恶意代码”这么简单，而在于它常常会把恶意意图藏在自然语言描述、执行脚本和工作流编排里。过去大家防木马，更多是看二进制、看静态特征、看 IOC。今天 skill 生态里的很多恶意行为，可能就写在几行“如何使用本 skill”的说明里。
AST02：供应链妥协
如果说 AST01 是 skill 自己有毒，那 AST02 说的就是：skill 就算原本没毒，也可能在分发链上被污染。
OWASP 在 AST02 里把焦点放到注册表、市场、依赖、发布者身份、透明日志、更新通道这些环节上。它建议做发布者验证、依赖分析、注册表透明性、内部镜像、变更管理和组织级 inventory。换句话说，OWASP 已经把 skill 当成一种新的软件供应链对象来对待了。
因为 skill 和传统软件包很像，但又更危险：软件包通常是“被程序调用”，而 skill 是“驱动 Agent 自主执行”。一旦供应链被打穿，损失的不是某个库函数，而是整个任务链。
AST03：过度授权
AST03 在总表里被列为 High，关键缓解措施是最小权限 manifest 和 schema 校验。现实证据则是 2026 年 2 月 Snyk 报告中提到的 280 多个泄露凭据的 skill。
这条风险的关键不在于“权限太多”这么笼统，而在于：skill 的权限边界经常和任务边界脱钩。
一个本来只需要读某个 API 的 skill，可能顺手申请了整目录读取；
一个只需要访问单个域名的 skill，可能申请了开放网络出站；
一个本来不该碰 identity file 和记忆文件的 skill，却获得了写 SOUL.md、MEMORY.md、AGENTS.md 的能力。
OWASP 在通用 Skill 格式提案里，甚至专门把 deny_write 放进默认保护项，并强调网络权限应该是 allowlist，而不是一个简单的 network: true。
这说明 OWASP 已经意识到：Agent 世界里的权限问题，不是传统 RBAC 那种“你能不能访问某张表”而已，而是你能不能长期改变 Agent 的行为状态。
AST04：不安全元数据
这是这份框架里我觉得很容易被忽视、但特别有现实感的一条。
OWASP 把 AST04 定义成元数据层面的风险：名字、描述、权限声明、风险等级、manifest 字段这些看起来像“说明信息”的东西，本身也可能被攻击者利用。总表里给的现实案例就是假冒 “Google” skill 的品牌冒充。
这条风险的本质是：今天用户安装一个 skill，首先看到的往往不是代码，而是元数据。如果元数据可以伪装、夸大、误导，攻击者其实就已经赢了第一步。
所以 AST04 的价值在于提醒平台方：安装前的信任界面，本身就是安全边界。不是说 skill 代码没问题就够了，manifest、权限描述和风险提示也必须可校验、可审计、可约束。
AST05：不安全反序列化
这条风险放在 skill 生态里非常合理。
因为大量 skill 都依赖 YAML、JSON、Markdown、manifest、配置脚本这些结构化或半结构化内容来完成加载。OWASP 在首页和开发建议里都明确提到：要使用安全的 YAML/JSON loader，禁用危险 tag，在执行前做 schema 校验，避免把不可信配置直接交给解析器。
它真正想提醒的是：skill 的风险不只发生在运行时，也发生在加载时。
用户以为自己只是“安装了一个 skill”，平台以为自己只是“读取了一份 manifest”，但如果解析器、加载器和执行器之间边界模糊，攻击可能在 skill 还没正式开始工作前就已经触发了。
AST06：弱隔离
如果说 AST03 是权限拿多了，AST06 就是更根本的问题：哪怕权限声明写得再漂亮，skill 最后还是和宿主跑在一个安全上下文里。
OWASP 在总表里把 AST06 定成 High，建议默认容器化、默认 Docker sandbox，把 host mode 变成显式 opt-in；同时要求平台记录 skill 的文件访问、shell、网络调用和 memory 写入。
这背后的意思很明确：skill 不能只靠“自觉”来守边界，必须靠隔离来守边界。
只要 skill 还默认共享宿主的文件系统、shell、凭据和网络出口，那 manifest 再精细，也很容易在现实里被绕过。尤其在 Agent 这类长会话、持久凭据、多工具联动的环境里，弱隔离的后果会被放大得非常快。
AST07：更新漂移
AST07 被 OWASP 归为 Medium，但我觉得很多企业环境里它的破坏力被低估了。所谓 update drift，本质上就是：你以为你装的是那个 skill，过一阵子它已经不是那个 skill 了。
OWASP 给出的缓解思路是版本固定、哈希校验、不可变 pinning、更新策略和重新扫描。它在开发建议里甚至直接写了：依赖要锁定到不可变哈希，而不是版本范围。
这件事在 Agent 生态里特别危险，因为 skill 通常不是孤立运行的，它会连着记忆、配置、依赖、脚本、外部 API 一起变化。一旦更新过程不可验证，团队很快就会失去对行为边界的控制。
AST08：扫描不足
这是整份框架里最有现实批判意味的一条。
OWASP 在总表里直接说，关键缓解措施不是普通扫描，而是 “语义 + 行为”的多工具流水线；在 Skill Scanner Integration 页面里，它也明确强调：自动化扫描必须发生在发布前和安装前，单纯的 pattern matching 不够。
这其实点破了一个行业现状：很多团队还在用扫软件包、扫依赖、扫代码仓的思路，去扫一种“代码 + 配置 + 自然语言 + 行为编排”的新对象。
而 skill 最危险的部分，恰恰常常不是传统静态规则最擅长发现的那一层，意指令可能不藏在脚本里，而藏在描述里；风险不一定体现在某个 API 调用本身，而体现在“这串动作组合起来之后会发生什么”。
所以 OWASP 才会强调：要做语义扫描，要做行为分析，要把扫描接到安装链路和发布链路里，而不是把它当成一个离线安全报告。
AST09：缺乏治理
如果说前面几条偏技术，AST09 就明显是企业治理问题了。
OWASP 对 AST09 的描述很直接：组织在部署 AI Agent 时，缺少 inventory、policy、review process 和 audit trail，导致开发者自己装 skill，SOC 看不见，没有审批流，也没有撤销机制，最终形成一层安全团队无法看见和控制的 “shadow AI”。
这条风险对企业尤其重要，因为真正让组织出事的，往往不只是一个恶意 skill，而是：
你根本不知道谁装了什么；
不知道它申请了什么权限；
不知道它把哪些数据传到了哪里；
也不知道出事后该怎么一键撤销、统一下线、追溯影响范围。
换句话说，skill 一旦进入企业，就不再只是开发效率问题，而是资产治理问题。
OWASP 在 AST10 总页的“Getting Started”部分其实已经给出了组织级动作：先做 skill inventory，把它视为立即优先事项；再建立 AST09 所说的治理框架，包括审批流、审计日志和 agentic identity controls。
AST10：跨平台复用
这是这份框架里很有前瞻性的一条。
OWASP 把它列为 Medium，但单独为它提出了一个 Universal Skill Format 提案，希望用统一的 YAML 格式去承载跨平台安全属性。官方明确说，这个格式是为了缓解 AST10，同时给 AST01 到 AST09 提供共同的元数据基础。
这条风险非常容易被低估，大家通常会觉得“跨平台复用”是好事，代表生态繁荣、开发者效率高。但安全上，跨平台复用还有另一层含义：恶意 skill 也可以跨平台迁移。
一个在 A 平台上被包装好的 skill，到了 B 平台，权限字段变了，风险等级字段没了，签名机制不兼容，扫描规则也不一样。结果就是代码迁过去了，安全语义却丢了。
OWASP 的提案正是在补这个缺口，比如它把 permissions.deny_write、network.allow、risk_tier、scan_status、signature、content_hash 这些字段都拉进了通用格式里，本质上就是希望“skill 的安全属性”也能跟着 skill 一起迁移，而不是每到一个平台就重新解释一遍。
5个防护动作
第一，skill 必须纳入供应链治理。
要有发布者验证、签名、透明日志、哈希校验、内部镜像和变更审批。skill 不再是“小插件”，而是新的软件供应链单元。
第二，skill 必须按最小权限设计。
不要再用粗粒度的“开/关”权限模型，而要细到文件路径、域名 allowlist、shell 开关、身份文件默认拒写。OWASP 的通用格式提案已经把这件事写得很具体了。
第三，skill 必须默认隔离运行。
不是“高风险的才沙箱”，而是反过来：默认沙箱，宿主执行是例外。因为在 Agent 环境里，执行权一旦拿到，后果往往不是一次性，而是会话级、记忆级、身份级的持续影响。
第四，skill 必须进入持续扫描和持续审计。
不是装之前扫一次就完了，而是发布时扫、安装时扫、更新后重扫、运行中留审计。OWASP 已经把 scanner integration 和 risk assessment 单独做成了配套页面，说明它并不把扫描视为附属工作，而是整个体系的一部分。
第五，企业必须把 skill 当正式资产管理。
做 inventory、做审批、做审计、做吊销、做 agent 身份治理。否则你治理的只是“模型”，没治理“行为”，最后 AI 风险还是会从 skill 这层漏出来。
声明：本文来自模安局，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
