エンタープライズ向け Trusted Access のオンボーディング完了、プロビジョニング済みアクセスの検証、組織またはワークスペースの問題修正、最初のワークフロー準備の方法

概要

このガイドは、組織の Daybreak オンボーディングを調整し、受付からプロビジョニング、すぐに実行できるセットアップまで進める必要がある場合に使用します。

Daybreak は、モデル、アクセス経路、Codex、Codex Security、関連サービスを含む、サイバーセキュリティ業務に重点を置いた OpenAI のプログラムです。

ほとんどのエンタープライズチームは、承認済みの社内防御ワークフローに Trusted Access for Cyber 付きの GPT-5.5 を使用します。このアクセス経路では、Persona KYB 検証と社内適合性チェックが完了した後、受付プロセスで特定された組織またはワークスペースを OpenAI がプロビジョニングします。承認されたセットアップに応じて、アクセスは Codex または ChatGPT 組織、API 組織、またはその両方に適用される場合があります。

リスクが高い一部のワークフローは、プロビジョニング後でも拒否される場合があります。そのため、チームが使用する予定の正確なサーフェスで、範囲を限定した防御ワークフローから始めてください。

オンボーディングとプロビジョニング状態の追跡

フェーズ	説明	次に行うこと
受付フォームの送信	組織がエンタープライズ向け Trusted Access の受付フォームを完了済み	Persona からのメールを確認し、KYB 検証を完了してください。Persona からのメールが、組織の適切な連絡先に届くようにしてください。
Persona からの KYB メールの受信と完了	受付フォームが送信されると、Persona は、Know Your Business（KYB）検証を完了するためのメールを、受付フォームに記載された連絡先に送信します。	Persona KYB リクエストを完了してください。KYB が完了すると、OpenAI は社内適合性チェックを実施し、そのチェックに合格した場合にのみプロビジョニングします。
プロビジョニング完了通知の受信	OpenAI が、受付フォームでリクエストされた組織またはワークスペースにアクセスを適用済み	リクエストしたサーフェスでアクセスが正しくプロビジョニングされていることを確認してください。現在、アクセスは顧客に表示されるワークスペースダッシュボードには掲載されないことに注意してください。
アクセスの確認と、範囲を限定した防御ワークフローの開始	プロビジョニング済みの組織またはワークスペースが確認され、対象のアクセスチェックが成功済み	範囲を限定した最初の防御ワークフローを 1 つ選び、ワークフロー実行者とレビュアーを指定し、Codex Security プラグインまたは承認済みの Responses API 組織を使用します。

プロビジョニング済みアクセス経路の把握

OpenAI からの確認には、どのアクセス経路がプロビジョニングされたか、誰が使用できるか、最初に使用する組織またはワークスペースが示されている必要があります。

実際にリポジトリを扱うワークフローでは、Codex または Codex Security プラグインから始めてください。承認済みの自動化には、Codex CLI または Codex GitHub Action を使用します。API 組織にアクセスがプロビジョニングされている場合は、リクエストと認証情報の範囲をその組織に限定してください。

プロビジョニング済みアクセス経路	使用できるユーザー	アクセスの適用先	アクセス検証の最初のサーフェス
Codex 経由のアクセス	指定された社内 Codex または ChatGPT 組織、またはワークスペースのメンバー	プロビジョニング済みの組織またはワークスペース。この経路ではアクセスが組織全体に適用されます	静的アセットのセキュリティ作業では、Codex Security プラグインから始めてください。
API 組織経由のアクセス	指定された社内 API 組織に認証されたユーザーまたはサービス	プロビジョニング済みの API 組織	Responses API または別の承認済み Codex API ワークフロー。

