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

OWASP AST10：智能体技能层十大安全风险深度解析与防护实践

在AI智能体的整体架构中，模型层负责核心的“思考”与推理，工具连接协议（如MCP）负责“连接”外部资源，而真正定义“智能体具体能执行哪些任务”的，则是技能层。OWASP最新推出的《Agentic Skills Top 10》（AST10）项目，正是将安全焦点对准了这一新兴的行为封装层，致力于为其建立一套系统性的安全评估与防护框架。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

技能，远不止是一个简单的提示词模板。在OpenClaw、Claude Code、Cursor/Codex、VS Code等主流AI开发环境中，它更接近于一个“可执行的行为包”，通常捆绑了权限声明、外部依赖、执行脚本、配置文件乃至完整的工作流逻辑。正因技能层直接驱动智能体与现实世界交互，它也成为攻击面最终落地、安全风险最为集中的关键环节。

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将风险焦点明确放在了公共注册表、技能市场、第三方依赖包、发布者身份伪造、透明日志缺失和不安全的更新通道等环节。

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

3. AST03：权限过度授予

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

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

OWASP在通用技能格式提案中，甚至专门将deny_write（默认拒写）列为关键保护项，并强调网络权限应是明确的域名或IP白名单（allowlist），而非一个简单的、粗粒度的network: true开关。这揭示了一个更深层的问题：在智能体世界中，权限关乎其长期行为状态和记忆的持久性改变，其复杂性和影响范围远超传统RBAC（基于角色的访问控制）中“能否访问某张数据库表”的范畴。

4. AST04：元数据欺诈与误导

这条风险极易被忽视，却极具现实危害性。它指向技能元数据层面的安全威胁：技能的展示名称、功能描述、所需权限声明、自我声明的风险等级等这些“说明性信息”本身，就可能成为攻击者进行社会工程学攻击或信任欺诈的工具。报告中列举的假冒“Google官方”技能进行品牌冒充的案例，便是典型。

其本质在于，用户或管理员在评估和安装技能时，首先接触并依赖的往往是这些元数据。如果元数据可以被轻易伪装、夸大或误导，攻击者实际上就已赢得了初始的信任。因此，AST04的价值在于提醒平台方和安全团队：安装前的信任界面与信息展示本身就是一道至关重要的安全边界。技能代码层面的安全只是技术底线，其清单文件、权限描述和风险提示也必须具备可校验、可审计、不可篡改的特性。

5. AST05：不安全的反序列化漏洞

这条风险在技能生态中显得尤为突出且合理。大量技能依赖YAML、JSON、Markdown等结构化或半结构化配置文件进行加载和初始化。OWASP明确建议必须使用经过安全加固的解析加载器、禁用危险的内置标签或函数，并在执行前进行严格的数据模式（Schema）校验。

它真正要提醒我们的是：安全风险不只发生在代码运行时，也潜伏在配置加载和解析时。用户可能以为只是“安装并读取了一份配置清单”，平台可能以为只是“解析了一份YAML文件”，但如果解析器、加载器与最终执行器之间的安全边界模糊，攻击完全可能在技能正式开始工作前就已触发，例如通过构造恶意的YAML内容实现远程代码执行。

6. AST06：运行时隔离机制薄弱

如果说AST03是权限“声明”过多，那么AST06则指向一个更根本的运行时安全问题：无论权限声明写得多么严谨，技能最终仍可能与宿主智能体运行在同一个操作系统进程或安全上下文中，缺乏强制的隔离。

OWASP建议默认采用容器化（如Docker）或轻量级沙箱技术来运行技能，而将“与宿主共享环境”的模式视为需要管理员显式选择（opt-in）的高风险例外。同时，要求平台记录技能运行期间所有的文件访问、Shell命令执行、网络调用等行为日志。这背后的逻辑非常清晰：不能仅仅依赖技能自身的“自觉”和声明来守卫边界，必须依靠操作系统或容器级别的强制隔离机制来设立不可逾越的边界。在智能体这种具有长会话、持久化凭据、多工具联动特性的环境中，弱隔离导致的后果会被急剧放大。

7. AST07：不可控的更新漂移

虽然被归为中危，但在长期运行的企业生产环境中，其破坏力和隐蔽性常被低估。所谓“更新漂移”，简单说就是：你以为安装并使用的是某个特定版本的技能，但经过一段时间或几次自动更新后，它的代码和行为可能已“面目全非”，而你却失去了对变更内容的掌控。

OWASP给出的缓解思路包括版本固定（Pin Version）、内容哈希校验、发布后不可变锁定以及严格的更新策略管理。在开发建议中更是直接指出：技能的依赖应锁定到不可变的哈希值，而非模糊的版本范围（如“^1.2.3”）。这一点在智能体生态中尤为关键，因为技能并非孤立运行，其更新往往牵动着关联的记忆、用户配置、外部API调用契约一同变化。一旦更新过程不可追溯、不可验证，团队将迅速失去对智能体行为边界的控制。

