使用 AI 编程工具时，如何避免密钥泄漏

一、密钥为什么会泄漏

我们经常不注意把以下内容让 AI 访问：

• .env、YAML 等配置文件
• 写有测试密钥的代码

例如：

OPENAI_API_KEY=sk-example-secret
Authorization: Bearer github_pat_example
DATABASE_URL=postgres://admin:password@db.internal/app

这些信息可能在开发者没有察觉的情况下进入 AI 请求。

二、在网关层自动替换密钥

通过私有部署 new-api 来使用 AI 服务，不过它只提供来敏感词阻隔，没有敏感词替换功能，作者是通过 clone 源代码后自行实现的。可以在请求转发给上游模型前，将命中的内容替换为安全占位符。

规则示例：

sk-example-secret=>[OPENAI_API_KEY]
github_pat_example=>[GITHUB_TOKEN]
db.internal=>[INTERNAL_DATABASE]

替换前：

请检查 Authorization: Bearer sk-example-secret 为什么无效。

替换后：

请检查 Authorization: Bearer [OPENAI_API_KEY] 为什么无效。

模型仍能理解问题，但无法看到真实密钥。如果没有指定替换值，系统会默认替换为 XX。

三、统一网关的优势

将替换功能放在 AI API 网关层，可以覆盖编辑器插件、命令行工具和内部应用等不同入口。

该功能可以处理 OpenAI、Claude、Gemini、Embedding、Rerank、图片生成和音频请求中的文本字段，也支持 JSON、表单和 multipart 请求。

相比依赖开发者手动检查，统一网关能够执行一致的安全策略：

AI 编程工具 → new-api → 敏感词替换 → 上游模型

四、审计与日志安全

系统可以记录命中时间、用户、令牌、模型、请求路径、替换次数以及有限的上下文，帮助管理员定位高风险使用方式。

由于审计内容本身可能包含密钥，相关字段应加密存储、限制管理员访问，并设置合理的保留期限。过期记录可以通过定时任务或手动任务分批清理。

如果日志中出现真实密钥，管理员不应只确认其已被替换，还应调查来源，并根据风险及时撤销或轮换密钥。

五、不应只依赖敏感词替换

敏感词替换只能识别已经配置的内容，无法保证发现未知、拆分、编码或隐藏在文件与图片中的密钥。

完整的防泄漏方案还应包括：

• 使用环境变量或密钥管理服务
• 禁止在代码中硬编码密钥
• 在 Git 和 CI 中执行密钥扫描
• 遵循最小权限原则
• 定期轮换和撤销凭据
• 限制 AI 工具可读取的文件范围

结语

AI 编程提高了开发效率，也让敏感数据更容易离开本地环境。通过网关层在请求出站前自动替换密钥，可以降低人为疏忽带来的泄漏风险。

敏感词替换应作为密钥管理、权限控制、代码扫描和定期轮换之外的最后一道出站防线。

注意：这不能解决 在2026年6月爆出的 Claude code 的安全隐患。