Skill 不只是插件包它会注入提示词、执行脚本并继承权限安全治理必须前置。原文链接AI 小老六导语很多团队在搭 AI Agent 平台时会把 Skill 理解成插件的轻量版装上一个 Skill模型就多一项能力。这个理解很顺手但也很容易把风险看轻。Skill从来不只是一个功能包它往往同时带着说明文本、可执行脚本、依赖声明以及对当前运行环境权限的继承关系。它既像一个 npm 包也像一次curl | bash还会把陌生文本塞进模型上下文里。问题就出在这里Skill Registry不是普通的素材市场而是一个新的供应链入口。你一旦把它设计成“拿来就装、装完就能继承现有权限”的分发系统安全账就不可能等到后面再补。为什么它比传统包管理更难管传统包管理已经够难了。你要防 typosquatting、防安装脚本、防依赖混淆、防仓库接管、防维护者账号失守。到了 Skill 生态麻烦会再多两层第一层是 Prompt Injection。Skill 被激活后不只是代码开始跑Skill 自带的自然语言描述也会进入模型上下文进而影响后续判断。第二层是 权限继承。当前会话已经拿到文件、网络或命令执行权限时新装的 Skill 往往会顺手继承这套能力用户却未必再经历一次细粒度审批。第三层是 多供应链扇出。一个 Skill 既可能调用自己的脚本也可能再去拉npm、pip、cargo或其他远端资源一次安装就打开多条链路。所以一个 Skill 的危险性不只取决于“它装了什么”还取决于“它让模型相信了什么”以及“它借用了多少现成权力”。一张表看主要攻击面层级典型风险真正麻烦的地方Loader加载时执行脚本、默认信任描述文本用户以为只是安装实际上执行已经开始Registry名称抢注、版本漂移、删除后复活锁住名字不等于锁住内容Runtime描述字段误导模型选择恶意 Skill决策者不再是人而是语言模型依赖链Skill 再去调用其他包管理器一次安装同时打开多条供应链最容易被低估的往往是Loader这一层。很多平台会把所有已安装 Skill 的描述在每轮对话前都注入模型上下文方便自动选择。体验上看很丝滑安全上看却等于把发行者写的自然语言长期放在系统指令附近。只要清洗不严Skill 即使没有被明确调用也可能先一步影响模型行为。这个风险不需要脚本执行成功才会发生它在“被看见”的那一刻就已经开始。图攻击面不只在执行脚本很多风险在加载与选择阶段就已经发生。“锁版本”为什么经常只是心理安慰不少 Skill 生态目前仍是 Git 驱动。所谓版本经常只是“当时默认分支指向哪里”。如果客户端只记下nameversion却没有记录实际 commit 和文件哈希那么锁住的只是名字不是字节内容。这会带来几个直接后果发布者可以重写同一版本背后的内容。仓库被转移或接管后旧安装记录仍可能继续指向新主人。自动更新时新增权限或新增 secrets 需求可能被静默带入。包管理器花了十几年才逐步补齐 lockfile、校验和、不可变发布和透明日志这些能力。Skill 生态如果跳过这一课迟早会重演同样的事故只是这次事故里还额外带着 Prompt Injection。决策入口才是 Skill 市场最不一样的地方传统软件仓库面对的是人类搜索和安装Skill 市场面对的却往往是 Agent 自己检索、自己筛选、自己决定装哪个。这意味着新的攻击方式出现了不是先骗过工程师而是先骗过检索模型和 选择模型。如果平台把 README、描述字段和辅助文档一起向量化发布者只要往这些文本里灌入足够多“相关但不诚实”的内容就可能把无关 Skill 抬进候选列表再进一步用“官方”“已验证”“更适合当前任务”之类措辞去提高模型选中它的概率。整个过程里真正被操纵的不是安装命令而是前面的 决策入口。图从检索、选择到执行风险会沿着 Agent 决策链一路放大。如果你只审查最后的执行脚本却不审查前面的检索和选择链路相当于只盯着炸弹落地却不看它是怎么被送进来的。真正难的是很多问题都不长得像漏洞这类系统最棘手的地方在于出了事之后你未必能指出“哪一行代码写错了”。更多时候问题来自默认设计本身slug 会在 90 天后释放因为产品默认就是这么设计的。更新路径不会重新确认权限因为团队觉得那样太打扰用户。描述字段直接进提示词因为这样实现成本最低。install fan-out 默认允许多种包管理器因为生态接入更方便。每一项单看都像合理权衡合在一起就形成了非常大的攻击面。所以 Skill 安全从来不只是扫描恶意脚本。它本质上是 设计治理问题而不是上线之后再补的一轮安全加固。平台团队优先补哪几块对于正在做 Skill 平台或内部技能仓库的团队下面几件事优先级很高锁定内容而不是只锁名称客户端必须记录实际 commit 和哈希。自动更新默认不能静默扩权新增工具权限或新增 secrets 需求必须重新确认。Skill 描述文本要做长度限制、字符清洗并尽量作为数据展示而不是指令拼接。任意 Git URL 不能等价于可信注册表来源至少要做显式风险分层。检索排序和模型选择链路要纳入安全审计不能只审 manifest。把这五件事往前放本质上是在承认一件事Skill不是内容分发而是复合型执行制品的供应链管理。图越早把内容锁定、权限确认与选择审计做进去后续补洞成本越低。结语今天看 Skill 市场很像在重演十多年前包管理器的早期阶段只不过节奏更快风险也更集中。以前一个恶意包最多是在你的机器上执行代码现在一个恶意 Skill 既能执行代码又能改写模型后续行为路径还可能借用已经批准的工具能力继续扩散。如果平台设计者还把它当作普通插件系统后面会付出很高的补课成本。更成熟的做法是从第一天就承认Skill Registry管理的不是“内容”而是带提示词、脚本、依赖和权限继承关系的复合制品。这笔安全账越早算越便宜。推荐阅读LLM 编程提速之后为什么你反而更难想清楚问题AI 编程争论变味了为什么反 AI 情绪开始走向怀旧化AI 没有 ROI企业真正暴露的是 Token 成本失控Claude Opus 4.8 深度解读让 AI 模型学会承认不确定性才是真正的生产力升级AI 已经进流程了但人不能从责任链上消失招聘、授信与公共服务里的治理底线
AI Skill 市场的安全账：为什么说 Skill Registry 本质上是新的供应链入口
Skill 不只是插件包它会注入提示词、执行脚本并继承权限安全治理必须前置。原文链接AI 小老六导语很多团队在搭 AI Agent 平台时会把 Skill 理解成插件的轻量版装上一个 Skill模型就多一项能力。这个理解很顺手但也很容易把风险看轻。Skill从来不只是一个功能包它往往同时带着说明文本、可执行脚本、依赖声明以及对当前运行环境权限的继承关系。它既像一个 npm 包也像一次curl | bash还会把陌生文本塞进模型上下文里。问题就出在这里Skill Registry不是普通的素材市场而是一个新的供应链入口。你一旦把它设计成“拿来就装、装完就能继承现有权限”的分发系统安全账就不可能等到后面再补。为什么它比传统包管理更难管传统包管理已经够难了。你要防 typosquatting、防安装脚本、防依赖混淆、防仓库接管、防维护者账号失守。到了 Skill 生态麻烦会再多两层第一层是 Prompt Injection。Skill 被激活后不只是代码开始跑Skill 自带的自然语言描述也会进入模型上下文进而影响后续判断。第二层是 权限继承。当前会话已经拿到文件、网络或命令执行权限时新装的 Skill 往往会顺手继承这套能力用户却未必再经历一次细粒度审批。第三层是 多供应链扇出。一个 Skill 既可能调用自己的脚本也可能再去拉npm、pip、cargo或其他远端资源一次安装就打开多条链路。所以一个 Skill 的危险性不只取决于“它装了什么”还取决于“它让模型相信了什么”以及“它借用了多少现成权力”。一张表看主要攻击面层级典型风险真正麻烦的地方Loader加载时执行脚本、默认信任描述文本用户以为只是安装实际上执行已经开始Registry名称抢注、版本漂移、删除后复活锁住名字不等于锁住内容Runtime描述字段误导模型选择恶意 Skill决策者不再是人而是语言模型依赖链Skill 再去调用其他包管理器一次安装同时打开多条供应链最容易被低估的往往是Loader这一层。很多平台会把所有已安装 Skill 的描述在每轮对话前都注入模型上下文方便自动选择。体验上看很丝滑安全上看却等于把发行者写的自然语言长期放在系统指令附近。只要清洗不严Skill 即使没有被明确调用也可能先一步影响模型行为。这个风险不需要脚本执行成功才会发生它在“被看见”的那一刻就已经开始。图攻击面不只在执行脚本很多风险在加载与选择阶段就已经发生。“锁版本”为什么经常只是心理安慰不少 Skill 生态目前仍是 Git 驱动。所谓版本经常只是“当时默认分支指向哪里”。如果客户端只记下nameversion却没有记录实际 commit 和文件哈希那么锁住的只是名字不是字节内容。这会带来几个直接后果发布者可以重写同一版本背后的内容。仓库被转移或接管后旧安装记录仍可能继续指向新主人。自动更新时新增权限或新增 secrets 需求可能被静默带入。包管理器花了十几年才逐步补齐 lockfile、校验和、不可变发布和透明日志这些能力。Skill 生态如果跳过这一课迟早会重演同样的事故只是这次事故里还额外带着 Prompt Injection。决策入口才是 Skill 市场最不一样的地方传统软件仓库面对的是人类搜索和安装Skill 市场面对的却往往是 Agent 自己检索、自己筛选、自己决定装哪个。这意味着新的攻击方式出现了不是先骗过工程师而是先骗过检索模型和 选择模型。如果平台把 README、描述字段和辅助文档一起向量化发布者只要往这些文本里灌入足够多“相关但不诚实”的内容就可能把无关 Skill 抬进候选列表再进一步用“官方”“已验证”“更适合当前任务”之类措辞去提高模型选中它的概率。整个过程里真正被操纵的不是安装命令而是前面的 决策入口。图从检索、选择到执行风险会沿着 Agent 决策链一路放大。如果你只审查最后的执行脚本却不审查前面的检索和选择链路相当于只盯着炸弹落地却不看它是怎么被送进来的。真正难的是很多问题都不长得像漏洞这类系统最棘手的地方在于出了事之后你未必能指出“哪一行代码写错了”。更多时候问题来自默认设计本身slug 会在 90 天后释放因为产品默认就是这么设计的。更新路径不会重新确认权限因为团队觉得那样太打扰用户。描述字段直接进提示词因为这样实现成本最低。install fan-out 默认允许多种包管理器因为生态接入更方便。每一项单看都像合理权衡合在一起就形成了非常大的攻击面。所以 Skill 安全从来不只是扫描恶意脚本。它本质上是 设计治理问题而不是上线之后再补的一轮安全加固。平台团队优先补哪几块对于正在做 Skill 平台或内部技能仓库的团队下面几件事优先级很高锁定内容而不是只锁名称客户端必须记录实际 commit 和哈希。自动更新默认不能静默扩权新增工具权限或新增 secrets 需求必须重新确认。Skill 描述文本要做长度限制、字符清洗并尽量作为数据展示而不是指令拼接。任意 Git URL 不能等价于可信注册表来源至少要做显式风险分层。检索排序和模型选择链路要纳入安全审计不能只审 manifest。把这五件事往前放本质上是在承认一件事Skill不是内容分发而是复合型执行制品的供应链管理。图越早把内容锁定、权限确认与选择审计做进去后续补洞成本越低。结语今天看 Skill 市场很像在重演十多年前包管理器的早期阶段只不过节奏更快风险也更集中。以前一个恶意包最多是在你的机器上执行代码现在一个恶意 Skill 既能执行代码又能改写模型后续行为路径还可能借用已经批准的工具能力继续扩散。如果平台设计者还把它当作普通插件系统后面会付出很高的补课成本。更成熟的做法是从第一天就承认Skill Registry管理的不是“内容”而是带提示词、脚本、依赖和权限继承关系的复合制品。这笔安全账越早算越便宜。推荐阅读LLM 编程提速之后为什么你反而更难想清楚问题AI 编程争论变味了为什么反 AI 情绪开始走向怀旧化AI 没有 ROI企业真正暴露的是 Token 成本失控Claude Opus 4.8 深度解读让 AI 模型学会承认不确定性才是真正的生产力升级AI 已经进流程了但人不能从责任链上消失招聘、授信与公共服务里的治理底线
