Coding Agent 正在从“帮开发者补代码”的工具，变成能直接进入工程环境的执行者。它可以读仓库、改文件、跑测试、调用命令行，甚至和 IDE、MCP 工具、内部服务一起工作。效率确实更高，但企业真正担心的也正在这里：一个能执行动作的 Agent，如果没有权限边界，就很难进入生产流程。

OpenAI 这次分享 Codex 的安全运行实践，重点不是展示它能写多少代码，而是说明企业应该怎样让 Coding Agent 在可控范围内工作。这个思路对开发团队很有参考价值：低风险动作尽量不打断，高风险动作必须停下来确认，所有关键行为都要能追踪。

最基础的一层是 sandbox，也就是给 Agent 划出明确的工作区。它能写哪些目录，哪些路径受保护，是否能访问网络，什么情况下算越界，都要提前定义。这样做不是为了限制 Agent 的价值，而是为了让它在安全范围内稳定发挥。比如改业务代码、跑单元测试可以放在常规流程里；但访问敏感目录、修改系统配置、执行破坏性命令，就不能默认放行。

有了 sandbox，还需要 approval。企业不会希望每一个小动作都人工审批，那样 Agent 反而拖慢开发；但也不能让它遇到高风险操作时自动通过。比较合理的做法是把动作分级：普通读写、测试命令可以自动执行；访问陌生域名、越过沙箱、运行危险命令时触发单次确认；明显危险的命令直接阻止。OpenAI 提到的 Auto-review mode，本质上也是为了减少低风险审批噪音，同时保留对关键动作的拦截。

网络访问是另一条必须单独治理的线。Coding Agent 很容易需要联网查文档、拉依赖、访问工具服务，但企业不能给它开放式外网权限。更稳的方式是 network policy：可信地址允许，明确不该访问的地址阻断，陌生域名进入审批，并记录 allow / deny 结果。这样既不影响常见开发任务，也避免 Agent 在不受控的网络环境里行动。

凭据管理同样重要。Agent 接入 CLI、MCP、IDE 或企业工作区时，经常会涉及 OAuth token、内部账号或服务权限。凭据如果散落在本地文件、脚本或环境变量里，风险会被放大。OpenAI 的做法是把凭据放进系统安全 keyring，并绑定企业工作区权限。对企业来说，关键不是“让 Agent 拿到 token”，而是让它的访问能力可撤销、可审计、可纳入统一权限体系。

最后是 telemetry。传统安全日志通常只能告诉安全团队“发生了什么”，比如某个进程启动、某个文件被修改、某个网络连接被尝试。但 Agent 场景还需要知道“为什么发生”：用户给了什么指令，Agent 为什么调用这个工具，审批如何通过，执行结果是什么。Codex 支持导出 OpenTelemetry 日志，也能进入 Compliance Logs，这让安全团队可以把 Agent 行为和用户意图、工具结果、网络策略放在一起分析。

所以，企业部署 Coding Agent 时，真正要回答的不是“模型够不够强”，而是这些问题：它能访问什么？哪些动作能自动做？哪些必须审批？网络怎么管？凭据怎么放？出问题后能不能还原链路？

Codex 的安全实践给出的方向很清楚：Coding Agent 要进入真实研发流程，必须先成为一个可控、可审计、可回滚的执行系统。只有权限边界和审计能力跟上，Agent 提效才不会变成新的工程风险。