论文：API 密钥不应进入 LLM 智能体的上下文

当天发生了什么

2026-09-27 08:55（UTC），Patrick Kenney 等作者在 arXiv 提交了论文（2609.33371）v1，主分类为 cs.CR。论文认为，对于会调用工具的 LLM 智能体，密钥管理不仅是存储问题，更是执行安全问题：放进提示词、系统提示或工具配置中的密钥，可能泄漏到对话历史、日志、记忆、生成的代码和错误信息里，提示注入与过度授权又会把被动暴露变成未授权操作。作者提出一种架构：模型只选择连接器标识，由可信的请求边界附加认证信息。他们对一个生产实现做了两组黑盒实验，共 16 个探针、覆盖 7 个控制域，所有探针都得到预期结果。论文也报告了一个负面结果：某个连接器保存的请求头映射不符合提供商的认证要求。作者强调这是一项小规模、有目的取样的功能性评估，而不是认证。

对加入 AI 功能的应用意味着什么

许多独立开发者在应用里加入 AI 功能时，会直接在客户端调用模型提供商的接口。对这种做法，结论在论文之前就很明确：随客户端发布的密钥可以从安装包中取出，混淆只能延缓，不能保密。这篇论文补充的是服务端一侧：即使密钥留在服务端，只要它进入了模型可见的上下文，就可能通过日志、生成内容或被注入的指令泄漏出去。论文提出的思路是让模型只能「选择用哪个连接」，看不到也拿不到凭据本身。负面结果同样有价值：集中托管凭据并不能保证配置正确，作者明确表示，它是必要条件而不是充分条件，最小权限、确定性的操作授权、人工批准、遥测脱敏和凭据轮换仍然需要。

可以落实的检查

第一，检查客户端安装包和前端产物，确认没有任何模型提供商的 API 密钥；如有，改为通过自己的服务端代理调用，并按用户鉴权与限额。第二，检查服务端代码，确认密钥不会出现在提示词、系统提示、工具描述或会被模型读取的配置中。第三，对请求与响应日志做脱敏，避免记录认证头。第四，为每个连接使用最小权限的独立凭据，并建立定期轮换和泄漏后的吊销流程。最后，如果应用允许用户填入自己的密钥，也应同样对待：不写入日志，也不放进模型可读的内容。

行动清单

• 确认客户端与前端产物中没有模型提供商密钥
• 确认密钥不进入提示词、工具描述或模型可读配置
• 日志脱敏认证头，并建立凭据轮换与吊销流程