OWASP 最新发布：Agentic Skill 的十大安全风险

OWASP AST10：智能体技能层的十大安全风险与防护要义

在AI智能体架构中，模型负责核心推理，工具连接协议（如MCP）负责系统对接，而技能层则定义了智能体的具体行为能力。OWASP近期推出的《Agentic Skills Top 10》（AST10）项目，正是针对这一新兴的行为封装层，致力于构建一套标准化的安全评估框架。

技能远非简单的提示词模板。在OpenClaw、Claude Code、Cursor/Codex、VS Code等主流生态中，它更接近于一个“可执行的行为包”，通常集成了权限声明、依赖项、脚本、配置乃至完整的执行逻辑。正因如此，技能层也成为智能体与现实世界交互时，攻击面最为集中的环节。

https://owasp.org/www-project-agentic-skills-top-10/

需要明确的是，AST10目前仍处于OWASP的“新项目/孵化器”阶段。其官方提案页面明确标注为“New Project Proposal”，目标是在2026年完成v1.0版本，届时将完善十大风险的详细描述、通用技能格式规范及安全检查清单等配套材料。因此，它更应被视为一个快速演进中的行业共识框架，而非一个已完全固化的最终标准。

该框架的核心是十大风险项，按其潜在影响严重性划分为：

关键级（Critical）：AST01, AST02
高危级（High）：AST03, AST04, AST05, AST06
中危级（Medium）：AST07, AST08, AST09, AST10

一、十大安全风险

1. AST01：恶意技能

这是最直接且常被低估的风险：技能本身即携带恶意载荷。它伪装成正常的工具包，声称提供搜索、邮件或数据库接入功能，实则利用智能体的执行权限窃取文件、密钥或外泄敏感数据。OWASP将其定为关键风险，并将Merkle根签名和注册表扫描列为关键缓解措施。

其危险性在于，恶意意图可能隐藏在自然语言描述、执行脚本或工作流编排中。传统安全关注二进制文件和静态特征；而在技能生态中，攻击指令可能直接写在“使用说明”里。

2. AST02：供应链妥协

如果说AST01是技能“本身有毒”，那么AST02则意味着：即便一个技能初始无害，也可能在其分发链条上被污染。OWASP将风险焦点放在了注册表、市场、依赖包、发布者身份、透明日志和更新通道等环节。

这传递了一个明确信号：技能应被视为一种新型的软件供应链对象。但与传统的、被程序调用的软件包不同，技能是“驱动智能体自主执行”的单元。一旦供应链被攻破，威胁的将不是单个函数库，而是整个自动化任务链条。

3. AST03：过度授权

这条高危风险的关键，不在于“权限过多”这一笼统概念，而在于技能申请的权限边界经常与其宣称的实际任务需求严重脱钩。

一个仅需读取特定API的技能，可能申请了整个目录的读取权；一个只需访问单个域名的技能，可能拿到了开放的网络出站权限。更值得警惕的是，某些本不应触碰身份和记忆文件的技能，却获得了写入SOUL.md、MEMORY.md等关键文件的能力。Snyk在2026年2月的报告中提及的280多个泄露凭据的技能，正是这一风险的现实例证。

OWASP在通用技能格式提案中，甚至专门将deny_write列为默认保护项，并强调网络权限应是明确的允许列表（allowlist），而非一个简单的network: true开关。这揭示了一个更深层的问题：智能体世界的权限关乎其长期行为状态的改变，其复杂性远超传统RBAC中“能否访问某张表”的范畴。

4. AST04：不安全元数据

这条风险极易被忽视，却极具现实破坏力。它指向技能元数据层面的威胁：名称、描述、权限声明、风险等级等这些“说明信息”本身，就可能成为攻击者的利用工具。总表中列举的假冒“Google”技能进行品牌冒充的案例，便是典型。

其本质在于，用户安装技能时，首先接触的往往是元数据。如果元数据可以伪装、夸大或误导，攻击者实际上就已赢得了初步信任。因此，AST04的价值在于提醒平台方：安装前的信任界面本身就是一道关键的安全边界。技能代码安全只是底线，其清单文件、权限描述和风险提示也必须具备可校验、可审计、可约束的特性。

5. AST05：不安全反序列化

这条风险在技能生态中显得尤为突出。大量技能依赖YAML、JSON、Markdown等结构化或半结构化内容进行加载和配置。OWASP明确建议使用安全的加载器、禁用危险标签，并在执行前进行严格的模式校验。

它真正要提醒我们的是：风险不只发生在运行时，也潜伏在加载时。用户以为只是“安装了一个技能”，平台以为只是“读取了一份清单”，但如果解析器、加载器与执行器之间的安全边界模糊，攻击完全可能在技能正式开始工作前就已触发。

6. AST06：弱隔离

