推荐配置

适用于网络安全工作流的安全控制取决于模型、模型可以执行的操作、模型可以访问的系统，以及所涉及数据的敏感程度。

对于大多数 Daybreak Blue 工作流，组织现有的安全实践（例如访问控制、凭据保护以及敏感操作审查）可能已经足够。

Daybreak Red 工作流、自主安全测试，以及涉及生产系统、敏感数据或外部工具的活动，可能需要更强的防护措施。以下建议主要面向这些风险较高的场景。

Trusted Access 管理获批准的模型访问，但不会配置你的环境，也不会对获批准的系统和操作强制实施限制。你的团队必须设置适当的隔离、权限、审查、监控和人工监督控制。应假设模型、其工具及每个已连接系统都可能遭到入侵，然后配置环境，确保即使发生这种情况，它们仍无法访问未经授权的系统、泄露凭据、停用防护措施，或在工作结束后保持驻留。

隔离环境

在专用实验室或沙箱中开展攻击性安全工作。初始环境不应具备不受限制的互联网访问权限，也不应能够访问敏感的生产系统、企业网络、无关工作负载或主机管理界面。除非获批准的工作明确要求并授权使用，否则应确保机密、凭据、持久访问权限和持久性系统变更无法触及。

对于风险较高或防护措施有所减少的工作，每次尝试都应使用全新且高度隔离的环境。分别隔离计算、存储、网络和身份，并在工作结束后销毁环境，而不是重置或重复使用。

开始风险较高的工作前，应测试文件系统和网络边界。测试范围应包括每台可访问的主机、每个已连接工具、受委派的智能体和下游服务。即使模型或审查者批准了某项操作，也应继续隔离主机环境。

定义并强制实施获批准的边界

模型开始工作前，应记录获准用于此项工作的系统、工具、操作和时间限制。包括：

• 获批准的目标系统、主机和环境。
• 排除的系统，包括生产系统和无关基础设施。
• 获批准的工具和已连接服务。
• 获批准和禁止的操作。
• 获批准的开始和结束时间，以及数据处理要求。
• 漏洞披露、补丁批准和维护者协调流程。
• 停止条件以及需要明确人工批准的操作。

将这些获批准的边界作为任务上下文提供给智能体。仅记录这些边界并不能强制实施它们：应采用独立的文件系统、网络、身份和工具控制，在可行情况下使未经授权的操作无法执行。

使用 Codex 权限配置文件创建最小权限边界。任务不需要进行更改时，选择 :read-only；工作需要编辑工作区时，则扩展 :workspace。例如：

approval_policy = "on-request"
approvals_reviewer = "auto_review"
default_permissions = "cyber-lab"

[features]
network_proxy = true

[permissions.cyber-lab]
description = "Limit security testing to the approved lab and workspace."
extends = ":workspace"

[permissions.cyber-lab.filesystem]
glob_scan_max_depth = 3

[permissions.cyber-lab.filesystem.":workspace_roots"]
"**/.env*" = "deny"
"**/*.pem" = "deny"

[permissions.cyber-lab.network]
enabled = true
# Uncomment only for an approved host that resolves to a private address.
# allow_local_binding = true

[permissions.cyber-lab.network.domains]
"lab.example.com" = "allow"

network_proxy 功能会强制限定获批准的域。如果没有此功能， network.enabled = true 会允许直接访问网络，且实验室允许列表 不会限制目标位置。Web 搜索、应用、连接器、MCP 服务器、 浏览器活动和 Codex 云端分别使用不同的控制；应限制或关闭 获批准工作流不需要的每个入口。

将 lab.example.com 替换为获批准的目标。限定范围的文件系统扫描旨在避免搜索 Linux、WSL 和 Windows 上的整个工作区；如果敏感文件位于更深层级，请增加深度或使用精确的拒绝路径。不要将权限配置文件与旧版 sandbox_mode 设置结合使用；请遵循权限配置文件配置指南。

如果获批准的实验室主机解析为私有地址，即使该主机位于允许列表中，Codex 默认仍会阻止它。仅针对明确获批准的私有网络工作设置 allow_local_binding = true，保持较窄的目标允许列表，并查看本地和私有网络指南。你也可以将获批准的确切私有 IP 地址加入允许列表。

默认阻止访问开放互联网和生产网络。如果必须访问外部资源，请通过独立强制实施的网关或代理进行路由，并采用严格的允许列表、请求检查和日志记录。对于通过软件包管理器、Webhook、URL 获取服务、重定向、云 API 和已连接工具建立的间接连接，也应实施相同限制。在运行前加载依赖项，或使用管理员批准的依赖项。

保护凭据和敏感数据

不要在提示、存储库、环境变量、共享文件系统和模型可访问的日志中存放可重复使用的 API key、云凭据、密码和服务账号令牌。需要身份验证时，应使用独立的代理程序或网关，提供仅限确切目标和获准操作的短期凭据，且不向模型暴露该凭据。

