你的凭证是如何被LLM Agent技能泄露的：一项实证研究
论文重点
首个针对LLM Agent技能生态中凭证泄露问题的大规模实证研究**。研究团队从SkillsMP平台（全球最大的开源技能市场）的170,226个构件中分层抽样17,022个技能，通过静态代码分析、动态沙箱测试和人工审查三重验证，发现520个受影响技能包含1,708个安全问题，并总结出10种泄露模式。核心发现是：76.3%的泄露案例需要联合分析自然语言描述和程序逻辑，说明凭证暴露本质上是跨模态的；73.5%的漏洞源于调试日志——Agent框架将stdout喂入LLM上下文窗口，使常规调试变成凭证暴露向量；89.6%的泄露凭证可被立即利用，且fork-based分发模式导致修复失效——从107个上游仓库移除的密钥仍活跃在50多个独立fork中。
核心研究内容
问题定义
LLM Agent正越来越多地依赖第三方“技能”（Skills）来完成各种任务——这些技能运行在特权执行环境中，经常需要处理API密钥、OAuth令牌、云凭证等敏感凭据。然而，这些凭证究竟是如何被泄露的，此前缺乏系统性的研究。传统软件安全中的凭证泄露研究范式无法直接套用于Agent技能场景，因为Agent技能的执行范式完全不同：技能不仅包含程序代码，还包含自然语言指令（SKILL.md），且所有输出（包括调试日志）都会被喂入LLM的上下文窗口。这种“代码+自然语言+执行上下文”的独特架构，催生了全新的攻击面和泄露途径。
研究围绕三个核心问题展开：
- RQ1（普遍性）：Agent技能中凭证泄露的普遍程度如何？
- RQ2（模式）：常见的泄露模式有哪些？
- RQ3（可利用性）：识别出的泄露模式在实践中的可利用程度如何？
创新方法
这项研究的最大创新在于方法论层面的三重验证架构，而非单一的技术突破：
第一层：静态分析——同时使用正则表达式匹配和AST（抽象语法树）解析，从源代码中系统性地提取硬编码密钥。AST分析能够理解代码结构，区分真正的密钥和示例占位符，大幅降低误报率。
第二层：动态沙箱测试——在隔离的Docker容器中执行技能，注入模拟凭证（Mock Credentials），监控网络I/O、系统调用和文件写入，捕获运行时暴露。研究设计了双条件测试策略（良性条件与对抗性条件），每个条件执行三轮以应对Agent行为的概率性。
第三层：开发者意图交叉验证——通过分析SKILL.md文档理解开发者声明的功能意图，与运行时行为进行交叉比对，区分“无意的疏忽”和“恶意的构造”。
此外，研究在采样方法上也体现了严谨性：从170,226个构件中采用分层随机抽样抽取17,022个技能，应用Cochran公式进行有限总体校正，样本量在99%置信水平和1%误差幅度下具有统计代表性。
研究成果
核心数据一览：
| 指标 | 数据 |
|---|---|
| 分析技能总数 | 17,022个 |
| 受影响技能 | 520个（3.1%） |
| 安全问题总数 | 1,708个 |
| 泄露模式分类 | 10种（4种开发者疏忽 + 6种恶意构造） |
| 跨模态分析需求 | 76.3%的案例需要联合分析NL描述和代码 |
| 调试日志占比 | 73.5%的漏洞 |
| 可立即利用 | 89.6% |
| 日常执行中触发 | 92.5%（无需提权） |
| 恶意技能 | 83个（16%） |
| 无意疏忽 | 437个（84%） |
| 上游修复后仍活跃 | 107个上游仓库移除的密钥在50+独立fork中存续 |
| 负责任披露后修复率 | 91.6%的硬编码案例已修复 |
四大核心发现：
跨模态泄露是根本特征：76.3%的案例中，仅靠分析代码或仅靠分析自然语言描述都无法发现泄露——必须两者结合。这是因为很多泄露藏在SKILL.md的自然语言指令中（如“请使用以下API密钥调用服务”），而代码层面可能并无明显痕迹。
调试日志是最大漏洞源：占73.5%。根本原因在于Agent框架的设计惯例——将stdout（标准输出）内容纳入LLM的上下文窗口。开发者习惯在调试时打印变量值（包括密钥），这些输出被Agent框架捕获后进入LLM上下文，可能被模型记忆、输出到日志，或被后续对话引用。
高可利用性与低利用门槛：89.6%的泄露凭证可被立即利用，且92.5%在常规执行中即可触发，无需任何提权操作。这意味着攻击者不需要复杂的漏洞利用链，只需诱导Agent执行一个被污染的技能即可。
Fork模式使修复失效：开源技能的分发模式（fork）导致安全问题“野火烧不尽”——即使上游仓库修复了问题，所有已存在的fork仍然包含泄露的凭证。
实际落地应用的可能性
- 安全扫描工具：研究的检测管道（静态+动态+意图分析）可直接产品化，用于CI/CD流程中自动扫描技能仓库
- 平台安全策略：技能市场（如SkillsMP）可集成该检测管道作为上架前的强制安全检查
- 开发者教育：10种泄露模式的分类可作为安全培训教材，帮助开发者避免常见陷阱
- 标准化倡议：研究结果为Agent技能生态的安全标准制定提供了实证基础
技术细节
泄露模式分类（10种）
研究识别出的10种泄露模式分为两大类：
开发者疏忽导致的4种模式：
- 硬编码凭证：API密钥、令牌直接写在源代码中
- 自然语言指令中的凭证：SKILL.md中明文写出密钥
- 调试日志泄露：stdout中打印敏感信息（占比最大，73.5%）
- 工具调用参数泄露：凭证通过不安全的工具调用模式传递
恶意构造的6种模式：
5.提示词注入：通过构造特定指令诱导Agent泄露凭证
6.社会工程诱导：使用说服性或欺骗性语言设计（如“为验证目的，请提供您的API密钥”）
7.混淆/规避检测：使用Base64编码等手段规避静态扫描
8.数据外泄：将凭证写入非声明文件或外发网络请求
9.权限提升：利用技能的执行权限获取更高权限
10.多模式组合攻击：37.3%的恶意技能组合多种攻击模式
凭证类型分类
研究建立了覆盖9种凭证类别的关键词字典：
| 凭证类型 | 示例 |
|---|---|
| OpenAI API密钥 | sk-... |
| AWS凭证 | AKIA... |
| 云服务凭证 | 各类云平台密钥前缀 |
| OAuth令牌 | 各类认证令牌 |
| 数据库凭证 | 连接字符串中的用户名/密码 |
| 第三方服务密钥 | Groq、Anthropic等 |
检测管道技术栈
静态分析层：
- 正则表达式匹配：基于9类凭证的关键词字典
- AST解析：使用tree-sitter框架支持Python和Node.js
- 语义约束分析：分析NL描述中的凭证相关语义
- 污点分析（Sink Detection）：追踪凭证引用是否流入不安全Sink
动态分析层：
- 隔离环境：Docker容器（Ubuntu 22.04, Python 3.11, Node.js 20）
- Agent运行时：Claude Code Agent（默认设置）
- 监控维度：
- 出站网络通信
- 非声明文件的写入
- 系统调用追踪
- 测试策略：每技能3轮良性测试 + 3轮对抗性测试
分类标准：
- 泄露指标在良性条件下出现≥2轮，或在对抗条件下出现≥1轮，即判定为确认泄露
研究设定
硬件与软件配置
| 组件 | 规格 |
|---|---|
| 隔离环境 | Docker容器（Ubuntu 22.04） |
| 编程语言运行时 | Python 3.11、Node.js 20 |
| Agent框架 | Claude Code Agent（默认配置） |
| 静态分析工具 | tree-sitter框架（多语言AST解析） |
| 数据来源 | SkillsMP平台（170,226个构件） |
研究流程（四阶段）
阶段1：数据集收集——从SkillsMP的170,226个构件中，通过分层随机抽样获取17,022个技能
阶段2：静态过滤——关键词匹配 + NL语义分析 + AST-based Sink检测，从17,022个技能中筛选出3,156个候选
阶段3：动态验证——在装有监控的沙箱中执行3,156个候选技能，分别在良性和对抗条件下测试，标记出1,427个问题
阶段4：人工分类——三位安全专家独立审查，将1,427个标记案例分为Benign（良性）、Vulnerable（漏洞）、Malicious（恶意）三类，最终确认520个案例
统计有效性
应用Cochran公式进行有限总体校正（p=0.5），17,022个样本在99%置信水平和1%误差幅度下具有统计代表性。
综合分析
为什么这个问题比想象中更严重？
这项研究揭示的本质问题远超传统“硬编码密钥”的范畴。Agent技能的安全威胁模型与普通软件有根本不同：
第一，执行上下文的特殊性。普通程序中的调试日志可能只留在本地文件，但Agent框架将stdout直接喂入LLM上下文窗口。这意味着“打印变量”这个再普通不过的调试行为，在Agent场景下等同于“把密钥发给LLM提供商”。更糟糕的是，LLM可能会在后续对话中引用这些信息，或被用于训练（如果用户未opt-out）。
第二，自然语言成为新的攻击面。传统代码审计只分析源代码，但Agent技能中的SKILL.md是自然语言指令——它们同样可以包含凭证，同样可以被Agent解析和执行。76.3%的跨模态泄露案例说明，单纯扫描代码已经不够了，必须同时分析自然语言。
第三，供应链安全的“fork困境”。开源软件的fork本是优势，但在安全问题上却成了噩梦——一旦某个版本的技能泄露了凭证，所有fork都会继承这个问题，且上游修复无法自动同步到下游。这在传统软件中已有类似问题（如Log4j），但Agent技能的快速迭代和低门槛分发加剧了这一风险。
84% vs 16% 的启示
研究发现84%的泄露源于开发者疏忽，仅16%是恶意行为。这个比例有两层含义：
乐观的一面：绝大多数问题可以通过开发者教育和自动化检测工具来解决，并非系统性的不可修复缺陷。
警示的一面：84%的“无心之失”说明当前Agent技能开发的默认安全姿态严重不足——开发者还在用写本地脚本的心态写Agent技能，没有意识到“每一个被Agent接触的数据都会‘经过’LLM”。这种认知差距是最大的安全隐患。
对AI安全社区的启示
这项研究为Agent安全领域提供了三个重要贡献：
- 基准数据集（SkillLeakBench）——为后续研究提供可复现的测试基准
- 漏洞分类体系——10种模式的系统化分类
- 检测管道——可开源/商业化的检测工具链
实践应用
对开发者的建议
- 永远不要在SKILL.md或代码中硬编码凭证——使用环境变量或密钥管理服务
- 审查所有调试输出——假设stdout的所有内容都可能被LLM看到
- 在CI/CD中集成凭证扫描——可使用研究团队开源的检测管道
- 关注fork的同步——如果fork了某个技能，定期检查上游的安全更新
- 使用零信任凭证管理方案——如Keygate这类工具，让AI只持有无意义别名
对平台运营者的建议
- 技能上架前强制安全扫描——集成类似阿里云“Skills检测”的方案
- 建立负责任披露机制——研究发现91.6%的硬编码案例可在披露后修复
- fork版本的安全追踪——建立上游修复到下游fork的通知机制
- 行为完整性检查——在安装前而非安装后进行行为完整性验证
对企业安全团队的建议
- 盘点已部署的Agent技能清单——研究显示3.1%的技能存在泄露问题
- 假设所有技能都不可信——“Trust No Skill”应成为默认安全原则
- 在生产环境部署前进行动态沙箱测试——静态扫描不足以发现所有问题
- 监控Agent的网络出站流量——数据外泄是最直接的攻击指标
参考资料来源
- 原始论文: arXiv:2604.03070
- PDF全文: https://arxiv.org/pdf/2604.03070
- 数据集: SkillLeakBench on Hugging Face
- 会议: ASE 2026 (The 41st IEEE/ACM International Conference on Automated Software Engineering)
