サイバーセキュリティのワークフローに必要なセキュリティ対策は、使用するモデル、そのモデルが実行できる操作、アクセスできるシステム、扱うデータの機密性によって異なります。
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 デスクトップアプリは、危険な操作についてモデル固有の警告を表示します。警告では、代わりに Approve for me を選ぶことを推奨し、レビュアーポリシーの設定へのリンクを示します。警告が表示されても、サンドボックスの制限が復元されたり、組織のポリシーが上書きされたりすることはありません。
作業範囲を文書化し、環境の分離、最小権限の設定、監視、人による監督と併せて自動レビューを使用してください。
慎重な判断を要する Codex 操作のレビュー
自動レビューでは、提案された操作を実行する前に、対象となる承認リクエストを別のレビュアーに送ります。レビュアーは、操作の内容、タスクのコンテキスト、適用されるポリシーを考慮してレビューします。組織は、承認済みの対象、禁止する操作、人による承認が必要な条件について、適用中のポリシーにルールを追加できます。
本番環境、外部システム、機密データに影響する操作や、権限昇格、永続的なアクセス、元に戻せない変更を伴う操作には、人による明示的な承認を必須としてください。ウェブサイト、リポジトリ、ドキュメント、ツールの出力に埋め込まれた指示は、信頼できないものとして扱います。こうした指示で承認範囲を広げたり、アクセス制御を上書きしたりすることはできません。
ChatGPT デスクトップアプリで承認済みの Daybreak モデルを選択すると、アカウントで利用可能で、かつ組織のポリシーで許可されている場合に限り、権限設定が自動的に Approve for me に切り替わります。デスクトップアプリの /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 の値を設定すると、保護措置が発動した際の影響範囲を限定しやすくなります。
作業後のクリーンアップと結果の検証
作業終了後は、一時的な認証情報を失効させ、バックグラウンドプロセスを終了し、永続的なアクセス手段を削除してください。リスクの高い作業に使用した環境は破棄します。コールバック、外部に露出した成果物、共有状態、実行をまたいで利用できるアクセス手段が残っていないことを確認してください。ユーザー、セッション、評価はそれぞれ分離した状態を維持します。
調査結果に基づいて対応する前に、その内容を検証してください。脆弱性の開示は関係者と調整して進め、修正や変更には人が責任を持つようにします。
開始前の確認事項
承認されたシステムと操作、作業に適したモデル、分離された環境、必要最小限の権限、ネットワークアクセスの制限、認証情報の保護、操作のレビュー、独立した監視、緊急停止手段、クリーンアップ計画を確認してください。モデルの保護対策、環境の分離、範囲を限定した権限、操作のレビュー、監視、人による監督は互いに補い合うものです。どれか一つだけに依存しないでください。