8. AST08：安全扫描深度与广度不足

这是整份框架中最具现实批判意味的一条。OWASP明确指出，关键的缓解措施并非传统的普通代码扫描，而是构建融合“语义分析+行为模拟”的多工具、多层次安全检测流水线。单纯的静态模式匹配或正则表达式规则远远不够。

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

因此，OWASP强调必须进行深度的语义理解扫描和动态行为分析，并将深度扫描能力深度集成到技能的发布、安装和更新链路中，实现“左移”安全，而非将其视为一份事后的、离线的安全合规报告。

9. AST09：企业级治理框架缺失

如果说前几条更偏重技术实现风险，AST09则直指企业组织与流程层面的治理问题。OWASP的描述一针见血：许多组织在部署AI智能体时，缺乏统一的技能资产清单、明确的安装与使用策略、规范的审批流程和完整的审计追踪。这导致开发者可以自行从外部市场安装技能，而安全与运营团队却无从知晓，最终在企业内部形成一片安全团队无法看见、无法控制、无法审计的“影子AI”。

对企业而言，真正导致严重安全事件的，往往不是一个孤立的恶意技能本身，而是由此引发的管理失控和连锁反应：根本不知道哪个部门安装了什么技能、不知道它申请并使用了哪些敏感权限、不知道业务数据流向了何处，更不知道在出事时该如何一键全局撤销和追溯影响。换言之，技能一旦进入企业环境，就从一个个开发效率工具，转变为了必须被严肃对待的、与企业核心资产和数据安全紧密相关的治理问题。

10. AST10：跨平台迁移导致的安全语义断裂

这是一条极具前瞻性的风险。技能的跨平台复用通常被视为生态繁荣和开发者体验良好的表现，但从安全运营角度看，它意味着恶意技能也能获得“一次开发，多平台危害”的便利。

一个在A平台经过严格安全包装和审核的技能，迁移到B平台后，其权限字段的语义可能改变、风险等级标签可能丢失、代码签名机制可能不兼容、平台方的扫描规则和策略也可能完全不同。结果是，技能的代码和功能被完整迁移过去了，但其附带的“安全属性”和“信任上下文”却发生了断裂。

为此，OWASP专门提出了通用技能格式（Universal Skill Format, USF）提案，旨在用一套统一的YAML格式标准来承载跨平台的安全属性。该格式草案纳入了诸如permissions.deny_write、network.allow（白名单）、risk_tier（风险等级）、scan_status（扫描状态）等关键字段。其核心目标正是确保“技能的安全语义与策略”能随技能代码本身一同无损迁移，而非每到一个新的平台或运行时环境，就需要安全团队重新进行人工解释、评估和配置。

二、五大核心防护动作与最佳实践

基于对上述十大风险的深入分析，我们可以为AI智能体的安全防护提炼出五个关键且可落地的动作：

第一，将技能纳入软件供应链安全治理体系。 必须建立覆盖技能全生命周期的供应链安全管控，包括发布者身份验证、强制代码签名、构建透明日志、内容哈希校验、建立内部可信镜像仓库以及严格的变更审批流程。必须从根本上认识到，技能是一种新的、关键的软件供应链单元，其安全性与传统软件依赖同等重要。

第二，遵循最小权限原则进行精细化权限设计。 彻底摒弃粗粒度的“全有或全无”式权限开关模型。应实现基于文件路径、具体域名白名单、受限的Shell访问、对身份/记忆文件的默认拒写（deny_write）等细粒度权限控制模型。OWASP的通用技能格式（USF）提案已为此提供了具体的技术蓝图和字段定义参考。

第三，默认在强隔离环境中运行技能。 安全策略应从“仅对高风险技能入沙箱”转变为“默认所有技能在沙箱/容器中运行，与宿主共享环境需特殊审批”。在智能体这种具有状态持久化能力的场景中，一次成功的越权执行或数据泄露，其后果往往是会话级、记忆级乃至身份级的持续性影响，隔离是最后也是最坚固的防线。

第四，实施持续、深度、集成的安全扫描与审计。 安全审查不应止步于安装前的一次性检查。必须建立覆盖技能发布时、安装时、更新后以及运行中的持续扫描机制，并保留完整的、不可篡改的审计日志。OWASP将扫描器集成和风险评估单独列为配套页面，正说明其将深度扫描视为整个智能体安全体系的核心组成部分，而非附属的、可选的工作。

第五，将技能作为正式IT资产进行全生命周期管理。 企业必须建立中心化的技能资产清单、定义明确的安装与使用审批流程、实施运行时的行为审计机制、并具备快速的全局吊销能力。同时，需要将智能体身份治理纳入整体身份与访问管理（IAM）体系。否则，企业治理的将仅仅是“模型”本身，而失控的“行为”会从技能层寻找到突破口，最终导致整个AI应用的安全防线失守。