Wake Forest大学的两项研究指向同一个问题：在快速发展的AI生态中，凭证经常被放在代理、应用或攻击者能够取得的位置。

研究人员分析了17,022项第三方AI代理技能，发现520项受影响技能共包含1,708个安全问题；另一项针对444款具备大语言模型（LLM）功能的iOS应用的研究则发现，282款在测试过程中暴露了凭证或后端访问机制。124

风险并不只是“字符串泄露”这么简单。一枚暴露的API密钥或令牌，可能让攻击者访问私人数据、调用代理的高权限工具，或使用开发者账户支付模型推理费用。

代理技能研究：问题不只藏在代码里

研究团队从SkillsMP收录的170,226个工件中，分层随机抽取17,022项技能进行分析。测试结合了静态秘密检测、使用模拟凭证的动态沙箱测试，以及对比技能声明用途与实际运行行为等方法。34

研究发现：

• 520项受影响技能共包含1,708个安全问题，分布在10种凭证泄露模式中。416
• 在这520项技能中，有466项暴露了无需提升权限即可使用的凭证，对应研究报告中的89.6%立即可利用率。14
• 76.3%的泄露案例需要同时检查技能的自然语言指令和程序代码才能发现。
• 另有3.1%的案例仅通过自然语言提示注入实现，并不包含可执行代码。4

这意味着，只做传统的代码审查可能仍然不够。一项技能可能在表面上描述着合法任务，但它的指令或配套脚本可能在运行过程中暴露秘密信息。

调试输出可能把密钥直接送进模型上下文

调试日志是研究特别关注的一类泄露路径。在某些代理框架中，标准输出会被送入模型上下文。这样一来，通过print或console.log打印出来的凭证，可能在用户发出普通自然语言请求时被模型读取或返回。

研究摘要称，调试日志是主要攻击向量；由于标准输出暴露给LLM，73.5%的泄露与此类输出有关。4

问题也不只涉及明显写死在代码里的API密钥。凭证还可能通过脚本、环境变量处理、日志、提示词指令，或代码与自然语言组合后的运行逻辑泄露。某些风险只有在技能正常执行时才会显现。

恶意开发与疏忽开发都可能造成泄露

研究将凭证泄露的成因大致分为两类：

• **恶意开发：**开发者故意加入窃取凭证或私人数据的指令、载荷，并可能将信息发送到远程服务器。
• **疏忽开发：**开发者没有遵循安全编码和秘密管理实践，无意中留下可被攻击者利用的凭证或访问路径。1

这一差别决定了修复方式。恶意内容需要筛查、下架和持续追踪；意外暴露则需要改进密钥管理、日志控制、身份验证、权限设计以及发布前测试。

Wake Forest表示，在收到研究人员通知后，SkillsMP已移除所有被识别出的恶意技能，并修复了大多数存在漏洞的技能。不过，研究同时提醒，清理原始仓库并不代表风险已经消失：派生仓库或复制版本可能继续保留已经暴露的凭证。14

iOS应用暴露了另一条“劫持LLM账户”的路径

相关的iOS研究分析了444款具备LLM功能的应用，发现其中282款——约占64%——在网络流量中暴露了可利用的LLM凭证或后端访问机制。25

研究报告的主要暴露模式包括：

• 可重放的JWT令牌：48%
• 未经过身份验证的后端代理：33%
• 明文传输API密钥：19%3

这些问题在普通使用过程中就可能暴露。攻击者一旦截获密钥、重复使用令牌，或找到开放代理，就可能借用开发者的LLM账户发送请求，消耗付费推理额度、滥用关联云资源，或制造未经授权的账单。25

现有证据支持严重、甚至可能不断累积的计费风险，但并不能独立证明“损失数十万美元”这一具体金额。更准确的说法是：在账户限额、监控能力和入侵持续时间等因素影响下，泄露凭证可能导致大额且难以预估的模型服务费用。

修复进度同样不理想。负责任披露三个月后，受影响iOS应用中只有**28%修复了报告中的漏洞，研究后续测试显示仍有72%**可以被利用。311

AI辅助开发正在扩大问题的传播面

两项研究共同说明，为应用加入AI功能，或安装可复用的代理技能，并不只是一次普通的产品迭代。这些操作会同时扩大应用的攻击面，带来一系列新风险：

