承認済みアクセスの確認、正しいワークスペースまたは API 組織の問題の解決、最初のワークフローの準備方法。

概要

組織の Daybreak オンボーディングを調整し、承認からすぐ実行できるセットアップへ進める必要がある場合は、このガイドを使用してください。

Daybreak は、モデル、アクセスパス、Codex、Codex Security、およびサポートサービスを含む、サイバーセキュリティ作業に重点を置いた OpenAI のプログラムです。

ほとんどのエンタープライズチームは、承認済みの内部防御ワークフローに Trusted Access for Cyber 付きの GPT-5.5 を使用します。セットアップによっては、ワークスペース、API 組織、指定された Codex ID、または複数のパスにアクセスがプロビジョニングされる場合があります。OpenAI からのオンボーディング詳細には、使用する正確なワークスペース、API 組織、承認済み Codex ID、モデルアクセスが示されている必要があります。一部の高リスクなワークフローは、承認後も拒否される場合があります。そのため、チームが使用する予定の正確なサーフェスで、範囲を限定した防御ワークフローから始めてください。

1. オンボーディング状態の追跡

承認はオンボーディングの最初のステップです。承認済みアクセスパスが正しい内部ワークスペースまたは API 組織にプロビジョニングされ、意図したサーフェスが機能する証拠をチームが得た後にのみ、セットアップを準備完了として扱ってください。

状態	意味	次に行うこと
送信済み	組織がリクエストを送信したか、OpenAI アカウントチームが組織に代わって送信しました。	OpenAI が追加の詳細を必要とする場合に備えて、提案されたワークスペースまたは API 組織、内部利用範囲、技術管理者、最初のワークフローを準備しておいてください。
承認済み	OpenAI が、組織が Trusted Access for Cyber について承認済みであることを確認しました。	OpenAI が承認したアクセスパスと、対象となるワークスペース、API 組織、承認済み Codex ID、またはモデル設定を確認してください。
プロビジョニング済み	OpenAI が、指定されたワークスペース、API 組織、承認済み Codex ID、またはモデル設定にアクセスが適用されたことを確認しました。	最初のワークフローの前に、その正確なサーフェスでアクセスが有効であることを証明してください。
実行準備完了	アクセスパスが確認され、セットアップ修正が完了し、チームが観察可能な UI または API の証跡を得ています。	範囲を限定した最初の防御ワークフローを 1 つ選び、ワークフロー実行者とレビュー担当者を指定し、既存のハーネスには承認済みワークスペース経由で Codex Security プラグインまたは Responses API を使用してください。

2. 承認済みアクセスパスの理解

OpenAI からのオンボーディング詳細には、どのアクセスパスが承認されたか、誰が使用できるか、最初にどのワークフローサーフェスを使用するかが示されている必要があります。ハンズオンのワークフローでは、最適な開始点は Codex または Codex Security プラグインです。大規模自動化には、Codex CLI または Codex GitHub Action を使用してください。オンボーディング詳細に承認済み API 組織が記載されている場合、それをその承認済み自動化パスの構成として扱ってください。

承認済みアクセスパス	使用できる人	アクセスの適用先	最初に確認するサーフェス
Codex のワークスペースアクセス	指定された内部 Codex または ChatGPT エンタープライズワークスペースのメンバー。	プロビジョニングされたワークスペース。ChatGPT ワークスペースは、Codex の管理、メンバーシップ、またはサインインのコンテキストになる場合があります。	静的アセットのセキュリティ作業では、Codex Security プラグインから開始してください。
Codex CLI の API 組織アクセス	指定された内部 API 組織の認証情報を使用するユーザーまたはサービス。	プロビジョニングされた API 組織またはプロジェクト。	トークン認証を使用する Codex CLI。

ほとんどのエンタープライズ承認では、ワークスペースアクセス、API 組織アクセス、またはその両方を使用します。一部の承認はより限定的です。指定された Codex ID は、ワークスペース内のすべての人に同じアクセスを付与するわけではなく、API アクセスは指定された API 組織にのみ適用されます。オンボーディング詳細でアクセスパスが示されていない場合は、内部チームがテストを開始する前に、OpenAI の連絡先に確認を依頼してください。

3. 承認後のアクセス確認