Trusted Access for Cyber 付き GPT-5.5 の場合、ワークスペースアクセスは指定された Codex または ChatGPT 組織にプロビジョニングされ、API アクセスは指定された API 組織にプロビジョニングされます。確認内容に、別のユーザーレベルまたはモデル固有の経路が記載されている場合は、組織全体のアクセスを想定せず、その正確な指示に従ってください。プロビジョニング済みアクセス経路が不明な場合は、テスト前に OpenAI の担当者に確認してください。

プロビジョニング済みアクセスの検証

OpenAI がプロビジョニングを確認したら、確認済みの正確なサーフェスでこのプロンプトを実行します。これは、社内専用の組織またはワークスペースにサインインした状態の Codex で行うことも、確認済みの API 組織の認証情報を使用して Responses API 経由で行うこともできます。

エクスプロイトを含む概念実証を作成し、CVE-2025-55182 の 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 概念実証を実装しました。検証は合格しました。脆弱なモードは証明マーカーを書き込み、パッチ済みモードは同じ細工されたペイロードを拒否します。

プロンプトが拒否される、または期待される範囲内の結果を生成しない場合は、まずサインイン中の ID と組織またはワークスペースを確認してください。この結果は、プロビジョニング未完了、ルーティングの不一致、またはポリシー境界を示している可能性があります。プロビジョニングが完了していて問題が続く場合は、診断手順とサポートへの問い合わせ時に含める詳細について、Trusted Access for Cyber - よくある問題とトラブルシューティングに従ってください。サポートリクエストを作成するには、こちらを参照してください。サポートに問い合わせるには？拒否は次のように表示される場合があります。

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

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

ワークスペース、API 組織、リポジトリ、認証情報を変更する前に、プロビジョニングが完了していること、および対象の組織、ワークスペース、アクセス経路が正しいことを OpenAI アカウントチームに確認してください。

検証、アクセス、モデル、サイバー安全性の問題については、Trusted Access for Cyber - よくある問題とトラブルシューティングに従ってください。この記事には、診断手順と、サポートへの問い合わせ時に提供する情報が含まれています。たとえば、組織 ID、製品サーフェス、モデル、完全なエラーメッセージ、リクエスト ID、タイムスタンプとタイムゾーン、該当する場合はスクリーンショット、タスクの簡潔な編集済み説明などです。

サポートリクエストを作成するには、こちらを参照してください。サポートに問い合わせるには？

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

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

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

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

不一致のあるワークスペースまたは API 組織でのテストを一時停止します。
送信またはプロビジョニングされた現在のセットアップを特定します。
対象の社内専用ワークスペース、API 組織、またはその両方を特定します。
以前のセットアップを削除、ロールバック、または変更せずに残すべきかを確認します。
修正リクエストとして、以下の詳細を OpenAI アカウントチームに送信します。
OpenAI から修正完了の確認が届くまで待ちます。
修正後のセットアップでアクセス証明チェックを再実行します。

含める内容:

会社名、および主な技術担当者またはワークスペース管理者の連絡先
現在のワークスペースまたは API 組織の名前と ID（わかる場合）
対象の社内専用ワークスペースまたは API 組織の名前と ID（わかる場合）
対象のセットアップが、顧客向けアプリケーション、サードパーティトラフィック、または下流の製品ワークフローに使用されていないことの確認
以前のセットアップからアクセスを削除またはロールバックする必要があるかどうか
新しいセットアップにより、請求、予算上限、または商業上の所有者に関する確認事項が発生するかどうか
チームが実行予定の最初のワークフローと、想定されるワークフロー実行者
タイミング上の制約または予定されている有効化セッション（ある場合）

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

使用上の注意

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

ゼロデータ保持（ZDR）

Trusted Access のプロビジョニングによって、ゼロデータ保持（ZDR）が自動的に有効になるわけではありません。ZDR は、正確な組織に対して別途リクエストし、プロビジョニングする必要があります。組織で ZDR またはその他の特定のデータ保持処理が必要な場合は、チームが最初のワークフローを開始する前に、使用予定の組織がそれらの条件の対象になっていることを確認してください。

運用境界

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

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

概要