• 客户端应用或代理上下文中嵌入服务商密钥
• 能够访问文件、服务或私人数据的高权限工具
• 意外进入模型可读上下文的日志
• 身份验证不足的后端接口
• 可被攻击者重复使用的令牌
• 由攻击者生成、但由开发者账户承担的LLM费用

随着开发者通过AI辅助“氛围编程”（vibe coding）快速生成和拼接软件，这一问题更加突出。开发速度不能替代威胁建模；身份验证、秘密管理、授权、日志和依赖审查仍需要有意识的工程设计。

代理技能研究还称，在72%的硬编码凭证案例中发现了AI辅助开发的特征。这一结果提示，不安全的生成式代码模式可能被快速复制并大规模传播。4

研究指向的安全设计基线

对于开发AI产品或发布代理技能的团队，研究结果支持以下防护措施：

1. **不要把长期有效的服务商密钥放在客户端或模型上下文中。**敏感的模型调用应通过经过身份验证的服务端完成。
2. **使用短期、低权限凭证。**遵循最小权限原则，并验证令牌的用途、受众和有效期，不能仅凭“持有令牌”就授予访问权。
3. **对日志和标准输出进行秘密脱敏。**凡是进入代理上下文的信息，都应被视为可能被模型或用户恢复。
4. **同时扫描代码、配置、提示词和依赖项中的秘密。**代理技能的风险表明，自然语言指令与可执行代码必须联合审查。
5. **测试网络流量和后端授权。**确认被截获的请求无法重放，也无法通过未认证代理转发。
6. **立即轮换暴露的凭证，并检查派生仓库和复制版本。**从原始仓库删除秘密，并不等于所有分发版本都已清理。
7. **在发布前加入平台级审核。**市场平台筛查、开发者安全指引、负责任披露和自动化检查，应与开发者自身的安全意识相互补充。34

核心结论很直接：AI安全不能等到产品上线后再补救。凭证、代理权限、模型上下文和计费控制，都应从项目启动之初就被视为产品安全的核心组成部分。

Wake Forest大学的两项研究指向同一个问题：在快速发展的AI生态中，凭证经常被放在代理、应用或攻击者能够取得的位置。

研究人员分析了17,022项第三方AI代理技能，发现520项受影响技能共包含1,708个安全问题；另一项针对444款具备大语言模型（LLM）功能的iOS应用的研究则发现，282款在测试过程中暴露了凭证或后端访问机制。124

风险并不只是“字符串泄露”这么简单。一枚暴露的API密钥或令牌，可能让攻击者访问私人数据、调用代理的高权限工具，或使用开发者账户支付模型推理费用。

代理技能研究：问题不只藏在代码里

研究团队从SkillsMP收录的170,226个工件中，分层随机抽取17,022项技能进行分析。测试结合了静态秘密检测、使用模拟凭证的动态沙箱测试，以及对比技能声明用途与实际运行行为等方法。34

研究发现：

• 520项受影响技能共包含1,708个安全问题，分布在10种凭证泄露模式中。416
• 在这520项技能中，有466项暴露了无需提升权限即可使用的凭证，对应研究报告中的89.6%立即可利用率。14
• 76.3%的泄露案例需要同时检查技能的自然语言指令和程序代码才能发现。
• 另有3.1%的案例仅通过自然语言提示注入实现，并不包含可执行代码。4

这意味着，只做传统的代码审查可能仍然不够。一项技能可能在表面上描述着合法任务，但它的指令或配套脚本可能在运行过程中暴露秘密信息。

调试输出可能把密钥直接送进模型上下文

调试日志是研究特别关注的一类泄露路径。在某些代理框架中，标准输出会被送入模型上下文。这样一来，通过print或console.log打印出来的凭证，可能在用户发出普通自然语言请求时被模型读取或返回。

研究摘要称，调试日志是主要攻击向量；由于标准输出暴露给LLM，73.5%的泄露与此类输出有关。4

问题也不只涉及明显写死在代码里的API密钥。凭证还可能通过脚本、环境变量处理、日志、提示词指令，或代码与自然语言组合后的运行逻辑泄露。某些风险只有在技能正常执行时才会显现。