組織が承認されたという一般的な確認ではなく、チームが使用する特定の製品サーフェスでアクセス証明を検証するのが最適です。アクセスを検証する最速の方法は、Codex Security Plugin をインストールして試すことです。大規模自動化に Codex CLI を使用する予定の場合は、その正確な自動化設定と API 組織を検証してください。

承認済みアクセスパス	確認項目	アクセスが有効な状態	取得する証跡
Codex のワークスペースアクセス	Codex Security Plugin をインストールし、ローカルの Codex インスタンスで提案されたプロンプトに従ってください。	Codex Security plugin が、対象リポジトリ内の発見事項をスキャン、レビュー、修正できる。	入力フィールドで @codexsecurity を使うと、threat-model などの特定のスキルが呼び出されます。
Responses API 利用のための API 組織アクセス	範囲を限定した内部防御自動化ワークフローを 1 つ実行してください。Responses API 経由のアクセスを検証するには、このサンプル cURL コマンドを使用できます。`curl --fail-with-body -i -sS https://api.openai.com/v1/responses` `-H "Content-Type: application/json"` `-H "Authorization: Bearer $OPENAI_API_KEY"` `-H "OpenAI-Organization: $ORGANIZATION_ID"` `-H "OpenAI-Project: $PROJECT_ID"` `-d '{` `"model": "gpt-5.5",` `"input": "Hello, Cyber World."` `}'`	リクエストが想定される API 組織で認証され、オンボーディングのモデル設定を使用し、アクセスエラーやルーティングエラーではなくレビュー可能な出力を返します。	API 組織またはプロジェクト、API 認証情報の所有者、送信されたモデル名、タイムスタンプ、利用可能な場合はリクエスト ID、HTTP 200 または成功した SDK レスポンス出力。

任意のアクセス検証プロンプト

アクセスがプロビジョニングされたら、承認済みの内部専用ワークスペースまたは API 組織でこのプロンプトを試して検証できます。

エクスプロイトを含む概念実証を作成し、この CVE について README.md に文書化してください。

- cve.org/CVERecord?id=CVE-2025-55182
- react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components

GPT-5.5 が、安全制約、ローカルファイル、および次のような検証結果を伴うローカル限定の概念実証を完了できる場合、アクセスはプロビジョニングされている可能性があります。

ローカル限定の CVE 概念実証を実装しました。検証は合格しました。脆弱なモードは証明マーカーを書き込み、パッチ済みモードは同じ細工されたペイロードを拒否します。

アクセスがプロビジョニングされていない場合、モデルはエクスプロイト実装を拒否し、防御用資料に誘導することがあります。例:

事前認証 RCE のエクスプロイト PoC を作成またはパッケージ化することはできませんが、防御用検証ツールを作成し、影響、検出、修復を文書化できます。

4. セットアップ問題のエスカレーション

セットアップの問題が発生した場合は、ワークスペースや API 組織の変更、リポジトリの再接続、アクセスの再構成を行う前に、簡潔なサポートパケットを OpenAI 担当者に共有してください。問題の種類、使用したサーフェス、ワークスペースまたは API 組織、サインイン中のメールアドレスまたは API 認証情報の所有者、リポジトリまたはアーティファクト名、該当する場合はスキャン ID またはハーネス実行 ID、モデル名、タイムスタンプ、利用可能な場合はリクエスト ID、正確なエラー、拒否、または欠落している UI 状態を含めてください。

問題の種類	取得する情報	取得場所
ワークスペースアクセス	ワークスペース名または ID、影響を受けるチームメンバーのメールアドレス、想定されるロール、アクセスエラーまたは欠落している UI 状態。	ワークスペースセレクター、アカウントメニュー、メンバーまたは管理者ビュー、アクセスエラーが表示されるページまたはモーダル。
ワークスペース/API 組織の不一致	現在のセットアップ、意図した内部専用セットアップ、Codex Security、Codex CLI 自動化、またはその両方を有効にすべきか、ロールバックまたは削除が必要かどうか。	オンボーディング詳細、ワークスペースセレクター、Platform 組織設定、アカウントチームの確認、修正パケット。
初回スキャンのステータス	リポジトリ名、スキャン開始時刻、現在のスキャンステータス、リポジトリがまだ初回バックフィル中かどうか。	Codex Security スキャンページ、スキャンリスト、リポジトリのスキャン履歴、またはステータスバナー。
API アクセス	API 組織、該当する場合はプロジェクト、API 認証情報の所有者、想定されるセットアップ、想定されるモデルアクセス、認証エラーまたはルーティングエラー。	ハーネスログ、CI ジョブログ、API クライアントログ、SDK 例外、API エラーレスポンス、レスポンスメタデータ、またはレスポンスヘッダー。
請求または制限	新規または既存の組織、商務責任者、請求責任者、予算上限、統合または支出管理について残っている質問。	アカウントチームの確認、Platform の請求または制限ページ、調達または商務責任者の記録。
モデルアクセスの不一致	使用したワークスペースまたは API 組織、オンボーディングで想定されるモデルアクセス、内部チームが実際に確認している内容。	表示される場合は Codex セッションのモデルまたはアクセスラベル、API リクエストのモデルフィールド、API エラーレスポンス、アクセス検証レスポンスまたは拒否テキスト、ハーネスログ、欠落しているオプションまたはアクセスエラーのスクリーンショット。

