让密钥留在边界里：接入 AI API 的准备清单

把 API 密钥粘进工具设置框很容易，难的是知道它随后会存在哪里、由谁读取、出错时会不会进入日志。接入之前先明确调用路径和权限范围，比发生异常后再搜索泄露位置更省事。密钥是可使用服务权限的凭据，不应被当作普通配置文字。

先确认谁实际发起请求

区分浏览器、你自己的后端服务、本地软件和第三方转发平台。不同路径决定谁能够接触密钥。公开网页中的前端代码无法安全隐藏需要保密的凭据，不能因为变量名叫 secret 就认为用户看不到。若工具要求你交出密钥，应先确认其来源与数据处理方式。

如果平台支持项目、权限或用途划分，按实际需要设置，避免把同一把高权限密钥用于所有设备与脚本。额度提醒、预算限制和硬性停止能力也要分别核对，不能把收到提醒理解为一定不会继续产生费用。具体功能随平台与服务类型而变，应以当前控制台及说明为准。

本地环境变量、受控的秘密管理功能或工具提供的凭据存储可以帮助避免直接写进源码，但每种方式仍有自己的访问边界。检查配置文件是否被版本管理跟踪，示例文件只放字段名和说明。不要将真实密钥复制到问题反馈、聊天截图或公开文档中，即使只是暂时测试。

请求头、完整 URL 和调试输出可能带出敏感字段。正常日志应只保留必要的时间、错误类别和请求标识，不把所有输入与响应默认记录下来。向支持人员提供信息时，先检查脱敏效果；把末尾几位打码并不能保证其他位置没有同一凭据的副本。

删除帖子、文件或提交记录不能使已复制的凭据失效。通过服务的正式控制台撤销或轮换，再更新仍需要使用它的应用，并检查旧凭据是否确实失效。随后核对调用与费用记录，记录异常时间范围。不要等待找到全部副本才开始控制旧密钥的权限。

清理不再使用的凭据，核对拥有访问权限的人和工具，确认恢复与轮换步骤可执行。对于自动任务，更新密钥后要验证实际调用成功，避免只修改配置却没有重启或重新加载。若属于组织账户，遵循既定管理流程，不在个人设备上另建难以追踪的共享副本。