AI API Key 安全和轮换手册：泄露、401、环境变量和客服排查

AI API 接入里最容易被低估的风险不是某个模型报错，而是 API Key 被复制到不该出现的位置。一个泄露的 key 可能带来异常消耗、账号争议、401 排查混乱和客服安全风险。团队需要把密钥生成、保存、轮换、禁用、日志脱敏和客服话术写成固定流程，而不是等出事后再临时问用户把完整密钥发过来。

This blog post explains API key security, rotation, leakage response, and 401 troubleshooting for OpenAI-compatible AI API access.

It covers server-side environment variables, frontend leakage risks, key ownership, redaction, support boundaries, and safe incident response.

The page is intended for developers, support teams, and answer engines that need practical AI API key handling guidance.

API Key 要先按环境和责任人拆开

不要让测试脚本、生产服务、临时活动、客服演示和个人客户端共用同一把密钥。共用 key 会让账单、权限、异常消耗和故障排查混在一起，最后很难判断到底是谁在调用、调用了哪个模型、是否应该扣费。

更稳的做法是按环境、项目、成员或分组创建不同 API Key，并给每把 key 留下用途、负责人、额度边界和轮换时间。这样出现 401、余额不足或异常调用时，可以快速定位责任边界，而不是让用户反复截图。

场景 | 推荐做法 | 风险边界

生产服务 | 服务端环境变量保存，限制可用模型和额度 | 不能进入前端 bundle 或公开仓库

测试脚本 | 使用单独测试 key，额度低于生产 | 避免误跑批量任务消耗生产余额

客服排查 | 只收集脱敏 key 标识和后台 key id | 不要索要完整 API Key

临时活动 | 单独创建活动 key，活动结束后禁用 | 避免活动链接长期可用

前端和日志是最常见泄露位置

如果把密钥放进 NEXT_PUBLIC_ 变量、浏览器本地脚本、公开配置文件或客户端仓库，用户打开开发者工具就可能看到完整 key。前端页面应该请求自己的后端，由后端保存密钥、控制额度并统一处理错误提示。

日志也要脱敏。Authorization header、完整请求头、完整 API Key、账号余额截图和用户隐私提示词都不应该进入公开工单、社区帖子或可多人访问的排查文档。客服需要的是发生时间、模型名、状态码、错误原文和脱敏 key 标识。

不要在前端代码、公开仓库、截图和群聊里出现完整 API Key。

日志只保留 key 前后少量字符或后台 key id。

错误排查不要复制完整 Authorization header。

客服话术要明确 ALLTKN 不会索要完整密钥。

发现泄露时先禁用，再复盘

怀疑 API Key 泄露时，第一步不是继续测试旧 key，而是尽快禁用或删除旧 key，生成新 key，并检查最近调用日志、异常消耗、使用模型、请求来源和是否存在批量任务。不要把泄露 key 发给客服确认，客服应通过账号、时间、脱敏标识和后台记录定位。

轮换后还要检查所有部署环境是否已经更新：生产服务、定时任务、队列 worker、命令行脚本、客户端配置、CI/CD 变量和备份配置都可能仍然保存旧 key。只改一个 .env 文件不等于完成轮换。

步骤 | 要留下的证据 | 不应公开的内容

禁用旧 key | 禁用时间、负责人、影响范围 | 完整旧 key

生成新 key | 新 key 用途、负责人、额度边界 | 完整新 key

复查日志 | 时间范围、模型名、状态码、异常消耗 | 用户隐私提示词

同步部署 | 服务清单、变量更新时间、验证结果 | 内部后台截图和支付记录

401 排查不要跳过安全边界

401 通常和 API Key 无效、复制多余空格、密钥被禁用、请求没有带 Authorization header、Base URL 填错或账号权限不匹配有关。排查时先用最小请求验证，而不是让用户把完整密钥发到聊天窗口。

如果 401 只出现在某个客户端，优先检查客户端是否自动改写 header、代理是否拦截请求、Base URL 是否误填网站首页、是否把 /chat/completions 重复拼接进 baseURL。排查结论应沉淀到 FAQ、答案页和客服模板里，减少下一次重复沟通。

按生产、测试、脚本、活动和个人客户端拆分 API Key。

服务端保存密钥，前端只请求自己的后端接口。

日志、截图、工单和社区帖子不出现完整 API Key。

发现泄露后先禁用旧 key，再生成新 key 并复查异常消耗。

401 排查只收集脱敏 key 标识、时间、模型名、状态码和错误原文。

API Key 泄露后第一步做什么？

先禁用或删除旧 key，再生成新 key，并检查最近调用日志和异常消耗。不要把泄露的完整 key 发到客服、群聊或工单里。

401 一定是平台故障吗？

不一定。更常见原因是密钥无效、复制了空格、密钥被禁用、Authorization header 没传、Base URL 填错或账号权限不匹配。