LLM 智能体 skill 中的凭据泄露：一项覆盖 1.7 万个 skill 的实证研究
2026 年 4 月 3 日的一篇 arXiv 研究分析了 17022 个智能体 skill，发现其中 520 个泄露凭据——73.5% 的泄露源自把密钥直接写入模型上下文的调试日志。
这是什么？
2026 年 4 月 3 日，一个团队在 arXiv 上发表了 Credential Leakage in LLM Agent Skills: A Large-Scale Empirical Study——这是首次对第三方「skill」如何泄露其所托管密钥的大规模测量。skill 是一组自然语言指令与辅助脚本的封装包，用于扩展智能体的能力；它通常运行在具有特权的环境中，可访问 API 密钥、令牌和数据库凭据。
该研究抽取了 17022 个 skill（取自作者称为 SkillsMP 的市场所收录的 170226 个 skill，于 2026 年初采集），并结合静态分析、沙箱执行与人工审查。研究识别出 520 个存在漏洞的 skill，共 1708 个不同问题，并归纳出 10 类泄露模式——其中 4 类为意外、6 类为对抗性。这是一项以负责任披露为基础的防御性研究，而非攻击工具包：本文不复现任何可利用的载荷。
工作原理
核心发现是：skill 中的凭据泄露是跨模态的。一个 skill 既是代码也是文本，研究发现的泄露中有 76.3% 只能通过同时分析脚本及其自然语言指令才能捕获；另有较小的 3.1% 纯粹源自指令文本中的提示注入。只分析源代码、或只分析提示词的工具，会漏掉大部分攻击面。
最主要的途径却很平常：调试日志。简单的 print 与 console.log 语句占了 73.5% 的泄露，因为 skill 的标准输出会被直接注入智能体的对话上下文。为调试而写入 stdout 的密钥，实际上等于交给了模型——以及下游任何能读取该上下文的环节。
泄露路径（概念示意）
skill 脚本 --将密钥打印到 stdout--> 模型上下文窗口
|
日志 / 记忆 / 对话记录
|
可被下游工具读取涉及的凭据覆盖了整个范围：云与 API 密钥（AWS、GCP 服务账号 JSON、gsk-/AKIA 形式的第三方密钥）、OAuth 与平台令牌、数据库连接串、SMTP 与管理员密码、SSH/TLS 私钥材料、Webhook 签名密钥，乃至加密货币钱包私钥。尤为关键的是，泄露凭据中有 89.6% 无需任何特殊权限即可被利用，而且这种暴露是持久的：从上游仓库中删除的密钥，仍存活于保留了旧材料的独立 fork 中，即便原始仓库已被修复。
为何重要
skill 正成为扩展智能体的默认方式，而市场模式意味着开发者安装的是陌生人编写的代码，这些代码随后会以开发者自己的凭据运行。这项研究把一个长期被怀疑的风险变成了可测量的事实，与之并行的还有 2026 年 4 月关于野外恶意 skill（2026 年 6 月 10 日修订）以及 skill 生态供应链投毒的研究。
有两个数字应当重塑威胁模型。其一，stdout 到上下文的管道是一条传统密钥扫描从未需要担心的泄露通道——你在 CI 中的密钥扫描器并不会监视工具在运行时打印了什么。其二，fork 在上游修复后仍保留密钥，因此「我们已轮换并修补了原始仓库」并不等于已经遏制。导致安全可靠性故障的同一套架构——一个打印过多的 skill——正是攻击者用来制造安全漏洞的那套架构。
防御
作者提出了具体的、分层的缓解措施。对于运行智能体和编写 skill 的人：
- 把 stdout 当作不可信输出，而非私有日志。 skill 打印的任何内容都可能进入模型上下文。在 stdout 流进入对话记忆之前过滤掉已识别的凭据模式，且绝不用明文密钥进行调试。
- 在架构层面落实最小权限。 应在前期就限定并最小化每个 skill 的凭据暴露，而非事后清洗。一个 skill 只应持有其所需的最窄令牌，且持有时间最短。
- 将推理引擎与执行引擎隔离。 论文主张基于能力的隔离——让 LLM 与 skill 各自拥有独立的内存与网络访问——使执行中的泄露不致演变为上下文中的泄露。
- 把发布前的密钥扫描设为强制环节。 将密钥扫描纳入 skill 开发生命周期，作为发布前的必经步骤，而非可选的加固。请注意，需要代码与语言联合扫描，才能捕获那占多数的跨模态情形。
- 轮换密钥，并将 fork 视为已被攻陷。 由于密钥会在 fork 中持续存在，应轮换任何曾经触及已发布 skill 的凭据，并假设被 fork 的副本仍携带旧值。仅从
main中删除并不足够。
状态
| 项目 | 参考 | 日期 | 备注 |
|---|---|---|---|
| 研究发表 | arXiv 2604.03070 | 2026-04-03 | 分析 17022 个 skill；520 个存在漏洞；1708 个问题 |
| 泄露分类法 | arXiv 2604.03070 | 2026-04-03 | 10 类模式（4 类意外、6 类对抗性） |
| 主导途径 | arXiv 2604.03070 | 2026-04-03 | 调试日志（print/console.log）= 73.5% 的泄露 |
| 可利用性 | arXiv 2604.03070 | 2026-04-03 | 89.6% 无需权限即可利用；在 fork 中持续存在 |
| 披露结果 | arXiv 2604.03070 | 2026-04 | 恶意 skill 已下架；91.6% 的硬编码凭据已修复 |
| 相关工作 | arXiv 2602.06547 | 2026-06-10 修订 | 在两个注册表上测量恶意 skill |
对各团队而言，要点不是「skill 不安全」，而是「skill 以你的凭据运行，而你现有的密钥管理假设并未覆盖它们」。泄露通道正是模型自身的上下文窗口，修复必须落在 skill 架构与发布管道之中，而真正遏制已暴露密钥的，是轮换——而非删除。