恶意开发与疏忽开发都可能造成泄露

研究将凭证泄露的成因大致分为两类：

• **恶意开发：**开发者故意加入窃取凭证或私人数据的指令、载荷，并可能将信息发送到远程服务器。
• **疏忽开发：**开发者没有遵循安全编码和秘密管理实践，无意中留下可被攻击者利用的凭证或访问路径。1

这一差别决定了修复方式。恶意内容需要筛查、下架和持续追踪；意外暴露则需要改进密钥管理、日志控制、身份验证、权限设计以及发布前测试。

Wake Forest表示，在收到研究人员通知后，SkillsMP已移除所有被识别出的恶意技能，并修复了大多数存在漏洞的技能。不过，研究同时提醒，清理原始仓库并不代表风险已经消失：派生仓库或复制版本可能继续保留已经暴露的凭证。14

iOS应用暴露了另一条“劫持LLM账户”的路径

相关的iOS研究分析了444款具备LLM功能的应用，发现其中282款——约占64%——在网络流量中暴露了可利用的LLM凭证或后端访问机制。25

研究报告的主要暴露模式包括：

• 可重放的JWT令牌：48%
• 未经过身份验证的后端代理：33%
• 明文传输API密钥：19%3

这些问题在普通使用过程中就可能暴露。攻击者一旦截获密钥、重复使用令牌，或找到开放代理，就可能借用开发者的LLM账户发送请求，消耗付费推理额度、滥用关联云资源，或制造未经授权的账单。25

现有证据支持严重、甚至可能不断累积的计费风险，但并不能独立证明“损失数十万美元”这一具体金额。更准确的说法是：在账户限额、监控能力和入侵持续时间等因素影响下，泄露凭证可能导致大额且难以预估的模型服务费用。

修复进度同样不理想。负责任披露三个月后，受影响iOS应用中只有**28%修复了报告中的漏洞，研究后续测试显示仍有72%**可以被利用。311

AI辅助开发正在扩大问题的传播面

两项研究共同说明，为应用加入AI功能，或安装可复用的代理技能，并不只是一次普通的产品迭代。这些操作会同时扩大应用的攻击面，带来一系列新风险：

• 客户端应用或代理上下文中嵌入服务商密钥
• 能够访问文件、服务或私人数据的高权限工具
• 意外进入模型可读上下文的日志
• 身份验证不足的后端接口
• 可被攻击者重复使用的令牌
• 由攻击者生成、但由开发者账户承担的LLM费用

随着开发者通过AI辅助“氛围编程”（vibe coding）快速生成和拼接软件，这一问题更加突出。开发速度不能替代威胁建模；身份验证、秘密管理、授权、日志和依赖审查仍需要有意识的工程设计。

代理技能研究还称，在72%的硬编码凭证案例中发现了AI辅助开发的特征。这一结果提示，不安全的生成式代码模式可能被快速复制并大规模传播。4

研究指向的安全设计基线

对于开发AI产品或发布代理技能的团队，研究结果支持以下防护措施：

1. **不要把长期有效的服务商密钥放在客户端或模型上下文中。**敏感的模型调用应通过经过身份验证的服务端完成。
2. **使用短期、低权限凭证。**遵循最小权限原则，并验证令牌的用途、受众和有效期，不能仅凭“持有令牌”就授予访问权。
3. **对日志和标准输出进行秘密脱敏。**凡是进入代理上下文的信息，都应被视为可能被模型或用户恢复。
4. **同时扫描代码、配置、提示词和依赖项中的秘密。**代理技能的风险表明，自然语言指令与可执行代码必须联合审查。
5. **测试网络流量和后端授权。**确认被截获的请求无法重放，也无法通过未认证代理转发。
6. **立即轮换暴露的凭证，并检查派生仓库和复制版本。**从原始仓库删除秘密，并不等于所有分发版本都已清理。
7. **在发布前加入平台级审核。**市场平台筛查、开发者安全指引、负责任披露和自动化检查，应与开发者自身的安全意识相互补充。34

核心结论很直接：AI安全不能等到产品上线后再补救。凭证、代理权限、模型上下文和计费控制，都应从项目启动之初就被视为产品安全的核心组成部分。