推奨構成

サイバーセキュリティのワークフローに適したセキュリティ制御は、モデル、モデルが実行できるアクション、アクセス可能なシステム、関連するデータの機密性によって異なります。

ほとんどの Daybreak Blue ワークフローでは、アクセス制御、認証情報の保護、機密性の高いアクションのレビューなど、組織の既存のセキュリティ対策で十分な場合があります。

Daybreak Red ワークフロー、自律型セキュリティテスト、および本番システム、機密データ、外部ツールが関係する活動では、より強力な保護対策が必要になる場合があります。以下の推奨事項は、主にこうしたリスクの高いシナリオを対象としています。

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 は直接のネットワークアクセスを許可するため、ラボの許可リストでは 接続先が制限されません。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 アクションをレビューする

Auto-review は、対象となるサンドボックス境界の承認リクエストを、提案されたアクションの実行前に別のレビュアーへ送ります。レビュアーは、提案されたアクション、範囲を限定したタスクコンテキスト、適用可能なポリシーを考慮し、リクエストを許可または拒否します。組織は、承認済みの対象、禁止されているアクション、人間によるレビューが必要な条件に合わせて、このポリシーをカスタマイズできます。

本番環境、外部システム、機密データ、権限昇格、永続的なアクセス、元に戻せない変更に影響するアクションには、人間による明示的な承認を必須にしてください。Web サイト、リポジトリ、文書、ツール出力に埋め込まれた指示は、信頼できないものとして扱ってください。それらによって承認範囲を拡大したり、アクセス制御を上書きしたりすることはできません。

ChatGPT デスクトップアプリで承認済みの Daybreak モデルを選択すると、そのモードがアカウントで利用可能で、組織ポリシーでも許可されている場合、アクセス許可の制御が自動的に Approve for me に切り替わります。これは、デスクトップアプリの /model コマンドを使用する場合にも適用されます。そのモードを利用できない場合、現在のアクセス許可モードは変更されません。モデルの選択によって、管理対象組織の要件が上書きされることはありません。

自動レビューを実行するには、次の 3 つの制御をすべて維持してください。

1. approval_policy = "on-request" などの対話型承認ポリシーを使用します。
2. approvals_reviewer = "auto_review" を設定します。
3. 強制可能なサンドボックスまたはアクセス許可プロファイルの境界を維持します。

ネットワーク許可リスト上の対象へのリクエストはネットワーク境界内にとどまり、Auto-review を自動的にはトリガーしません。接続先が許可リストに含まれている場合でも機密性の高いコマンドをレビューするには、~/.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" を使用してください。人による判断が必要なアクションには、引き続き人間による明示的な承認が必要です。

Auto-review は、サンドボックス内ですでに許可されている通常のアクションを検査しません。approval_policy = "never" または Full Access では、機密性の高いアクションでもレビュー可能な承認リクエストが生成されない場合があります。自動レビューは誤る可能性があり、分離、明確に定義された境界、監視、人間による明示的な監督に代わるものではありません。

範囲を限定したポリシーと組織全体への適用については、許可されたサイバーセキュリティワークフローを構成するを参照してください。

独立して監視し、安全側に停止する

モデルへのリクエスト、ツール呼び出し、ネットワークアクティビティ、認証情報の使用、セキュリティ関連の変更を記録してください。ログと監視システムは、モデルが制御する環境の外部に配置してください。未承認の対象、予期しないネットワークリクエスト、漏洩した認証情報、ポリシー変更、ログの欠落、保護対策を回避しようとする試みについてアラートを設定してください。

ポリシー適用、認証情報ブローカー、レビューシステム、緊急停止制御をエージェントから独立させてください。必須の制御または監視システムが機能しなくなった場合は、ワークフローを停止してください。

カスタムエージェントのワークフローにガードレールを追加する

Responses API、Agents SDK、または別のハーネスを使用して構築する場合は、ツール実行の境界にレビューを追加してください。実行前に、提案された機密性の高いアクションを承認済みのシステム、アクション、制限時間と照合し、不明確またはリスクの高いアクションを人に送り、独立したファイルシステムおよびネットワークの制限を適用し、監査ログを保持し、レビュアーまたはポリシーを利用できない場合は安全側に停止してください。

Codex Auto-review は、カスタムツールや外部ハーネスを自動的には保護しません。Agents SDK のパターンについてはガードレールと人間によるレビューを、参考資料としてオープンソースのレビュアーポリシーを使用してください。

Codex 製品側のサンドボックス化とレビューは、API のサイバーセキュリティチェックとは別のものです。API の保護対策は cyber_policy エラーを返すことがあり、ユーザーごとの safety_identifier 値は保護対策によるアクションの影響を抑えるのに役立ちます。

クリーンアップして結果を検証する

作業終了後、一時的な認証情報を失効させ、バックグラウンドプロセスを終了し、永続的なアクセスを削除して、リスクの高い環境を破棄してください。コールバック、公開された成果物、共有状態、実行間のアクセスが残っていないことを確認し、ユーザー、セッション、評価を個別に分離してください。

調査結果に基づいて対応する前に内容を検証し、協調的な開示の慣行に従い、修復と変更に対する人の説明責任を維持してください。

始める前に

承認済みのシステムとアクション、適切なモデル、分離された環境、最小権限のアクセス許可、制限されたネットワークアクセス、保護された認証情報、アクションのレビュー、独立した監視、緊急停止、クリーンアップ計画を確認してください。モデルの保護対策、分離、範囲を限定したアクセス許可、アクションのレビュー、監視、人間による監督は互いに補完し合うものであり、いずれか 1 つだけを唯一の制御として使用すべきではありません。