使用 Codex 时如何保护 API Key、密码与生产配置

AI 编程工具可以读取用户授权范围内的文件和上下文，因此敏感信息保护必须从任务开始前做起。最安全的密钥不是“告诉工具不要泄露”，而是根本不把不必要的密钥放进可访问范围。

## 哪些内容属于敏感信息

- API Key、访问令牌、Session Token 和 Cookie。 - 数据库密码、SSH 私钥和云平台凭据。 - 支付信息、客户个人数据和内部业务数据。 - 生产环境地址、备份文件和未公开漏洞细节。 - 可以绕过登录或重置账号的一次性链接。

验证码和密钥即使只使用一次，也不应发送到公开对话或第三方客服。

## 从文件结构开始隔离

把真实凭据保存在受控的密钥系统或本地环境变量中，仓库只保留示例变量名。使用 .gitignore 可以降低误提交风险，但它不能阻止已存在文件被读取，也不能替代操作系统权限。

运行 Codex 前检查工作目录，避免把整个用户目录、下载目录或备份目录作为项目根目录。只授权任务需要的仓库和子目录。

## 提示中不要粘贴真实密钥

排查认证问题时，通常只需要变量名、错误类型、权限范围和密钥前后少量脱敏字符。用 EXAMPLE_KEY 或已撤销的测试值复现格式问题。任何要求提供完整密码、验证码、Cookie 或 Token 的第三方，都应被视为高风险。

## 检查输出与日志

命令输出、构建日志、截图和错误堆栈也可能包含密钥。分享前搜索常见变量名并脱敏。代理生成的调试代码如果打印请求头或完整环境变量，必须在提交前删除。

## 发现泄露后的处理

1. 立即撤销或轮换受影响的凭据。 2. 检查访问日志和异常操作。 3. 从当前文件和后续提交中移除敏感值。 4. 评估历史提交、构建缓存和聊天记录中的副本。 5. 记录事件原因并改进扫描与权限策略。

仅删除当前文件并不能让已经暴露的密钥重新安全，轮换才是关键。

## 团队最低标准

为开发、测试和生产使用不同凭据；限制每个凭据的权限和有效期；在提交与发布流程加入密钥扫描；明确谁可以批准生产访问。使用 Codex 时坚持最小上下文和最小权限，可以显著降低误传与误执行风险。