Codex 如何安全连接 Azure
如果我想让 Codex 接入 Azure，应该先检查哪些安全设置，才能尽量避免账号、密钥或资源暴露？
连接前的安全准备
建议先确认 Azure 账号已启用多因素认证，并为 Codex 单独创建最小权限的服务主体或托管身份。不要直接使用个人管理员账号，也不要把订阅级权限开放给不必要的任务。密钥、连接字符串、证书应存放在 Azure Key Vault 或等效的密钥管理服务中，避免写进代码库、日志或配置文件。还需要检查网络访问控制、资源组权限边界和审计日志是否开启，以便在出现异常时能够追踪操作来源。
Codex 在 Azure 上执行任务时，怎样设置权限才能让它只接触必要的资源，而不是访问整个订阅？
用最小权限控制访问范围
可以为 Codex 分配专用角色，并按资源组、单个资源或特定 API 范围授权，而不是直接给高权限角色。若任务只需要读取某个存储账户，就不要赋予写入或删除权限。对临时任务可以使用短期凭据或时限更短的访问令牌，任务结束后立即回收。配合条件访问、资源锁和私有网络访问策略，可以进一步减少误操作和越权风险。
如果 Codex 需要调用 Azure 服务，应该怎样保存和传递密钥，才不容易在代码、命令记录或输出中泄露？
安全管理密钥和令牌
不要把密钥硬编码到脚本、仓库或示例配置里。更安全的做法是通过 Azure Key Vault、环境变量注入或托管身份来获取访问凭据，并限制这些凭据只在运行时可见。日志中要屏蔽敏感字段，CI/CD 流水线也应启用 secret masking。对于可轮换的凭据，建议定期更换并监控异常调用，减少单个泄露点带来的影响。
当 Codex 对 Azure 资源进行读写或部署时，我怎样知道它做过哪些操作，出问题后如何回溯？
开启审计与监控能力
可以在 Azure 中开启活动日志、资源日志和安全中心相关监控，记录 Codex 发起的操作、时间、来源和结果。给每个自动化任务设置独立身份，便于在日志中区分不同工作流。配合告警规则，可以在异常访问、权限变更或资源删除时及时收到通知。若需要更强的可追溯性，还可以把日志集中到 SIEM 或日志分析工作区，方便统一检索和审计。