核心判断：Agent 安全不能只靠提示词。真正能约束风险的是系统边界——它能写哪里、能访问哪些网络、用什么身份、何时停下来问人，以及事后能否还原完整操作链。
为什么“让模型谨慎一点”不够
传统聊天模型答错，主要损失是信息质量；能够运行命令、修改代码和调用外部工具的 Agent 答错，可能直接改变真实系统。风险已经从“说了什么”变成“做了什么”。
OpenAI 在公开的 Codex 安全实践中，把控制面拆成四组：受管理的配置、受约束的执行、网络策略和 Agent 原生日志。这套划分的价值不只适用于编码工具，也适用于运维、数据分析和企业流程 Agent。
第一层：沙箱定义硬边界
沙箱解决的是“即使模型判断错了，它最多能影响什么”。常见边界包括：
- 允许读取的目录；
- 允许写入的工作区；
- 受保护的配置和凭据；
- 默认是否允许访问网络；
- 子进程是否继承相同限制。
关键点在于，限制必须由操作系统或执行环境强制实施，而不是依靠模型自觉遵守。OpenAI 对 Windows 沙箱的工程复盘说明了这个难题：编码 Agent 需要同时驱动 shell、Git、Python、包管理器和构建工具，普通应用沙箱往往太窄，完全访问又太危险。
Windows 方案最终需要在文件 ACL、受限令牌和防火墙之间建立专门的执行边界。这个案例说明，沙箱不是一个开关，而是一组与操作系统深度绑定的工程能力。
第二层：审批处理必要的越界
把所有操作都弹窗审批，Agent 会退化成一台需要不断确认的遥控器；完全不审批，又会把高风险动作混进日常流程。
更合理的做法是让沙箱与审批配合：
- 边界内的低风险动作自动执行；
- 需要访问工作区外文件或陌生网络时请求授权；
- 删除、发布、付款、修改生产配置等动作强制人工确认；
- 明确禁止的动作不提供绕过入口。
审批不是安全边界本身。它是经过风险分类后的例外通道，不能替代沙箱。
第三层：网络访问采用默认收敛
Agent 能读本地资料又能任意联网，就具备了数据外传通道。稳妥的网络策略应该默认收敛，而不是默认全开：
- 已知业务域名进入允许列表；
- 明确危险的目的地直接阻断；
- 陌生域名触发审批；
- 内网、云元数据地址和凭据服务单独保护；
- 网络规则与具体身份、任务和会话关联。
仅通过代理环境变量“劝阻”程序联网并不可靠。程序可以忽略代理变量或直接建立套接字，因此生产环境需要由防火墙、代理或运行时边界强制执行。
第四层：身份与凭据不交给上下文
密钥不应该以明文进入提示词或日志。Agent 使用 CLI、MCP 和第三方服务时，需要把凭据保存在安全存储中，并让访问行为绑定到企业工作区和具体身份。
这样才能回答三个问题：是谁授权的、Agent 代表谁行动、权限何时失效。长期共享的万能密钥无法提供这些答案。
第五层：审计必须记录“为什么”
传统系统日志能告诉你某个进程启动、文件被修改、网络连接被尝试，却不一定能解释这次动作来自哪个用户目标，以及 Agent 为什么选择它。
Agent 审计至少应记录：
- 用户请求与任务标识；
- 工具调用和参数；
- 审批决定；
- 执行结果；
- MCP 服务使用；
- 网络允许与拒绝事件；
- 人工接管和回滚动作。
这些数据既用于安全调查，也能反向发现权限过宽、频繁误拦和工作流设计问题。
从 M0 开始上线
对运维、工业和企业系统，建议按风险逐级开放：
- M0 只读诊断：查询日志、配置和状态，不修改系统；
- M1 低风险自动化：限定工作区内生成文件、运行测试和整理报告；
- M2 受控变更：Agent 生成方案，人类审批后由受限工具执行；
- M3 有界自治：只在经过评测、可回滚且持续监控的窄场景中自动变更。
升级条件不应是“模型看起来更聪明了”，而应是任务通过率、越权率、误审批率、回滚成功率和审计完整性达到明确门槛。
结论
一套可上线的 Agent 安全架构，需要同时具备硬边界、例外审批、网络控制、短期身份和可追溯日志。少任何一层，风险都可能从回答错误升级为真实系统事故。
参考资料与延伸阅读
- Running Codex safely at OpenAI
- Building a safe, effective sandbox to enable Codex on Windows
- Codex sandboxing documentation
资料核验日期：2026-08-23。