OWASP Agentic Skills Top 10 红队实战解析：从Skill注入到系统级失控
OWASP Agentic Skills Top 10 红队实战解析：从Skill注入到系统级失控
Al1ex
发布于 2026-05-19 18:54:13
发布于 2026-05-19 18:54:13
文章前言
随着AI Agent、智能工作流以及具备自主执行能力的大语言模型系统快速发展，AI的安全边界正在从"模型推理"进一步扩展到"行为执行"。相比传统LLM应用，Agent系统已经不再只是"生成文本"，而是开始具备任务规划、工具调用、文件操作、Shell执行、跨系统协同以及长期记忆等能力。这意味着Agent技能(Skill)如果被恶意利用、污染或劫持，其影响范围将直接从"错误回答"升级为真实世界中的自动化攻击、权限滥用与供应链失控。OWASP在最新发布的 《OWASP Agentic Skills Top 10》中将安全关注点正式聚焦到了Agent的"行为层(Behavior Layer)"，强调Skills已成为连接模型、工具与执行系统之间最危险、也最容易被忽视的攻击面，本文将基于OWASP官方《OWASP Agentic Skills Top 10》项目，对Agentic AI Skill生态中的十大核心风险进行深入剖析，从攻击原理、真实案例、供应链风险、权限边界、Skill执行链路到企业级防御架构进行系统讲解并帮助读者全面理解AI Agent在"自主执行时代"下面临的新型攻击面并建立面向未来Agent系统的安全设计与治理思维
风险类型
AST01:恶意技能
风险介绍
Malicious Skills(恶意技能)是指攻击者通过构造、篡改或伪装AI Agent的Skill(技能/工具能力模块)，使得Agent在执行任务过程中触发恶意行为的一类安全风险。在Agentic AI系统中Skill通常负责定义Agent如何调用工具、访问资源、执行工作流以及与外部系统交互，因此一旦恶意Skill被加载或信任，攻击者就可能借助Agent获得文件访问、Shell执行、API调用、数据读取甚至系统控制能力。例如：攻击者可以在第三方Skill仓库中植入带有隐藏后门的Skill或伪装成正常自动化插件诱导开发者安装，Agent调用该Skill时便可能自动泄露敏感数据、执行危险命令或向外部服务器发送信息。OWASP将其视为Agent时代最核心的供应链风险之一，因为Skill 本质上已经成为"AI的可执行能力模块"，Skill一旦被恶意控制就等同于攻击者获得了Agent的行为控制权
风险场景
Malicious Skills(恶意技能)攻击场景包括：
- SkillHub投毒攻击：攻击者向第三方Skill市场、GitHub仓库、MCP Marketplace或Agent插件中心上传带后门的Skill，利用企业对官方仓库或热门项目的信任实现供应链攻击，Agent自动安装或自动更新这些Skill时，恶意逻辑便会进入企业环境
- 恶意自动化插件类：攻击者将恶意Skill伪装成办公助手、DevOps工具、日志分析插件或自动化工作流组件，诱导开发者或企业Agent安装使用。表面上Skill能够正常完成任务，但内部会偷偷读取文件、窃取API Key、记录聊天内容或向外部服务器发送敏感数据，属于最常见的"伪装型恶意Skill攻击"
- Tool调用劫持攻击：恶意Skill在执行过程中篡改工具调用逻辑，例如：修改API参数、扩展查询范围、注入额外请求或伪造函数返回值，从而让Agent执行超出原始任务范围的危险操作，例如：读取整个目录、批量导出数据库或越权访问资源
- 隐藏式数据外传类：恶意Skill在后台静默收集并外传敏感数据，例如：聊天记录、Embedding内容、数据库信息、Token、配置文件或企业文档。由于Skill对外表现为"正常工作"，因此这类攻击往往隐蔽性极强，难以及时发现
- Shell与系统控制类：高权限Skill拥有Shell执行、Docker控制、Kubernetes操作或系统配置修改能力，Skill一旦被恶意利用，攻击者便可能借助Agent执行命令、植入后门、横向移动或控制服务器，从而将Agent变成真实的攻击入口
防御措施
- 数字签名校验类：企业针对每个Skill进行签名验证，确保代码未被篡改且来源可信
- Skill白名单机制：企业仅允许经过企业认证和安全审核的Skill运行，禁止动态加载未知或未授权插件
- 供应链安全管控：企业建立自己的SKILLHUB、第三方插件市场并对上线发布的SKILL进行安全审计，建立完备的安装来源验证、发布审计管理机制，防止恶意SKILL投毒、版本篡改和恶意更新风险
┌──────────────────────────────────────────────────────────────┐
│ 🧑 AI Agent应用层 │
│ - Agent / Workflow / Multi-Agent System │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 🔐 Skill / Tool入口控制层（Gateway） │
│ - Skill白名单机制（Whitelist Only） │
│ - 数字签名校验（Signature Verification） │
│ - 来源可信验证（Trusted Registry） │
│ - 版本锁定（Version Pinning） │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 🔍 供应链安全扫描层（Supply Chain Scanner） │
│ - 依赖包扫描（SCA: Software Composition Analysis） │
│ - 恶意代码检测（Backdoor / Trojan Detection） │
│ - Skill行为分析（Behavior Profiling） │
│ - 模型/数据投毒检测（Data & Model Validation） │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ ⚙️ CI/CD & 更新控制层（Release Guard） │
│ - 更新审批流程（Manual Approval Gate） │
│ - 版本可回滚机制（Rollback Safety） │
│ - 发布链路审计（Release Provenance Tracking） │
│ - 制品签名验证（Artifact Signing） │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 🧱 运行时隔离层（Runtime Sandbox） │
│ - Skill容器隔离（Container / VM Sandbox） │
│ - 文件系统隔离（FS Isolation） │
│ - 网络访问控制（Egress Filtering） │
│ - 系统调用限制（Syscall Restriction） │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 🧠 Agent行为控制层（Policy Engine） │
│ - Tool调用策略控制（Tool Policy Enforcement） │
│ - 最小权限访问（Least Privilege Access） │
│ - Prompt Injection联动检测 │
│ - 异常行为识别（Behavior Anomaly Detection） │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 🔒 数据与密钥安全层（Data Security Layer） │
│ - Secrets Vault（API Key / Token管理） │
│ - 数据最小化访问（Data Minimization） │
│ - 敏感数据脱敏（Data Masking） │
│ - 加密存储与传输（Encryption at Rest / Transit） │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 📊 监控审计与响应层（Observability） │
│ - Skill执行日志审计（Full Trace Logging） │
│ - 数据外传检测（Exfiltration Detection） │
│ - 异常调用告警（Anomaly Alerting） │
│ - 自动隔离与Kill Switch │
└──────────────────────────────────────────────────────────────┘AST03:过度授权风险
风险介绍
Over-Privileged Skills(过度授权的技能)是指AI Agent中Skill在设计或部署过程中被赋予了超出其实际功能需求的权限，从而在被误用、被攻击或被恶意触发时可能对系统造成更大范围影响的一类安全风险。在Agentic AI架构中Skill通常用于执行特定任务，例如：文件读取、API调用、数据库查询或系统操作，但是当这些Skill被默认授予"全量访问权限"或"管理员级权限"时，遭遇到Prompt Injection、Malicious Skills或供应链攻击就可能被滥用执行敏感操作，例如：批量导出数据、修改系统配置、访问敏感文件或调用高风险API。OWASP将此类问题视为典型的"权限边界失控"风险，其本质是没有遵循最小权限原则，导致Skill从"功能组件"演变为了高风险执行单元，因此必须通过细粒度权限控制、动态授权与运行时策略约束来限制其影响范围
风险场景
SKILL过度授权的攻击场景包括：
- SKill 过度权限被滥用：Skill被赋予文件系统全读写、数据库全访问或云资源管理等高权限，一旦被触发即可直接执行高危操作，导致系统级数据泄露或配置篡改。
- Prompt间接驱动攻击：攻击者通过构造诱导性Prompt，使Agent在“正常任务执行”的名义下自动调用高权限Skill，从而实现合法调用链下的恶意操作。
- 自动化执行放大风险：由于Agent具备自动调用Skill并执行多步骤任务的能力，攻击行为无需人工确认即可完成，使得风险在执行链路中被指数级放大
- 大规模数据外泄风险：SKILL被过度授权可能一次性访问并导出全量数据库、敏感文件或密钥信息，导致企业核心数据被批量泄露
- 隐蔽性强难以检测类：Skill执行行为在系统层面表现为“合法任务完成”，缺乏明显异常特征，使攻击行为容易长期潜伏且难以及时发现
防御措施
- 最小权限原则：为每个Skill仅分配完成其功能所必需的最低权限，避免赋予全局访问或管理员级权限，从源头限制攻击面
- 细粒度权限控制：涉及SKILL需要对文件、数据库、API和云资源操作时需要进行分级授权，例如：按表、目录、字段或接口级别限制访问范围
- 高风险操作人工审批：对数据导出、系统配置修改、批量删除等敏感操作强制引入人工确认流程
- API访问白名单控制：仅允许Skill调用经过批准的API接口，禁止动态调用未知或高风险接口
- 敏感操作隔离执行：将删除、写入、支付、权限变更等操作放入独立执行环境，并设置额外安全校验
- 审计日志可追溯性：记录所有Skill的权限申请、调用路径与执行结果，支持事后追踪与攻击溯源
AST04:不安全元数据
风险介绍
Insecure Metadata(不安全的元数据)是指AI Agent在使用Skill、工具、模型或外部资源时，其依赖的元数据信息(例如：描述信息、权限声明、参数说明、调用示例、版本信息或配置文件)被攻击者篡改、伪造或滥用，从而误导Agent的决策与执行行为的一类安全风险。在Agentic AI系统中元数据通常用于指导模型如何选择工具、如何调用Skill以及如何理解输入输出结构，但由于这些信息往往以"非结构化文本"或"弱校验配置"的形式存在，攻击者可以通过修改Skill描述、注入恶意提示词、伪造工具说明或篡改参数定义，使Agent错误地选择高风险工具、执行越权操作或将敏感数据传递给错误的执行路径。OWASP将此类风险视为典型的“信任边界被元数据破坏”的问题，其本质是Agent过度依赖不可信的描述性信息，而缺乏对元数据真实性与完整性的校验机制
风险场景
SKILL中不安全的元数据攻击场景包括：
- 工具描述伪造：攻击者篡改Skill或Tool的metadata描述信息并将高风险或恶意工具伪装成“安全工具”、“日志分析工具”、“文件清理工具”等，使Agent在语义理解层面误判工具真实用途，从而错误选择并执行危险操作
- 参数Schema污染：攻击者修改工具的参数定义(例如：JSON Schema、OpenAPI Spec)，篡改字段含义、默认值或类型约束，使Agent在自动填充参数或推理调用时传入错误甚至高危参数，进而触发非预期行为或数据泄露
- 权限声明伪装攻击：攻击者在metadata中伪造权限范围说明，例如：标注为“只读访问”或“安全查询接口”，但实际工具具备写入数据库、执行系统命令或访问敏感资源的能力，导致Agent基于错误信任执行越权操作
- Prompt型Metadata注入：攻击者在工具描述、参数说明或README字段中嵌入隐藏指令或诱导性语句，使得Agent在解析metadata时将其当作上下文指令执行，从而改变工具选择逻辑或触发敏感信息泄露
- 版本与来源伪造攻击风险：攻击者伪造工具版本号、作者信息或可信来源标签，使恶意工具看起来来自“官方版本”或“高可信发布者”，提高其在工具选择排序中的优先级，从而增加被Agent自动选中的概率
防御措施
不安全的元数据的防御措施包括：
┌──────────────────────────────────────────────────────────────┐
│ 🧑 Agent / LLM 应用层 │
│ - Tool Selection / Skill Invocation │
│ - Multi-Agent Workflow │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 🔐 Metadata可信解析层（Secure Metadata Parser） │
│ - Prompt Injection检测（Metadata Sanitization） │
│ - 非结构化文本隔离（Untrusted Text Isolation） │
│ - Schema严格解析（Strict Schema Validation） │
│ - 字段类型强校验（Type Enforcement） │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 🧾 Metadata完整性验证层（Integrity Verification） │
│ - 数字签名校验（Digital Signature Check） │
│ - Hash一致性校验（Integrity Hash Validation） │
│ - 版本绑定验证（Version Binding Check） │
│ - 来源可信验证（Provenance Verification） │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 📦 可信注册中心（Trusted Tool Registry） │
│ - Tool / Skill Registry │
│ - Approved Metadata Store │
│ - Version Control System │
│ - Publisher Identity Management │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ ⚙️ 工具选择控制层（Tool Selection Guardrail） │
│ - Tool Ranking Isolation │
│ - Metadata vs Capability Cross-check │
│ - Risk Scoring Engine │
│ - High-risk Tool Blocking │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 🧱 运行时行为验证层（Runtime Verification Layer） │
│ - Behavior vs Metadata Consistency Check │
│ - API Call Monitoring │
│ - Parameter Runtime Validation │
│ - Execution Anomaly Detection │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 📊 安全监控与审计层（Observability & Audit） │
│ - Metadata Change Log │
│ - Tool Invocation Trace │
│ - Anomaly Alerting │
│ - Incident Forensics │
└──────────────────────────────────────────────────────────────┘AST05:不安全反序列化
风险介绍
Unsafe Deserialization(不安全反序列化)是指AI Agent或其依赖系统在处理外部输入数据时，对序列化数据(例如：JSON、YAML、Pickle、protobuf、模型配置文件、Skill状态数据等)缺乏安全校验与边界控制，从而导致攻击者通过构造恶意序列化内容，在反序列化过程中触发代码执行、对象注入、逻辑篡改或权限提升的一类安全风险。在Agentic AI场景中这类问题尤为常见，因为Agent经常需要加载工具状态、记忆缓存、插件配置以及跨系统传输的数据，一旦这些数据在反序列化时被信任就可能被注入隐藏指令或恶意对象结构。例如：攻击者可以构造特制的Pickle对象触发远程代码执行或在YAML/JSON中嵌入复杂结构改变Agent执行逻辑，甚至通过模型缓存文件污染推理结果。OWASP将其视为典型的“数据即代码”风险，其本质是系统在恢复数据结构时错误地执行了不可信输入，从而打破了数据与执行逻辑之间的安全边界。
风险场景
- 数据存储污染攻击：恶意序列化数据被写入Agent memory、会话缓存、Skill状态文件或向量数据库等持久化存储中，使攻击载荷进入“可信数据层”
- 自动加载触发反序列化：系统在恢复会话、加载工具配置或读取缓存时，自动对存储数据进行反序列化处理，在未做安全校验的情况下触发潜在攻击载荷
- 对象重建执行阶段：反序列化过程中，恶意对象结构被还原并触发构造函数、回调函数或特殊字段执行逻辑，使数据恢复过程转变为代码执行入口
- 隐蔽执行与控制阶段：攻击最终在系统内部静默执行，实现远程代码执行、参数篡改或Agent行为劫持，并通过正常返回流程掩盖异常行为
- 恶意序列化载荷注入：攻击者构造包含隐藏逻辑或可执行结构的序列化数据(例如：Pickle payload、YAML tag、JSON对象注入或protobuf异常字段)将恶意执行链嵌入数据结构中
防御措施
- 运行时行为监控：实时监控反序列化过程中的对象创建行为、异常调用路径及执行链触发情况
- 危险对象执行禁用：禁止在反序列化过程中触发构造函数、回调函数或任意代码执行逻辑，从源头阻断RCE风险
- 嵌套深度复杂度限制：限制反序列化对象的嵌套层级与结构复杂度，防止通过深层对象嵌套触发资源耗尽或逻辑绕过
- 输入来源与可信校验：在反序列化之前对数据来源进行严格校验，仅允许来自可信系统、已认证服务或签名数据源的输入进入处理流程
- 白名单反序列化机制：仅允许预定义的安全类、对象类型或数据结构被反序列化，禁止动态或未知类型对象的加载与实例化
AST06:弱隔离风险
风险介绍
Weak Isolation(弱隔离)是指AI Agent系统在多组件、多任务或多租户运行环境中缺乏足够的隔离机制，导致不同Agent实例、Skill执行环境、数据上下文或工具调用之间可以相互影响或发生信息泄露的一类安全风险。在Agentic AI架构中隔离通常涉及运行时环境隔离(容器或虚拟机)、数据隔离(Memory/Context隔离)、权限隔离(Tool调用权限分区)以及会话隔离等多个层面。如果这些隔离措施设计不完善，例如：多个Agent共享同一上下文窗口、Skill运行在同一进程空间、不同用户请求共享缓存或工具状态就可能导致敏感信息跨会话泄露、权限横向扩展甚至被攻击者利用“低权限Agent”间接访问高权限资源。OWASP将其定义为典型的“边界失效类风险”，其本质是系统未能在AI执行单元之间建立清晰的信任边界，从而使攻击影响可以跨Agent、跨任务甚至跨用户扩散
风险场景
SKILL弱隔离常见攻击风险场景包括：
- 跨会话数据泄露类攻击：由于不同Agent或用户共享Memory、缓存或上下文存储空间，攻击者可以通过查询或提示构造，间接访问到其他会话中的敏感信息或历史数据
- 工具执行环境复用攻击：多个Agent共享同一工具执行上下文或运行环境时，攻击者可通过污染执行状态或参数残留，实现对高权限工具调用的间接劫持与越权执行
- RAG索引串扰污染攻击：在多租户共享向量数据库或检索系统时，一个Agent的检索请求可能返回其他用户的数据片段，导致信息混淆或敏感数据泄露
- Skill状态共享污染攻击：当多个Agent共享Skill运行状态或配置时，一个Agent的行为可能修改或影响其他Agent的执行逻辑，从而导致功能被间接篡改或劫持
- 权限横向扩展风险攻击：低权限Agent利用共享运行环境中的漏洞或未隔离资源，间接访问高权限数据或工具，实现跨权限边界的横向移动与数据获取
防御措施
- 数据隔离机制：不同用户、Agent实例或租户提供独立的数据存储空间，确保Memory、缓存和上下文信息不会跨会话或跨租户共享
- 运行环境隔离：通过容器、虚拟机或沙箱技术，为每个Agent或Skill提供独立执行环境，防止状态污染与执行上下文复用
- RAG索引隔离：为不同用户或业务域建立独立的向量数据库或索引分区，避免检索结果跨租户混合或信息泄露
- 工具权限隔离：对不同Agent或任务分配独立的工具访问权限与执行上下文，防止低权限Agent复用高权限工具状态
- 会话隔离机制：确保不同对话或任务的上下文窗口完全隔离，避免历史信息在不同会话之间被误读或复用
- 多租户隔离架构：在系统架构层面实现租户级隔离，包括计算资源、存储资源和网络资源的完全分区
AST07:更新漂移风险
风险介绍
Update Drift(更新漂移)是指AI Agent、Skill、模型、依赖库或安全策略在持续更新过程中，由于版本变化、配置偏移、策略不同步或依赖链变更，逐渐偏离原始安全基线与预期行为，从而引发安全失控的一类风险。在Agentic AI场景中系统通常依赖频繁迭代的模型版本、Skill插件、Prompt模板、工具Schema以及外部API，一旦更新流程缺乏统一治理就可能出现“开发环境与生产环境不一致”“安全策略未同步”“旧权限残留”“新版本绕过旧防护”等问题。例如:某个Skill在更新后新增高权限能力但未更新访问控制策略或模型升级后改变Tool调用行为，导致原本安全的执行链出现新的攻击面。OWASP将其视为一种典型的“安全基线漂移风险”，其本质是系统在不断演化过程中失去了对配置、权限与行为一致性的控制，最终导致隐蔽性的安全漏洞逐渐积累并暴露
风险场景
更新漂移常见的风险场景包括：
- 模型行为漂移：模型升级后改变了Prompt理解方式、Tool调用逻辑或推理行为，但是原有安全策略仍基于旧模型设计，导致原本有效防护边界逐渐失效
- 多环境配置漂移：开发、测试与生产环境之间的配置、安全策略或权限控制逐渐不一致，导致部分环境缺失关键防护，随着时间迁移从而形成隐蔽漏洞
- 安全策略版本滞后：Agent系统与Skill组件已完成升级，Policy Engine、审计规则或检测策略仍停留在旧版本逻辑，导致新型行为无法被正确识别与限制
- 依赖链更新引入隐性风险：第三方SDK、依赖库或底层框架升级后改变了默认行为、配置逻辑或权限模型，在兼容性变化中引入新的攻击面与潜在漏洞
- Skill能力扩展未同步权限：Skill更新后新增文件写入、Shell执行或高权限API调用等能力，但是访问控制策略、白名单策略等未同步更新，从而产生新的越权风险
防御措施
Update Drif风险的核心防御思想是建立"持续一致的安全基线治理体系"，确保模型、Skill、依赖库、Prompt、Tool Schema与安全策略在更新过程中始终保持同步演化。企业首先需要建立严格的版本管理与配置基线机制并对所有组件实施版本锁定(Version Pinning)、配置快照与变更审计，避免不同环境之间出现不可控差异。同时在每次模型或Skill更新时，不仅要验证功能兼容性，还必须同步进行权限审查、策略校验与安全回归测试，确保新版本不会绕过既有安全边界。对于依赖链与第三方组件，应建立自动化供应链扫描与行为差异分析机制，及时发现新增权限、默认行为变化或潜在攻击面。此外还应通过Policy-as-Code、CI/CD安全门禁、运行时行为监控以及多环境一致性校验等方式，实现“更新即验证、部署即审计、异常即回滚”的闭环控制。本质目标是让AI系统在持续迭代过程中始终维持"功能变化与安全策略同步变化"，防止系统随着时间推移逐渐偏离原有安全控制范围
AST08:Poor Scanning
风险介绍
Poor Scanning(扫描能力不足)是指AI Agent系统在开发、部署、更新或运行过程中缺乏对模型、Skill、依赖库、Prompt、元数据、数据集以及运行行为的有效安全扫描与风险检测能力，从而导致恶意内容、漏洞组件、隐藏权限或异常行为长期未被发现的一类安全风险。在Agentic AI场景中系统通常会动态加载第三方Skill、自动更新依赖、接入外部数据源并频繁调用工具链，如果缺少针对Prompt Injection、恶意Skill、元数据污染、依赖漏洞、数据投毒或权限异常的专项扫描机制，攻击载荷就可能以“合法组件”的形式进入生产环境。例如：恶意Skill隐藏在正常插件中、模型权重携带后门、依赖库包含已知漏洞或Prompt模板中嵌入敏感指令，而系统由于仅进行传统漏洞扫描或完全缺乏AI专项检测，最终无法及时识别风险。OWASP将其视为典型的“安全可见性缺失”问题，其本质是企业对AI系统缺乏持续、深度和上下文感知的安全检测能力
风险场景
扫描能力不足的风险场景主要包括：
- 依赖库漏洞未扫描：第三方依赖或SDK中存在已知或未知漏洞，但由于缺乏SCA或深度依赖扫描机制，漏洞组件被直接集成并在运行时被攻击者利用
- 隐藏指令注入检测：攻击者在Prompt模板或元数据中嵌入隐蔽指令或误导信息，由于扫描系统未识别语义级攻击内容，导致Agent在执行时偏离原始安全策略
- 运行时缺乏持续扫描：系统仅在部署阶段进行一次性扫描，缺乏运行时持续检测能力，使得后期引入的行为变化、动态攻击或环境漂移无法被及时发现与阻断
- 模型后门未被检测：在模型权重或微调过程中植入触发式后门行为，由于扫描机制缺乏深度行为分析能力，无法识别输入-输出异常映射，使模型在特定触发条件下输出恶意或操控性结果
- 恶意Skill绕过基础扫描：攻击者上传表面功能正常但内含隐藏逻辑的Skill，利用静态或规则型扫描能力不足的缺陷，使后门代码未被识别并直接进入生产环境，在特定条件下触发数据窃取或恶意操作
防御措施
AST08防御的核心是把“扫描”变成贯穿整个AI生命周期的连续安全系统，而不是一个检查步骤：
┌──────────────────────────────────────────────────────────────┐
│ 🧑 1. 组件引入阶段（Source Intake） │
│ Skill / Model / Dependency / Prompt / Data │
└──────────────────────────────────────────────────────────────┘
│
▼
🔴【卡点1：供应链可信验证（Trust Gate）】
- 来源认证（Trusted Registry Only）
- 数字签名校验（Signature Verification）
- 发布者身份验证（Publisher Auth）
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 📦 2. 预扫描阶段（Pre-Scan Layer） │
│ 静态分析 + 元数据解析 + 结构检查 │
└──────────────────────────────────────────────────────────────┘
│
▼
🟠【卡点2：静态安全扫描（Static Security Scan）】
- 依赖漏洞扫描（SCA）
- Skill代码审计（Static Code Analysis）
- Prompt/Metadata Injection检测
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 🧪 3. 深度分析阶段（Deep Inspection） │
│ 行为模拟 + 沙箱执行 + 模型测试 │
└──────────────────────────────────────────────────────────────┘
│
▼
🟡【卡点3：行为级扫描（Behavioral Analysis）】
- 沙箱运行（Sandbox Execution）
- API调用模拟分析
- 模型输入输出异常检测
│
▼
┌──────────────────────────────────────────────────────────────┐
│ ⚙️ 4. 部署阶段（Deployment Gate） │
│ CI/CD发布 + 版本控制 + 环境同步 │
└──────────────────────────────────────────────────────────────┘
│
▼
🔵【卡点4：发布安全门禁（Release Security Gate）】
- Policy-as-Code校验
- 版本漂移检测（Drift Check）
- 权限一致性验证
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 🧠 5. 运行阶段（Runtime Execution） │
│ Agent / Skill / Tool 调用执行 │
└──────────────────────────────────────────────────────────────┘
│
▼
🟣【卡点5：运行时扫描（Runtime Security Monitoring）】
- 行为异常检测（Anomaly Detection）
- Tool调用监控
- Prompt Injection Runtime Detection
- 数据外传检测（Exfiltration Guard）
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 📊 6. 持续监控阶段（Continuous Scanning） │
│ 全链路日志 + 安全分析 + 威胁情报 │
└──────────────────────────────────────────────────────────────┘
│
▼
⚫【卡点6：持续安全扫描（Continuous Security Scan）】
- 周期性重扫描（Re-scan）
- Threat Intelligence Feed
- 行为回溯分析（Forensics）
- 自动隔离 / Kill SwitchAST09:缺乏治理风险
风险介绍
No Governance(缺乏治理)是指在AI Agent系统的设计、开发、部署与运行过程中缺少统一的安全治理框架、标准规范与生命周期管理机制，导致模型、Skill、Prompt、工具、数据与权限策略各自独立演进、无统一约束的一类系统性风险。在这种情况下不同团队可能各自引入第三方Skill、修改Prompt模板、更新模型版本或调整权限配置，但是缺乏集中化的审批、审计与策略控制机制，使得安全规则无法一致执行，甚至出现"同一系统不同Agent行为标准不一致"的情况。同时由于缺乏资产管理与责任边界定义，系统中可能长期存在未下线的旧版本Skill、未审计的模型组件或未追踪的数据流路径，使攻击面持续扩大且难以收敛。OWASP将其视为一种“结构性风险”，其本质不是单点漏洞，而是整个AI系统缺乏统一治理能力，从而导致安全控制碎片化、策略失效与风险不可见
风险场景
缺乏治理风险场景包括：
- 旧组件长期残留：已过期或存在已知漏洞的Skill、模型或依赖库未被及时下线，长期驻留在生产环境中，成为可被反复利用的攻击入口
- 治理碎片组合利用：多个看似独立的小型治理缺陷(例如：权限配置不一致、组件版本差异、策略缺失)被攻击者组合利用，形成跨组件的系统级攻击链路
- 未审批组件引入：攻击者或内部团队绕过统一治理流程，将恶意或未审计的Skill、模型或插件直接引入生产环境，由于缺乏集中审批机制，使恶意组件长期在线运行
- 多版本策略冲突：不同团队独立维护Prompt、模型或安全策略版本，缺乏统一基线管理，导致同一系统在不同调用路径中表现出不一致的安全行为，从而被攻击者利用绕过防护
- Shadow AI隐蔽接入：未经纳管的Agent实例或自动化脚本在未登记资产系统的情况下接入企业内部工具与数据接口，形成治理盲区并被用于隐蔽数据访问或操作
防御措施
AST09防御的本质是把AI系统从“工具集合”变成“可控资产体系”
┌──────────────────────────────────────────────────────────────┐
│ 🧑 1. AI资产接入阶段（Asset Intake） │
│ Skill / Model / Prompt / Tool / Data / Agent │
└──────────────────────────────────────────────────────────────┘
│
▼
🔴【卡点1：统一资产登记（Central Asset Registry）】
- 所有AI资产必须登记（Model/Skill/Tool）
- 未登记资产禁止接入生产环境
- Shadow AI识别与拦截
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 📦 2. 组件引入阶段（Component Onboarding） │
│ 第三方Skill / 模型 / Prompt模板 / 插件 │
└──────────────────────────────────────────────────────────────┘
│
▼
🟠【卡点2：统一审批流程（Governance Approval Gate）】
- 安全评审（Security Review Board）
- 风险评级（Risk Scoring）
- 合规检查（Compliance Check）
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 🧪 3. 标准化检测阶段（Standardized Validation） │
│ 安全扫描 + 行为分析 + 依赖检查 │
└──────────────────────────────────────────────────────────────┘
│
▼
🟡【卡点3：统一安全基线（Security Baseline Enforcement）】
- Prompt/Model/Skill基线对齐
- 版本一致性校验（Version Alignment）
- Policy-as-Code强制执行
│
▼
┌──────────────────────────────────────────────────────────────┐
│ ⚙️ 4. 部署治理阶段（Controlled Deployment） │
│ CI/CD发布 + 多环境同步 │
└──────────────────────────────────────────────────────────────┘
│
▼
🔵【卡点4：环境一致性治理（Environment Governance）】
- 开发/测试/生产环境统一策略
- 配置漂移检测（Configuration Drift Detection）
- 版本锁定（Version Pinning）
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 🧠 5. 运行治理阶段（Runtime Governance） │
│ Agent / Skill / Tool 执行 │
└──────────────────────────────────────────────────────────────┘
│
▼
🟣【卡点5：运行时治理控制（Runtime Policy Enforcement）】
- 权限动态控制（Dynamic Access Control）
- Shadow AI检测
- 行为异常识别（Behavior Governance）
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 📊 6. 持续治理阶段（Continuous Governance） │
│ 审计 / 资产管理 / 风险分析 / 生命周期管理 │
└──────────────────────────────────────────────────────────────┘
│
▼
⚫【卡点6：全生命周期治理（Lifecycle Governance）】
- 资产生命周期管理（Create → Update → Retire）
- 定期审计（Governance Audit）
- 自动下线机制（Auto Decommissioning）AST10:跨平台风险
风险介绍
Cross-Platform Reuse(跨平台复用风险)是指AI Agent、Skill、模型组件、Prompt模板、工具链或数据在不同平台、系统或环境之间被重复使用或迁移时，由于安全策略不一致、上下文差异或信任边界缺失，从而引发权限扩展、数据泄露或行为失控的一类风险。在实际AI生态中同一个Skill可能同时运行在不同Agent平台(例如：企业内部系统、第三方SaaS、开源框架或边缘设备)，同一Prompt模板可能在不同业务场景中复用，同一模型或插件可能存在跨环境部署，但这些平台往往具有不同的权限模型、数据隔离机制与安全策略。一旦缺乏统一的安全标准或跨平台验证机制就可能出现"在A平台安全的组件，在B平台变成高危能力"的情况。例如：在内部系统中仅用于日志分析的Skill被迁移到外部Agent平台后获得更高数据访问权限或一个Prompt模板在不同系统中被扩展为可调用敏感工具，从而形成跨环境的攻击面扩散。OWASP将其视为典型的"边界迁移风险"，其本质是安全控制无法随组件跨平台移动而同步继承，导致信任边界在不同系统之间断裂
风险场景
跨平台风险场景包括以下几种：
- 受限环境组件导出：攻击者或内部人员将原本在低权限或受控平台中开发的Skill、Prompt或模型组件导出，组件本身虽功能正常，但是缺乏完整安全上下文约束
- 跨平台复用与迁移：被导出的组件在未经过安全适配与重新评估的情况下，直接被迁移到其他AI平台或Agent系统中并重新部署上线
- 安全策略未继承：跨平台迁移过程中，原平台的安全策略、访问控制与审计规则未同步继承或映射，导致新环境缺乏必要的约束机制
- 权限模型不一致利用：不同平台之间权限控制策略不一致，攻击者利用高权限平台的默认宽松策略，使原本受限的组件获得额外数据访问或执行能力
- 高权限环境数据滥用：在目标平台中，复用组件被赋予更高权限后直接访问敏感数据源或执行高风险操作，从而造成数据泄露或系统控制风险
防御措施
- 跨平台安全继承机制：在组件迁移或复用时，强制携带原始安全策略、权限边界与审计规则，确保Skill、Prompt或模型在不同平台中保持一致的安全约束
- 统一身份与信任体系：建立跨平台统一的身份认证与信任管理机制，对所有AI组件进行身份绑定与可信标记，防止未认证组件在不同平台间随意复用
- 跨平台权限映射与校验：在组件迁移过程中，对源平台与目标平台的权限模型进行映射比对，自动检测权限扩展或策略缺失情况
- 最小权限重新评估：所有跨平台复用组件在新环境中必须重新进行权限审查，仅授予完成任务所需的最低权限，避免权限继承放大风险
- 安全基线强制对齐：要求不同平台之间共享统一的安全基线标准（Policy-as-Code），确保Prompt、Skill和模型在部署前满足一致的安全要求
- 跨平台组件注册与追踪：建立集中化组件注册中心，对所有跨平台复用的AI资产进行登记、版本管理与调用追踪，防止“影子组件”存在
- 运行时行为一致性检测：对同一组件在不同平台上的行为进行对比分析，检测是否出现权限异常扩大或行为偏移
- 动态访问控制与环境绑定：将组件权限与运行环境绑定，限制其在未授权平台或环境中执行敏感操作
- 跨平台审计与溯源机制：记录组件在不同平台的部署、调用与数据访问路径，支持跨系统安全审计与攻击溯源
- 自动化安全重新认证：每次跨平台迁移后强制触发安全重新认证流程，确保组件在新环境中通过完整安全验证后才能启用
生命周期
OWASP Agentic Skills Top 10在Skill生命周期(Creation → Distribution → Deployment → Execution → Update / Governance)中风险分布
┌────────────────────────────────────────────────────────────────────────────┐
│ 🧑 1. Skill 创建阶段 (Creation) │
│ 编写 Skill / Prompt / Tool / Manifest │
└────────────────────────────────────────────────────────────────────────────┘
│
│ 🔴 AST04 Insecure Metadata
│ 🔴 AST03 Over-Privileged Skills
│ 🔴 AST05 Unsafe Deserialization
▼
┌────────────────────────────────────────────────────────────────────────────┐
│ 📦 2. 分发阶段 (Distribution) │
│ Registry / Marketplace / GitHub / Package Repo │
└────────────────────────────────────────────────────────────────────────────┘
│
│ 🔴 AST01 Malicious Skills
│ 🔴 AST02 Supply Chain Compromise
│ 🔴 AST08 Poor Scanning
▼
┌────────────────────────────────────────────────────────────────────────────┐
│ ⚙️ 3. 部署阶段 (Deployment) │
│ CI/CD / Auto Install / Agent Loader │
└────────────────────────────────────────────────────────────────────────────┘
│
│ 🔴 AST06 Weak Isolation
│ 🔴 AST07 Update Drift
│ 🔴 AST10 Cross-Platform Reuse
▼
┌────────────────────────────────────────────────────────────────────────────┐
│ 🧠 4. 执行阶段 (Execution) │
│ Agent Runtime / Tool Invocation / Memory / RAG │
└────────────────────────────────────────────────────────────────────────────┘
│
│ 🔴 AST03 Over-Privileged Skills (runtime abuse)
│ 🔴 AST05 Unsafe Deserialization (runtime trigger)
│ 🔴 AST06 Weak Isolation (cross-agent leakage)
│ 🔴 AST08 Poor Scanning (missed runtime detection)
▼
┌────────────────────────────────────────────────────────────────────────────┐
│ 🔄 5. 更新 / 漂移阶段 (Update & Drift) │
│ Version upgrade / dependency change / policy evolution │
└────────────────────────────────────────────────────────────────────────────┘
│
│ 🔴 AST07 Update Drift
│ 🔴 AST02 Supply Chain Compromise
│ 🔴 AST10 Cross-Platform Reuse
▼
┌────────────────────────────────────────────────────────────────────────────┐
│ 🧭 6. 治理阶段 (Governance Layer - 横跨全流程) │
│ Registry / Policy / Audit / Compliance / Inventory │
└────────────────────────────────────────────────────────────────────────────┘
│
│ 🔴 AST09 No Governance
│ 🔴 AST08 Poor Scanning
│ 🔴 AST04 Insecure Metadata
▼
┌────────────────────────────────────────────────────────────────────────────┐
│ 🚨 全生命周期横向风险（Cross-Cutting Risks） │
│ │
│ AST01 → Malicious Skills │
│ AST02 → Supply Chain Compromise │
│ AST06 → Weak Isolation │
│ AST09 → No Governance │
│ │
│ 👉 这些风险贯穿所有阶段，而非单点发生 │
└────────────────────────────────────────────────────────────────────────────┘参考链接
https://owasp.org/www-project-agentic-skills-top-10/
推 荐 阅 读
图片
图片
图片
图片
横向移动之RDP&Desktop Session Hija
图片
本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。
原始发表：2026-05-17，如有侵权请联系 cloudcommunity@tencent.com 删除
评论
登录后参与评论
推荐阅读
目录
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号