サイバーセキュリティワークフローに適したセキュリティ制御は、使用するモデル、そのモデルが実行できるアクション、アクセス可能なシステム、関連データの機密性によって異なります。
ほとんどの Daybreak Blue ワークフローでは、アクセス制御、認証情報の保護、機密性の高いアクションのレビューなど、組織の既存のセキュリティ対策で十分な場合があります。
Daybreak Red ワークフロー、自律型セキュリティテスト、および本番システム、機密データ、外部ツールに関わるアクティビティには、より強力な安全対策が必要になる場合があります。以下の推奨事項は、主にこうしたリスクの高いシナリオを対象としています。
各ワークフローのリスクを評価し、適切なセキュリティ制御を実装する責任は利用者にあります。モデルの安全対策と Trusted Access は、組織独自のセキュリティ対策、監視、監督に代わるものではありません。
Trusted Access は承認済みモデルへのアクセスを管理しますが、環境を構成したり、アクセス先のシステムや実行するアクションを承認済みの範囲に制限したりはしません。チームは、適切な分離、権限、レビュー、監視、人間による監督の制御を設定する必要があります。モデル、そのツール、接続されているすべてのシステムが侵害される可能性を前提とし、侵害された場合でも、未承認のシステムへの到達、認証情報の漏えい、安全対策の無効化、作業終了後の残存ができないように環境を構成してください。
環境の分離
オフェンシブセキュリティ作業は、専用のラボまたはサンドボックスで実行します。開始時点では、インターネットへの無制限のアクセスや、機密性の高い本番システム、社内ネットワーク、無関係なワークロード、ホスト管理インターフェースへのアクセスを禁止します。承認済みの作業で明示的に必要とされ、許可されている場合を除き、シークレットや認証情報へのアクセス、永続的アクセスの確立、恒久的なシステム変更ができないようにします。
リスクの高い作業や安全対策を緩和した作業では、試行ごとに新しく用意した、強固に分離された環境を使用します。コンピューティング、ストレージ、ネットワーク、ID を分離し、環境はリセットや再利用をせず、作業後に破棄します。
リスクの高い作業を始める前に、ファイルシステムとネットワークの境界をテストします。到達可能なすべてのホスト、接続済みツール、委任先のエージェント、ダウンストリームサービスを対象に含めます。個別のアクションがモデルまたはレビュアーに承認された場合でも、ホスト環境の分離を維持します。
承認済みの境界の定義と適用
モデルの実行前に、その作業について承認済みのシステム、ツール、アクション、制限時間を文書化します。次の項目を含めます。
- 承認済みの対象システム、ホスト、環境
- 本番システムや無関係なインフラストラクチャを含む除外対象システム
- 承認済みのツールと接続済みサービス
- 許可されているアクションと禁止されているアクション
- 承認済みの開始時刻と終了時刻、およびデータの取り扱い要件
- 脆弱性の開示、パッチの承認、メンテナーとの調整
- 停止条件と、人間による明示的な承認が必要なアクション
これらの承認済みの境界をタスクのコンテキストとしてエージェントに渡します。文書化するだけでは境界を強制できません。実用上可能な限り未承認のアクションを実行できないよう、ファイルシステム、ネットワーク、ID、ツールに対して独立した制御を適用します。
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 によってネットワークへの直接アクセスが許可され、ラボの許可リストでは、
接続先を制限できません。ウェブ検索、アプリ、コネクタ、MCP サーバー、
ブラウザでの操作、Codex Cloud はそれぞれ別の仕組みで制御されます。
承認済みのワークフローに不要な機能は、それぞれ制限するか無効にしてください。
lab.example.com を承認済みの対象に置き換えます。このファイルシステムスキャンは探索範囲を限定し、Linux、WSL、Windows でワークスペース全体を検索しないように設計されています。機密ファイルがより深い階層にある場合は、探索深度を増やすか、完全一致する拒否パスを指定してください。権限プロファイルを従来の sandbox_mode 設定と併用せず、権限プロファイルの構成ガイダンスに従ってください。
承認済みのラボホストがプライベートアドレスに解決される場合、ホストが許可リストに含まれていても、Codex はデフォルトでブロックします。明示的に承認されたプライベートネットワーク上の作業に限って allow_local_binding = true を設定し、宛先の許可リストは必要最小限に保ち、ローカルネットワークとプライベートネットワークに関するガイダンスを確認してください。承認済みのプライベート IP アドレスそのものを許可リストに追加することもできます。
インターネットおよび本番ネットワークへのアクセスは、デフォルトでブロックします。外部アクセスが必要な場合は、必要最小限の許可リスト、リクエスト検査、ログ記録を備え、独立して制御されるゲートウェイまたはプロキシを経由させます。パッケージマネージャー、Webhook、URL 取得サービス、リダイレクト、クラウド API、接続済みツールを経由する間接的な接続にも、同じ制限を適用します。依存関係は実行前に読み込むか、管理者が承認したものを使用します。
認証情報と機密データの保護
再利用可能な API キー、クラウド認証情報、パスワード、サービスアカウントのトークンを、プロンプト、リポジトリ、環境変数、共有ファイルシステム、モデルがアクセス可能なログに含めないでください。認証が必要な場合は、別のブローカーまたはゲートウェイを使用し、認証情報自体をモデルに公開せずに、指定された対象と許可済みのアクションだけに限定した短期認証情報を提供します。
承認済みタスクに必要なデータだけを提供します。不要な機密情報を除去し、クラウドメタデータと認証情報エンドポイントへのアクセスをブロックし、モデルが生成したファイルを信頼できないものとして扱います。
サイバーセキュリティワークフローでは、:danger-full-access と --yolo を使用しないでください。フルアクセスにすると、自動レビューの前提となる強制可能なサンドボックス境界が失われます。管理対象の組織は、:danger-full-access と --yolo の除外、許可される承認ポリシーの制限、自動レビューの必須化を、エンタープライズの管理対象設定で行えます。
承認済みのセキュリティモデルで フルアクセス を有効にする前に、ChatGPT デスクトップアプリには危険なアクションに関するモデル固有の警告が表示されます。この警告では 代わりに承認 の使用が推奨され、レビューポリシーの構成へのリンクが表示されます。この警告によってサンドボックス境界が復元されたり、組織ポリシーが上書きされたりすることはありません。
ガードレールは、制御されたサイバーセキュリティワークフローに、ポリシーに基づくレビューを追加します。ただし、環境の分離、最小権限、明確に定義された境界、監視、人間による監督に代わるものではありません。
Codex の機密性の高いアクションのレビュー
自動レビューは、提案されたアクションの実行前に、サンドボックス境界を越える承認リクエストのうち対象となるものを別のレビュアーに送ります。レビュアーは、提案されたアクション、範囲を限定したタスクコンテキスト、適用されるポリシーを考慮し、リクエストを許可または拒否します。組織は、承認済みの対象、禁止アクション、人間によるレビューを必須とする条件に合わせて、このポリシーをカスタマイズできます。
本番環境、外部システム、機密データ、権限昇格、永続的アクセス、不可逆な変更に影響するアクションには、人間による明示的な承認を必須にします。ウェブサイト、リポジトリ、ドキュメント、ツール出力に埋め込まれた指示は信頼できないものとして扱います。こうした指示によって認可範囲を拡大したり、アクセス制御を上書きしたりすることはできません。
ChatGPT デスクトップアプリで承認済みの Daybreak モデルを選択すると、そのモードをアカウントで利用でき、組織ポリシーでも許可されている場合、権限コントロールが自動的に 代わりに承認 に切り替わります。デスクトップアプリの /model コマンドを使用した場合も同様です。そのモードを利用できない場合、現在の権限モードは変更されません。モデルを選択しても、管理対象組織の要件が上書きされることはありません。
承認リクエストの自動レビューを使用する場合は、次の 3 つの制御をすべて維持してください。
approval_policy = "on-request"など、対話型の承認ポリシーを使用します。approvals_reviewer = "auto_review"を設定します。- サンドボックスまたは権限プロファイルによる、強制可能な境界を維持します。
ネットワーク許可リスト上の対象へのリクエストはネットワーク境界内に収まるため、自動レビューが自動的に開始されることはありません。宛先が許可リストに含まれている場合でも機密性の高いコマンドをレビューするには、明示的なコマンドルールを ~/.codex/rules/ 配下に作成します。
prefix_rule(
pattern = ["curl"],
decision = "prompt",
justification = "Review requests to the approved cybersecurity target.",
)ルールを追加した後、Codex を再起動します。approvals_reviewer = "auto_review" を設定すると、一致するコマンドは実行前にレビュアーへ送られます。機密性の高いコマンドごとに対応するプロンプトルールを追加するか、approval_mode = "prompt" を個々のMCP ツールに適用します。人の判断が必要なアクションには、引き続き人間による明示的な承認が必要です。
自動レビューは、サンドボックス内ですでに許可されている通常のアクションを検査しません。approval_policy = "never" またはフルアクセスでは、機密性の高いアクションによってレビュー対象となる承認リクエストが生成されない可能性があります。自動レビューが誤った判断をする可能性もあり、分離、明確に定義された境界、監視、人間による明示的な監督に代わるものではありません。
対象範囲を限定したポリシーと組織全体への適用については、認可されたサイバーセキュリティワークフローの構成を参照してください。
独立した監視とフェイルクローズ
モデルへのリクエスト、ツール呼び出し、ネットワークアクティビティ、認証情報の使用、セキュリティに関係する変更を記録します。ログと監視システムは、モデルが制御する環境の外部に配置します。未承認の対象、予期しないネットワークリクエスト、認証情報の露出、ポリシーの変更、ログの欠落、安全対策を回避する試みを検出した場合は、アラートを発します。
ポリシー適用、認証情報ブローカー、レビューシステム、緊急停止制御をエージェントから独立させます。重要な制御または監視システムに障害が発生した場合は、ワークフローを停止します。
カスタムエージェントワークフローへのガードレールの追加
Responses API、Agents SDK、または別のハーネスを使用して構築する場合は、ツール実行の境界でレビューを追加します。提案された機密性の高いアクションを、実行前に承認済みのシステム、アクション、制限時間と照合し、曖昧またはリスクの高いアクションは人間による判断に回します。ファイルシステムとネットワークの制限を独立して適用し、監査ログを保持し、レビュアーまたはポリシーを利用できない場合はフェイルクローズとします。
カスタムツールや外部ハーネスは、Codex の自動レビューでは自動的に保護されません。Agents SDK のパターンにはガードレールと人間によるレビューを使用し、オープンソースのレビューポリシーを参考にしてください。
Codex 製品側のサンドボックスとレビューは、API のサイバーセキュリティチェックとは別のものです。API の安全対策によって cyber_policy エラーが返されることがあります。また、ユーザーごとの safety_identifier 値は、安全対策が作動した場合の影響を抑えるのに役立ちます。
クリーンアップと結果の検証
作業終了後、一時的な認証情報を取り消し、バックグラウンドプロセスを終了し、永続的アクセスを削除して、リスクの高い環境を破棄します。コールバック、外部に露出したアーティファクト、共有状態、実行をまたぐアクセスが残っていないことを確認し、ユーザー、セッション、評価を相互に分離した状態に保ちます。
調査結果に基づいて対応する前に内容を検証し、協調的な開示の慣行に従い、修復や変更には必ず人が責任を負うようにします。
開始前の確認
承認済みのシステムとアクション、適切なモデル、分離された環境、最小権限、制限されたネットワークアクセス、保護された認証情報、アクションのレビュー、独立した監視、緊急停止、クリーンアップ計画を確認します。モデルの安全対策、分離、範囲を限定した権限、アクションのレビュー、監視、人間による監督は相互補完的なものであり、どれか 1 つだけを唯一の制御手段にしてはいけません。