当 Agent 从「回答问题」走向「替你行动」，安全问题就不再只是模型输出风险，而是执行风险。真正决定事故上限的，不只是模型层，而是承接权限、工作流和工具调用的技能执行层。
如果你只看三句话，可以先看这里。
- 模型层的主要问题，往往是回答错了
- 技能层的主要问题，往往是事情做错了，甚至做了本不该做的事
- Agent 安全真正需要补课的，不只是提示词防护，而是一整套可信执行机制
很多团队谈 AI Agent 风险，第一反应还是模型。
会不会幻觉，会不会被提示词绕过，会不会胡说八道。
这些当然重要。
但当 Agent 开始接文件系统、连企业系统、调 shell、读 memory、发请求、跑多步流程，风险中心就已经悄悄挪地方了。真正决定事故上限的，往往不再只是模型层，而是 技能执行层。
换句话说，模型决定它怎么想，技能决定它怎么做。很多真实世界的安全事故，不是因为模型多说了一句错话，而是因为 Agent 多做了一件错事。
为什么今天必须把注意力从模型层，移到技能执行层
过去大家盯着模型，很正常。
因为大模型刚进入业务系统时，最直观的风险就是内容层，幻觉、越狱、有害输出、隐私泄露、提示词注入。这些风险都跟模型输出直接相关，也更容易被看见。
但 Agent 和普通聊天机器人不是一回事。
一个普通聊天机器人，说错话，问题通常停留在内容层。一个接了技能的 Agent，说错话之外，还可能真的去做事。它会把自然语言解释成动作链，把动作链落到工具调用，把工具调用落到你的主机、你的凭证、你的网络出口、你的业务系统上。
OWASP 在 Agentic Skills Top 10 里给了一个很关键的判断，MCP 更像模型和工具沟通的协议层，Skills 则是决定这些工具最终替你做什么的行为层。
这句话非常重要。
因为很多团队已经开始对模型做红队、对提示词做防注入、对 MCP 工具做访问控制，却没有意识到，中间还有一层真正决定攻击能否落地的行为编排层。
也就是 Skill。
一个更准确的心智模型，模型是大脑，技能是手脚和流程
如果把 Agent 想成一套完整系统，大致可以拆成四层。
- 模型层，负责理解、推理、生成
- 协议与工具层，负责给模型提供可调用的能力接口，比如 MCP、函数调用、插件接口
- 技能执行层，负责把任务拆成步骤，决定先读什么、再调什么、最后怎么写回去
- 现实世界动作层，负责真正对文件、命令、网络、数据库、邮件、工单系统产生影响
这里真正容易被低估的，是第三层。
因为 Skill 看起来不像传统意义上的危险代码。它经常只是一个 SKILL.md、一个 skill.json、一段 YAML frontmatter、一个 manifest、几段说明文字、几个脚本引用、一些约束和步骤。
看上去像配置。
其实不是。
它是 可执行行为的说明书。
而且是一种同时混合了自然语言、权限声明、工作流编排和宿主上下文共享的说明书。
这就让它天然比普通提示词更危险，也比单纯工具更难防。
Skill 为什么会成为新的高风险面
1. 它把文本风险，变成执行风险
模型层的很多风险，本质上还是输出风险。
Skill 层不一样。它直接控制执行路径。它规定 Agent 先读哪个文件，再调哪个工具，再向哪里发请求，再把什么结果写入哪个位置。
这意味着风险不再只是回答偏了，而是动作真的发生了。
比如一个看似无害的「代码整理 Skill」，如果它被植入恶意步骤，完全可能在整理代码前顺手读取 .env、SSH key、浏览器 Cookie、SOUL.md、MEMORY.md，再通过 webhook 或外部域名发出去。
这时候问题已经不是提示词越狱，而是 凭证失窃和主机失陷。
2. 它天然处在最危险的三角交汇处
OWASP 和相关研究反复提到一个判断，很多生产环境中的 Agent 同时满足三个条件。
- 能接触私有数据
- 会接触不可信内容
- 还具备对外通信能力
这三个条件叠在一起，就是事故最容易发生的地方。
Simon Willison 和 Palo Alto Networks 把这类组合概括成一种非常致命的结构。你也可以把它理解成 Agent 时代的「高危三件套」。
模型本身并不一定拥有这个组合。
Skill 经常拥有。
3. 它会借用宿主权限，把小问题放大成整机问题
很多团队做 Agent 产品时，默认让 Skill 和宿主运行在同一安全上下文里。共享文件系统，共享 shell，共享网络出口，共享凭证。
这么做开发很快，体验也很丝滑。
代价是，一旦 Skill 被污染、被串改、被投毒、被诱导，损失不再是某个功能出错，而可能直接上升到宿主级损失。
所以 OWASP 把 AST06 Weak Isolation 列成高风险，一点也不夸张。
没有隔离，就没有真正的 Skill 风险边界，只有整机风险。
4. 它既像代码，又不像代码，所以传统扫描经常失灵
这是很多团队的盲区。
安全团队对代码扫描已经很熟了，查危险函数、查命令执行、查可疑依赖、查特征字符串。
但 Skill 的恶意逻辑，很多时候并不需要显式恶意代码。
攻击者完全可以把恶意意图写进自然语言步骤里，让 Agent 自己去完成敏感读取、越权调用、外部发送。
这也是为什么 OWASP 单独列出 AST08 Poor Scanning。传统扫描器看得见代码，看不见语义驱动的行为。
如果还用老办法扫 Skill，你得到的往往不是安全，而是虚假的安全感。
OWASP AST10 真正提醒我们的，不是 10 个漏洞，而是一条完整的攻击链
OWASP最新推出Agentic Skills Top 10类别,这套框架最有价值的地方，不只是列了 10 个类别。
更重要的是，它把 Agent 技能层的系统性风险讲清楚了。
这 10 项风险，大致可以归成五组。
第一组，来源不可信
AST01 Malicious SkillsAST02 Supply Chain CompromiseAST04 Insecure Metadata
这一组说的是，风险在安装前就已经开始了。
恶意 Skill 可以伪装成效率工具、品牌插件、热门模板。供应链可以被投毒，元数据可以被伪造，描述可以被美化，风险等级可以被淡化。
用户看到的是一个好像很方便的能力包。
实际上装进去的，可能是一个带执行权的伪装体。
第二组，授权太大，隔离太弱
AST03 Over-Privileged SkillsAST06 Weak Isolation
这一组说的是，哪怕 Skill 本身不是恶意的，只要权限给大了，隔离做弱了，后面的任何小偏差都会被放大。
一个本来只该访问天气接口的 Skill，如果还能读本地文件、调 shell、写 memory、发外网，它就已经不是一个天气工具，而是一个披着天气外衣的执行代理。
第三组，加载和检测过程本身就可能出事
AST05 Unsafe DeserializationAST08 Poor Scanning
很多团队的思路是，先把 Skill 读进来，再决定是否执行。
问题是，Skill 的解析、反序列化、初始化过程，本身就可能是攻击面。
再加上传统扫描器对自然语言驱动的恶意行为识别能力有限，很多风险会在「看起来通过了检测」的情况下悄悄进入系统。
第四组，生命周期控制失效
AST07 Update Drift
在 Agent 生态里，更新不是普通的软件 patch。
它更像是你在重新批准一个会替你行动的行为体继续存在。
今天批准的是 v1.0，明天自动更新成 v1.0.1，功能描述没变，但访问路径、外联域名、写入文件、执行顺序全变了。你如果没有 pin 版本、校验 hash、保留审批，等于把新的行为差异直接吞进生产环境。
第五组，组织层完全看不见它
AST09 No GovernanceAST10 Cross-Platform Reuse
这组问题最像现实世界里的企业事故。
开发者本地一条命令装了一个 Skill，SOC 看不见，资产系统没有记录，IAM 没绑定，离职也没回收，之后这个 Skill 又跨平台迁移到了另一个 Agent 里，原来的权限语义、签名和风险标签还丢了。
到这一步，组织面临的就不是 Shadow AI，而是 Shadow Execution。
系统里存在一批会替你做事的自动执行体，但你并不知道它们是谁，从哪来，能干什么，最近干过什么。
几个数字，足够说明这不是纸上谈兵
OWASP 官方仓库整理的 2026 年公开研究里，有几组数据很刺眼。
- 扫描了 3,984 个 Skills
- 其中 36.82% 存在安全缺陷
- 13.4% 存在严重问题
- 已确认 76+ 个恶意 payload
- ClawHavoc 活动中发现 1,184 个恶意 Skills
- 还有 135,000+ 个 OpenClaw 实例暴露在公网
这些数字背后，不只是漏洞数量多。
更麻烦的是，攻击已经从单点漏洞，走向了生态位攻击。
攻击者开始盯注册中心、盯仓库配置、盯 Skill 描述、盯元数据、盯 memory 文件、盯更新链路、盯本地 WebSocket、盯那些默认把 Agent 当成本地助手跑起来的开发机。
这跟传统的依赖投毒、恶意浏览器扩展、CI/CD 供应链攻击越来越像。
只是这次多了一层自然语言驱动的执行能力。
所以危险也更大。
一个常见误区，模型做了安全，不等于 Agent 就安全了
很多团队的防线，今天还是这样配的。
- 对模型做安全对齐
- 对输入做提示词过滤
- 对输出做内容审核
- 对工具做基础鉴权
然后就觉得差不多了。
其实差得还挺远。
因为 Agent 最终是不是安全，不取决于它说得有多礼貌，而取决于它 执行链是不是可证明、可约束、可回放、可审计。
这也是为什么同样一个模型，放在聊天窗口里问题不大，接到有 Skill 的本地开发环境里，风险突然上一个台阶。
模型还是那个模型。
危险变大的，是执行层。
如果今天就要上 Agent，技能层至少要补上这五道防线
1. 把 Skill 当成可执行供应链，而不是文档资产
所有 Skill 都应该有明确来源、作者身份、签名、版本、内容哈希、变更记录。
没有 provenance，就不要默认信任。
如果平台支持注册中心透明日志、签名校验、发布审计，这些能力最好默认开启，不要依赖用户自觉。
2. 把权限从笼统允许，改成声明式最小授权
真正可用的权限控制，不是一个「允许访问文件系统」的总开关。
而是细到：
- 允许读哪些目录
- 允许写哪些目录
- 默认禁止写哪些身份和记忆文件
- 允许访问哪些外部域名
- 是否允许 shell
- 是否允许调用高风险工具
OWASP 在 Universal Skill Format 提案里强调的 deny_write、network allowlist、signature、content_hash，本质上都是在把这件事标准化。
3. 默认沙箱，不要默认宿主模式
如果一个 Skill 能直接和宿主共享文件系统、shell、网络、凭证，那么前面的权限声明和风险提示，很多时候只是心理安慰。
真正有效的办法，还是进程隔离、容器隔离、网络隔离、临时凭证、一次性工作目录。
默认安全，永远比事后提醒靠谱。
4. 从代码扫描，升级到语义扫描和运行时监控
Skill 不能只扫代码，还要扫说明、manifest、脚本引用、外联域名、权限组合、执行意图。
上线后也不能只看安装通过没有，还要看它在运行时有没有异常读取、异常写入、异常外联、异常 memory 修改。
一句话，要看行为，不只看文本。
5. 把 Skill 纳入企业治理，不要让它在资产体系外野生增长
企业里真正高风险的，不是有人研究 Agent。
而是有人已经把 Agent 跑进了开发机、知识库、客服系统、代码仓库、内网工具链，但没人盘点，也没人审批，更没人知道哪个 Skill 在替谁干活。
这件事不进 inventory，不进 IAM，不进日志，不进审批，不进离职回收，就迟早会出治理事故。
对开发者来说，最实用的判断标准是什么
如果你不是安全团队，而是一个正在接入 Agent 的工程师，我觉得可以先用四个问题做快速判断。
- 这个 Skill 从哪来，作者和版本能不能验证
- 它到底能读什么、写什么、连什么、执行什么
- 它是不是默认运行在宿主权限里
- 出事之后，我能不能知道它刚才到底做了什么
这四个问题里，只要有两个答不上来，就不该把它直接接进生产环境。
最后
AI Agent 的风险，当然有模型层。
但如果今天还只盯着模型，那就有点像只检查司机会不会说错话，却不看方向盘、油门、刹车和路线权限在谁手里。
Agent 一旦开始行动，真正危险的地方就不再只是认知错误，而是 错误被转成了动作，动作被授予了权限，权限又缺少边界和审计。
这就是为什么 2026 年开始，围绕 Skill 的安全研究一下子密集了起来。
因为大家终于意识到，Agent 安全的关键问题，不是它看起来够不够聪明，而是它到底能不能被信任去替你做事。
而这个答案，越来越不在模型里。
而在技能执行层。