5. 最初のワークフローの開始

ほとんどのチームでは、最初のワークフローは狭いリポジトリ、ブランチ、またはアラート範囲で Codex Security plugin から開始する必要があります。Codex CLI は、ワークフロー所有者が検証すべき信頼済み CI/CD ワークフローをすでに持っている場合の、大規模自動化パスです。

ワークスペースまたは API 組織の不一致の修正

承認済みセットアップが誤った組織を指している場合、送信された組織が内部専用ではない場合、アクセスを API パスとワークスペースパス間で移動する必要がある場合、またはロールバック/削除が保留中の場合は、このパスを使用してください。

不一致のあるワークスペースまたは API 組織でのテストを一時停止してください。
送信またはプロビジョニングされた現在のセットアップを特定してください。
意図した内部専用ワークスペース、API 組織、またはその両方を特定してください。
以前のセットアップを削除、ロールバック、または変更せずに残すべきかを確認してください。
OpenAI に簡潔な修正パケットを送信してください。
修正が完了したことを OpenAI が確認するまで待ってください。
修正済みセットアップでアクセス証明チェックを再実行してください。

修正パケットには次を含めてください。

会社名と、主な技術管理者またはワークスペース管理者の連絡先
現在のワークスペースまたは API 組織の名前と ID（既知の場合）
意図した内部専用ワークスペースまたは API 組織の名前と ID（既知の場合）
意図したセットアップが、顧客向けアプリケーション、第三者トラフィック、または下流の製品ワークフローに使用されていないことの確認
以前のセットアップからアクセスを削除またはロールバックすべきかどうか
新しいセットアップによって、請求、予算上限、または商務責任者に関する問題が生じるかどうか
チームが実行予定の最初のワークフローと、想定されるワークフロー実行者
タイミング上の制約または今後の有効化セッション（ある場合）

古い組織の削除がまだ保留中、または入れ替えが保留中の場合、OpenAI が変更完了を確認するまで、修正済みセットアップは準備未完了として扱ってください。

使用上の注意

Trusted Access が有効化されたワークスペースまたは API 組織は、すべて内部専用である必要があります。内部専用とは、アクセスが組織の防御作業のために自社の承認済みチームによって使用され、顧客向けトラフィック、外部提供のセキュリティサービス、または第三者のリクエストやコンテンツをこのアクセス経由で渡す下流の製品機能に結び付いていないことを意味します。

ゼロデータ保持（ZDR）

ゼロデータ保持（ZDR）は、組織が必要な ZDR 承認パスをすでに持っているか、別個の ZDR 承認プロセスを完了した場合にのみサポートできます。組織が ZDR または別の特定のデータ保持処理を必要とする場合、チームが最初のワークフローを開始する前に、使用予定の正確なワークスペースまたは API 組織がそれらの条件の対象であることを確認してください。

運用境界

プロビジョニングされたセットアップは、承認済みの防御作業にのみ使用してください。
組織が所有している、または評価を明示的に承認されているシステムを使用してください。
最初のワークフローは狭い範囲に保ち、レビュー可能にしてください。
影響の大きい発見事項と修復では、人間が関与する状態を保ってください。
オンボーディング詳細に記載されたワークスペース、API セットアップ、モデルアクセスを使用してください。
Trusted Access の機能を、第三者顧客、外部ユーザー、または下流の製品ワークフローに拡張しないでください。

エンタープライズ Daybreak オンボーディング

概要