如果说AST03是权限“声明”过多，那么AST06则指向一个更根本的问题：无论权限声明写得多么严谨，技能最终仍可能与宿主运行在同一个安全上下文中。

OWASP建议默认采用容器化或Docker沙箱，将宿主模式视为需要显式选择（opt-in）的例外，并要求平台记录技能的所有文件访问、Shell命令、网络调用等行为。这背后的逻辑很清晰：不能只依赖技能的“自觉”来守边界，必须依靠强制的隔离机制来设立边界。在智能体这种长会话、持凭据、多工具联动的环境中，弱隔离的后果会被急剧放大。

7. AST07：更新漂移

虽然被归为中危，但在企业环境中，其破坏力常被低估。所谓“更新漂移”，简单说就是：你以为安装的是那个技能，但一段时间后，它可能已“面目全非”。

OWASP给出的缓解思路包括版本固定、哈希校验、不可变锁定和更新策略管理。在开发建议中更是直接指出：依赖应锁定到不可变的哈希值，而非模糊的版本范围。这一点在智能体生态中尤为关键，因为技能并非孤立运行，其更新往往牵动着关联的记忆、配置、脚本和外部API一同变化。一旦更新过程不可验证，团队将迅速失去对行为边界的控制。

8. AST08：扫描不足

这是整份框架中最具现实批判意味的一条。OWASP明确指出，关键缓解措施并非普通扫描，而是构建“语义+行为”分析的多工具流水线。单纯的模式匹配远远不够。

这恰恰点破了行业现状：许多团队仍在沿用扫描传统软件包、依赖库的思路，去应对一种融合了“代码、配置、自然语言与行为编排”的新对象。而技能最危险的部分，往往不是传统静态规则所能轻易发现的——恶意指令可能藏在描述文本中，风险可能源于一系列看似无害的动作组合。

因此，OWASP强调必须进行语义扫描和行为分析，并将扫描深度集成到发布和安装链路中，而非将其视为一份离线的安全报告。

9. AST09：缺乏治理

如果说前几条偏重技术，AST09则直指企业治理问题。OWASP的描述一针见血：组织在部署AI智能体时，缺乏资产清单、策略、审批流程和审计追踪，导致开发者自行安装技能，安全运营团队却无从知晓，最终形成一片安全团队无法看见和控制的“影子AI”。

对企业而言，真正导致严重事件的，往往不是一个恶意技能本身，而是由此引发的连锁反应：根本不知道谁安装了什么、不知道它申请了哪些权限、不知道数据流向何处，更不知道出事时该如何一键撤销和追溯影响。换言之，技能一旦进入企业，就从一个开发效率工具，转变为了一个必须严肃对待的资产治理问题。

10. AST10：跨平台复用

这是一条极具前瞻性的风险。跨平台复用通常被视为生态繁荣和开发者效率高的表现，但从安全角度看，它意味着恶意技能也能轻松迁移。

一个在A平台经过安全包装的技能，迁移到B平台后，其权限字段可能改变、风险等级标签可能丢失、签名机制可能不兼容、扫描规则也可能不同。结果是代码迁移过去了，但安全语义却断裂了。

为此，OWASP专门提出了通用技能格式（Universal Skill Format）提案，旨在用统一的YAML格式承载跨平台的安全属性。该格式纳入了如permissions.deny_write、network.allow、risk_tier、scan_status等字段，其核心目标正是确保“技能的安全属性”能随技能本身一同迁移，而非每到一个新平台就需要重新解释和定义。

二、5个核心防护动作

基于上述风险分析，可以提炼出五个关键的防护动作：

第一，将技能纳入供应链治理体系。 必须建立发布者验证、代码签名、透明日志、哈希校验、内部镜像和变更审批流程。技能不再是“小插件”，而是新的、关键的软件供应链单元。

第二，遵循最小权限原则设计。 摒弃粗粒度的“开/关”式权限模型，实现文件路径、域名白名单、Shell访问、身份文件默认拒写等细粒度控制。OWASP的通用格式提案已为此提供了具体蓝图。

第三，默认在隔离环境中运行。 安全策略应从“高风险才入沙箱”转变为“默认沙箱，宿主执行为例外”。在智能体环境中，一次越权执行的后果往往是会话级、记忆级乃至身份级的持续影响。

第四，实施持续扫描与持续审计。 安全审查不应止步于安装前。必须在发布时、安装时、更新后以及运行中进行持续扫描，并保留完整的审计日志。OWASP将扫描器集成和风险评估单独列为配套页面，正说明其将扫描视为整个安全体系的核心组成部分，而非附属工作。

第五，将技能作为正式资产进行管理。 企业必须建立技能的资产清单、安装审批流程、运行审计机制和吊销能力，并实施智能体身份治理。否则，治理的将仅仅是“模型”，而失控的“行为”会从技能层寻找到突破口，最终导致AI风险防线失守。