大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



文章总结： OWASP发布AgenticSkills十大安全风险框架，将skill定义为AIAgent的可执行行为包而非简单提示词模板。框架识别10个关键风险，包括恶意技能、供应链妥协、过度授权等，并按严重程度分级。核心建议包括将skill纳入供应链治理、实施最小权限原则、默认隔离运行、持续扫描审计以及企业级资产管理。该项目目前处于孵化阶段，旨在为跨平台skill安全提供统一标准。 综合评分： 87 文章分类： AI安全,应用安全,供应链安全,安全建设,漏洞分析

---

数据安全矩阵

2026年4月11日 23:21 上海

在小说阅读器读本章

去阅读

以下文章来源于模安局 ，作者面向未来AI治理的

模安局 .

面向未来的AI治理

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 指向的是最直接、也最容易被低估的一类风险：skill 本体就是恶意的。

它伪装成一个正常的能力包，看起来像在帮你接入搜索、邮箱、文档、浏览器、数据库，实际上却在借 Agent 的权限读文件、拿密钥、写记忆、出网外传。OWASP 在总表里把 AST01 设成 Critical，并把 Merkle root signing 和注册表扫描列为关键缓解措施。

这类风险之所以危险，不在于“skill 里有恶意代码”这么简单，而在于它常常会把恶意意图藏在自然语言描述、执行脚本和工作流编排里。过去大家防木马，更多是看二进制、看静态特征、看 IOC。今天 skill 生态里的很多恶意行为，可能就写在几行“如何使用本 skill”的说明里。

如果说 AST01 是 skill 自己有毒，那 AST02 说的就是：skill 就算原本没毒，也可能在分发链上被污染。

OWASP 在 AST02 里把焦点放到注册表、市场、依赖、发布者身份、透明日志、更新通道这些环节上。它建议做发布者验证、依赖分析、注册表透明性、内部镜像、变更管理和组织级 inventory。换句话说，OWASP 已经把 skill 当成一种新的软件供应链对象来对待了。

因为 skill 和传统软件包很像，但又更危险：软件包通常是“被程序调用”，而 skill 是“驱动 Agent 自主执行”。一旦供应链被打穿，损失的不是某个库函数，而是整个任务链。

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 的行为状态。

这是这份框架里我觉得很容易被忽视、但特别有现实感的一条。

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 还没正式开始工作前就已经触发了。

如果说 AST03 是权限拿多了，AST06 就是更根本的问题：哪怕权限声明写得再漂亮，skill 最后还是和宿主跑在一个安全上下文里。

OWASP 在总表里把 AST06 定成 High，建议默认容器化、默认 Docker sandbox，把 host mode 变成显式 opt-in；同时要求平台记录 skill 的文件访问、shell、网络调用和 memory 写入。

这背后的意思很明确：skill 不能只靠“自觉”来守边界，必须靠隔离来守边界。

只要 skill 还默认共享宿主的文件系统、shell、凭据和网络出口，那 manifest 再精细，也很容易在现实里被绕过。尤其在 Agent 这类长会话、持久凭据、多工具联动的环境里，弱隔离的后果会被放大得非常快。

AST07 被 OWASP 归为 Medium，但我觉得很多企业环境里它的破坏力被低估了。所谓 update drift，本质上就是：你以为你装的是那个 skill，过一阵子它已经不是那个 skill 了。

OWASP 给出的缓解思路是版本固定、哈希校验、不可变 pinning、更新策略和重新扫描。它在开发建议里甚至直接写了：依赖要锁定到不可变哈希，而不是版本范围。

这件事在 Agent 生态里特别危险，因为 skill 通常不是孤立运行的，它会连着记忆、配置、依赖、脚本、外部 API 一起变化。一旦更新过程不可验证，团队很快就会失去对行为边界的控制。

这是整份框架里最有现实批判意味的一条。

OWASP 在总表里直接说，关键缓解措施不是普通扫描，而是 “语义 + 行为”的多工具流水线；在 Skill Scanner Integration 页面里，它也明确强调：自动化扫描必须发生在发布前和安装前，单纯的 pattern matching 不够。

这其实点破了一个行业现状：很多团队还在用扫软件包、扫依赖、扫代码仓的思路，去扫一种“代码 + 配置 + 自然语言 + 行为编排”的新对象。

而 skill 最危险的部分，恰恰常常不是传统静态规则最擅长发现的那一层，意指令可能不藏在脚本里，而藏在描述里；风险不一定体现在某个 API 调用本身，而体现在“这串动作组合起来之后会发生什么”。

所以 OWASP 才会强调：要做语义扫描，要做行为分析，要把扫描接到安装链路和发布链路里，而不是把它当成一个离线安全报告。

如果说前面几条偏技术，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。

这是这份框架里很有前瞻性的一条。

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 这层漏出来。

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：数据安全矩阵 《OWASP最新发布：Agentic Skill 的十大安全风险》