仅提供获批准任务所需的数据。移除不必要的敏感信息，阻止访问云元数据和凭据端点，并将模型生成的文件视为不可信内容。

在网络安全工作流中，应避免使用 :danger-full-access 和 --yolo。Full Access 会移除自动审查赖以实施的沙箱边界。托管组织可以排除 :danger-full-access 和 --yolo、限制允许使用的批准策略，并通过企业托管配置要求进行自动审查。

为获批准的安全模型启用 Full Access 前，ChatGPT 桌面应用会显示针对该模型的危险操作警告。该警告会建议改用 Approve for me，并链接到审查者策略配置。此警告不会恢复沙箱边界，也不会覆盖组织策略。

防护规则可为受控的网络安全工作流添加基于策略的审查。它们无法取代环境隔离、最小权限、明确定义的边界、监控或人工监督。

审查 Codex 的敏感操作

自动审查会在拟议操作运行前，将符合条件的沙箱边界批准请求转交给独立的审查者。审查者会考虑拟议操作、限定范围的任务上下文和适用策略，然后允许或拒绝请求。组织可以根据获批准的目标、禁止的操作以及必须人工审查的条件，自定义该策略。

对于影响生产环境、外部系统、敏感数据、权限提升、持久访问或不可逆更改的操作，应要求明确的人工批准。将网站、存储库、文档和工具输出中嵌入的指令视为不可信内容；这些指令无法扩大授权范围或覆盖访问控制。

在 ChatGPT 桌面应用中选择获批准的 Daybreak 模型时，如果你的账号可以使用 Approve for me 模式且组织策略允许，权限控件会自动切换到该模式。使用桌面应用的 /model 命令时也是如此。如果该模式不可用，当前权限模式将保持不变。模型选择绝不会覆盖托管组织的要求。

要运行自动审查，请确保以下三项控制均已启用：

1. 使用交互式批准策略，例如 approval_policy = "on-request"。
2. 设置 approvals_reviewer = "auto_review"。
3. 保留可强制实施的沙箱或权限配置文件边界。

对网络允许列表中目标的请求会保持在网络边界内，不会自动触发自动审查。即使目标位于允许列表中，如需审查敏感命令，请在 ~/.codex/rules/ 下创建明确的命令规则：

prefix_rule(
    pattern = ["curl"],
    decision = "prompt",
    justification = "Review requests to the approved cybersecurity target.",
)

添加规则后，重启 Codex。使用 approvals_reviewer = "auto_review" 时，匹配的命令会在执行前转交给审查者。为每条敏感命令添加对应的提示规则，或对单独的 MCP 工具使用 approval_mode = "prompt"。需要由人员做出决定的操作仍须获得明确的人工批准。

自动审查不会检查沙箱内已获准执行的常规操作。使用 approval_policy = "never" 或 Full Access 时，敏感操作可能不会产生可审查的批准请求。自动审查可能出错，且无法取代隔离、明确定义的边界、监控或明确的人工监督。

有关限定范围的策略和组织范围内的强制实施，请参阅配置获授权的网络安全工作流。

独立监控并采用故障关闭机制

记录模型请求、工具调用、网络活动、凭据使用情况以及与安全相关的更改。将日志和监控系统置于模型控制的环境之外。针对未经授权的目标、意外网络请求、凭据暴露、策略更改、日志缺失以及绕过防护措施的尝试发出警报。

确保策略实施机制、凭据代理程序、审查系统和紧急关闭控件独立于智能体。如果关键控制或监控系统发生故障，应停止工作流。

为自定义智能体工作流添加防护规则

如果使用 Responses API、Agents SDK 或其他运行框架进行构建，请在工具执行边界添加审查。执行前，应根据获批准的系统、操作和时间限制检查拟议的敏感操作；将含糊或高风险的操作转交给人员；强制实施独立的文件系统和网络限制；保留审计日志；如果审查者或策略不可用，则采用故障关闭机制。

Codex 自动审查不会自动保护自定义工具或外部运行框架。请参考 Agents SDK 模式的防护规则与人工审查，并将开源审查者策略作为参考。

Codex 产品端的沙箱和审查独立于 API 网络安全检查。API 防护措施可能会返回 cyber_policy 错误，而按用户设置的 safety_identifier 值有助于限制防护操作的影响。

清理并验证结果

工作结束后，撤销临时凭据、终止后台进程、移除持久访问权限，并销毁风险较高的环境。验证是否仍存在回调、暴露的工件、共享状态或跨运行访问，并隔离不同的用户、会话和评估。

在根据发现采取行动前进行验证，遵循协同披露实践，并确保由人员对修复和更改负责。

开始之前

确认获批准的系统和操作、适当的模型、隔离环境、最小权限、受限的网络访问、受保护的凭据、操作审查、独立监控、紧急停止机制和清理计划。模型防护措施、隔离、限定范围的权限、操作审查、监控和人工监督相辅相成；不应将其中任何一项作为唯一的控制措施。