AI API Key 怎么安全使用和监控用量？
简答：AI API Key 的安全用法可以归纳为四步：密钥只放在后端或受控运行环境，通过环境变量或 Secret Manager 注入；按应用、环境和团队成员拆分密钥并限制权限；持续查看请求量、Token、费用、模型、来源和错误率；发现异常后先撤销或轮换密钥，再更新部署并审计日志。不要把 Key 写进前端代码、Git 仓库、URL、日志、截图或聊天记录。
定义：AI API Key 是用于证明调用者身份并授权访问模型接口的凭据，泄露后可能被他人用于消耗配额、产生费用或访问关联资源。
先做这张安全与监控速查表
本站为第三方指南，非相关服务官方，具体控制台名称、权限和限制以各平台官网为准。下面的顺序适合刚开始调用 OpenAI、Gemini 或 Claude API 的个人开发者和小团队。
| 环节 | 推荐做法 | 不要这样做 |
|---|---|---|
| 存储 | 使用环境变量、CI/CD Secret 或云端 Secret Manager | 把明文 Key 写进源代码、配置文件或笔记 |
| 调用位置 | 由后端服务器或受控工作负载发起请求 | 把长期 Key 放进浏览器、移动端或桌面客户端 |
| 权限 | 按应用、环境、团队成员拆分，使用最小权限和来源限制 | 多人共用一个无法追责的高权限 Key |
| 监控 | 查看请求量、Token、费用、模型、来源、错误率和时间分布 | 只看余额，不看调用日志和异常来源 |
| 止损 | 配置可执行的支出、速率或配额限制，并准备轮换流程 | 只设置提醒，却没有实际阻断措施 |
OpenAI 明确建议使用独立密钥、到期时间、环境变量、密钥管理服务、用量监控和 IP 允许列表；Google Cloud 也建议给 API Key 添加限制、删除闲置密钥，并避免通过 URL 查询参数传递密钥。可分别参考 OpenAI API 密钥安全最佳实践 和 Google Cloud API Key 管理建议。
不同运行环境应该把 Key 放在哪里
个人脚本和本地开发
本地脚本可以使用环境变量或未提交到仓库的 .env 文件。将 .env 加入 .gitignore，并在提交前检查差异和提交历史。环境变量只对当前 shell 或当前会话是否生效，取决于你的设置方式；修改后应重新打开终端或重新加载配置。
export AI_API_KEY='你的密钥'验证时不要把完整密钥打印到终端、日志或截图中，只检查变量是否存在。例如可以判断变量长度，或仅输出“已设置/未设置”。如果使用 Bash，可以用 read -s 读取临时密钥，避免输入内容回显。
后端服务和服务器
生产环境应通过部署平台的 Secret、云端密钥管理服务或等效机制注入 Key，而不是把它写入镜像、仓库或启动脚本。应用日志只记录请求 ID、模型、状态码和耗时等必要字段，禁止记录 Authorization 请求头、完整 URL 查询参数和完整请求体中的密钥。
前端、移动端和桌面客户端
不要在浏览器 JavaScript、移动端安装包或公开桌面客户端中放置长期有效的高权限 Key。用户可以通过开发者工具、反编译或网络抓包看到客户端中的凭据。更安全的结构是：客户端请求你的后端，由后端完成身份验证、权限判断、限流和模型调用。
CI/CD 和第三方工具
CI/CD 平台应使用加密 Secret，并限制哪些分支、工作流和环境可以读取它。第三方 IDE、自动化平台、代理服务或网关如果要求输入 Key，应先确认其权限范围、日志处理、删除方式和访问责任。Claude 官方也提醒，将 Key 提供给第三方工具意味着该工具可能接触你的 API 账户，因此应使用加密 Secret，而不是直接写进代码或配置文件，详见 Claude API Key 安全实践。
为什么 URL、日志、截图和聊天记录都不适合放 Key
API Key 本质上是 bearer credential：拿到它的人通常可以尝试以你的身份发起请求。把密钥放进 URL 查询参数尤其容易被代理、浏览器历史、访问日志和监控系统记录。Google Cloud 官方建议不要使用查询参数传递 API Key，而应使用专用请求头或客户端库，具体说明见 Google Cloud API Key 管理文档。
- 代码仓库：即使仓库后来删除了文件，提交历史、分支或缓存仍可能保留旧密钥，因此不能只删除当前文件。
- 日志：网关、反向代理、错误追踪和调试日志可能记录请求头、URL 或异常上下文。
- 截图和录屏：控制台、终端和配置文件中的密钥可能被同步到聊天、工单或公开文档。
- 聊天机器人和第三方工具：不要为了排错直接粘贴完整 Key；应先打码，只保留前后少量字符用于识别。
如果必须在排错中确认是否使用了正确密钥，可以比较密钥的别名、创建时间或掩码后的前后几位，不要传递完整凭据。
按应用、环境和人员拆分密钥
“一个项目一个 Key”比“所有地方共用一个 Key”更容易排查和止损。建议至少拆分为开发、测试、生产三个环境；如果有多个工具或服务，再按应用拆分。团队成员也应使用各自的 Key 或各自的身份，不要通过群聊、共享文档或环境文件传递同一把高权限密钥。
- 开发环境：低权限、低额度，允许快速撤销。
- 测试环境：使用独立项目或独立 Key，避免测试流量混入生产账单。
- 生产环境：只由后端服务读取，配合来源 IP、工作负载身份或 Secret Manager。
- 第三方接入：单独创建专用 Key，限制用途和额度，不要复用生产主密钥。
OpenAI 官方建议为团队成员使用唯一 API Key，并支持设置密钥到期日期、权限和 IP 允许列表；Google Cloud 则建议采用最小权限、密钥限制和短期凭据等方式减少泄露影响。
如何监控 AI API 用量和异常请求
用量监控不只是看余额。建议按小时或按天观察以下指标，并尽量按项目、Key、模型、环境和来源拆分：
- 请求量：单位时间内的请求数是否突然上升。
- Token：输入、输出和总 Token 是否与业务增长相符。
- 费用：实际消费与预算、配额或预期趋势是否一致。
- 模型：是否出现平时不会使用的高成本模型或异常模型切换。
- 来源：来源 IP、区域、用户代理或工作负载是否与部署环境一致。
- 错误率：401、403、429、5xx 和超时是否集中出现。
- 时间分布：非工作时段的连续调用是否符合定时任务或批处理计划。
单一异常不一定代表密钥泄露。例如发布新版本可能带来请求量增长，批处理也可能集中消耗 Token。因此应结合 Key、模型、来源和时间段交叉判断。对个人开发者，可以每天查看一次；对生产服务，可以设置请求量、费用、错误率和速率的阈值告警。
提醒和硬性限制不是一回事。OpenAI 文档说明，支出提醒本身不会停止 API 流量，硬性执行措施才可能阻止继续请求，但执行可能存在延迟并导致略微超出限额；Claude 官方也建议结合 Usage、Logs、支出限制和工作区速率限制。设置后应通过测试请求确认限制确实能够生效，而不是只在控制台显示。
发现 Key 泄露后的处理顺序
- 先控制风险：立即暂停受影响的服务、工作流或第三方连接；如果平台支持，先撤销、禁用或删除泄露的 Key。
- 创建替代凭据：生成权限更小、用途更单一的新 Key，或改用短期身份凭据。
- 更新部署：替换服务器、容器、CI/CD、密钥管理服务和本地配置中的旧值，并重启实际读取凭据的进程。
- 审计用量：检查泄露前后的请求量、费用、模型、来源 IP、时间分布和错误日志，保留必要证据。
- 清理暴露位置：从代码、文档、日志、截图和工单中移除明文凭据，同时检查 Git 历史和构建产物。
- 收紧限制：重新设置权限、来源 IP、速率、配额和支出限制，确认限制可以实际阻断请求。
- 建立轮换记录：记录密钥所有者、用途、创建时间、到期时间和最近一次轮换时间。
不要只把泄露的 Key 从前端代码或仓库当前版本中删除，因为旧提交、构建产物和日志可能仍然保留它。澳大利亚网络安全机构在截至 2026 年 9 月 29 日发布的 AI 服务建议中，也强调要维护凭据清单、监控凭据变更和异常活动，并在恢复服务前撤销受损凭据、保留日志和调查未授权访问，详见 AI 服务保护建议。
Gemini API Key 的日期变化需要注意什么
Google 的 Gemini 文档显示，Gemini API 支持标准 API Key 和授权 API Key，并正在从标准密钥转向授权密钥。自 2026 年 5 月 28 日起，Google AI Studio 新建的 API Key 默认使用授权密钥；文档同时说明，Gemini API 会拒绝不受限制的标准密钥请求，但添加明确限制的标准密钥仍可能正常使用。
截至 2026 年 10 月 23 日，如果你仍在使用较早创建的 Gemini 标准密钥，应登录 Google AI Studio 或 Google Cloud 控制台核查密钥类型、应用限制、关联项目和服务账号权限。不要仅因为请求目前还能成功，就认为配置已经符合生产环境安全要求。具体密钥类型和迁移要求以 Gemini API 密钥官方文档显示的最新状态为准。
个人开发者可以直接执行的 10 分钟检查清单
- 全局搜索项目代码，确认没有明文 Key、Authorization 头或带 Key 的 URL。
- 检查
.gitignore是否忽略.env、本地配置和导出的凭据文件。 - 查看 CI/CD、云部署和容器环境，确认 Key 来自 Secret 而不是 Dockerfile 或启动命令。
- 确认浏览器、移动端和公开客户端没有长期高权限 Key。
- 为开发、测试、生产和第三方工具分别使用不同 Key。
- 删除不再使用的密钥，记录每把密钥的用途和责任人。
- 设置可执行的速率、配额或支出限制，并用测试请求验证。
- 检查最近的请求量、Token、费用、模型和来源是否符合预期。
- 配置至少一种异常告警，例如费用突增、请求量突增或 401/429 比例异常。
- 准备一份轮换记录，确保泄露时能快速更新所有部署位置。
如果你正在为多个 AI 工具配置兼容接口，建议先为每个工具单独创建凭据和环境变量，再逐一验证调用，避免把同一个生产 Key 复制到多个客户端。
常见问题
API Key 放在 .env 文件里安全吗？
比直接写进代码更好，但不是自动安全。必须确保文件不提交到代码仓库、不上传到公开网盘、不打包进前端资源，并在生产环境优先使用平台 Secret 或密钥管理服务。若 .env 曾经提交过完整 Key，应立即轮换，而不是只删除文件。
只设置预算提醒，能防止 API Key 被盗刷吗？
不能保证。提醒通常只是通知，未必会阻止请求继续执行。应同时配置平台支持的硬性支出上限、配额、速率限制或来源限制，并通过测试确认它们能够实际拒绝超限请求。不同平台的控制台名称和生效方式可能不同，以官方文档为准。
前端应用必须直接调用模型 API，怎么办？
不要把长期有效的高权限 Key 放进前端。优先增加后端代理，由后端控制用户身份、请求范围、速率和费用。如果平台提供面向客户端的短期凭据或受限密钥，应按照官方方案设置最小权限、来源限制和过期时间，并明确其仍可能被终端用户看到。
发现 Key 出现在 Git 历史里，只删除提交可以吗？
不可以。只要密钥曾经暴露，就应先撤销或轮换，再清理仓库历史、构建产物、日志和缓存。随后检查用量、来源和费用，并为替代密钥设置更小权限和更严格限制。
监控用量时最少要看哪些指标？
最低限度应看请求量、输入和输出 Token、费用、模型、来源、错误率以及时间分布。个人脚本可以每天检查，生产服务应根据业务量设置周期性检查和异常告警。
常见问题
API Key 放在 .env 文件里安全吗？
比直接写进代码更好，但必须加入 .gitignore，不能上传到公开仓库、网盘或前端资源。生产环境优先使用 CI/CD Secret 或 Secret Manager；如果 .env 曾经提交过完整密钥，应立即轮换。
只设置预算提醒，能防止 API Key 被盗刷吗？
不能保证。提醒通常只是通知，不一定会停止请求。还应配置平台支持的硬性支出上限、配额、速率限制或来源限制，并通过测试确认限制能够实际生效。
前端应用必须直接调用模型 API，怎么办？
不要把长期有效的高权限 Key 放进前端。优先增加后端代理；如果平台提供短期凭据或受限密钥，应按官方方案配置最小权限、来源限制和过期时间。
发现 Key 出现在 Git 历史里，只删除提交可以吗？
不可以。应先撤销或轮换密钥，再清理 Git 历史、构建产物、日志和缓存，随后检查用量、来源和费用。
监控用量时最少要看哪些指标？
至少查看请求量、输入和输出 Token、费用、模型、来源、错误率和时间分布。个人脚本可以每天检查，生产服务应设置周期性检查和异常告警。
相关阅读
参考资料
- OpenAI：API 密钥安全最佳实践
- Google Cloud：Best practices for managing API keys（docs.cloud.google.com）
- Google AI for Developers：使用 Gemini API 密钥
- Claude Help Center：API key best practices（support.claude.com）
- CGA：Protect your organisations’ AI services（cyber.gov.au）