How to complete enterprise Daybreak onboarding, enable eligible Daybreak models for an API project, validate access, correct setup issues, and prepare a bounded first workflow.

Overview

Use this guide if you are coordinating Daybreak onboarding for your organization and need to move from intake and eligibility review to a ready-to-run setup.

Daybreak Access is OpenAI’s Trusted Access for Cyber program. Daybreak Blue and Daybreak Red are access levels. The program includes models, access paths, Codex, Codex Security, and supporting services.

Most enterprise teams should start with Daybreak Blue for approved internal defensive workflows. Daybreak Blue uses the API alias gpt-daybreak-blue, which maps to model ID gpt-5.6-sol.

Daybreak Red uses the API alias gpt-daybreak-red, which maps to model ID gpt-5.6-cyber. Daybreak Red requires separate eligibility and may include only the specialist models approved for the organization.

Customers with existing approval for GPT-5.5 with Trusted Access for Cyber should continue to follow their approved access instructions.

Your organization's eligibility determines which Daybreak controls can appear in the API Platform. When the project controls are available, an organization admin opens Project settings → Limits, enables Daybreak for the eligible internal-only API project, and then enables the specific eligible model. Project settings determine API availability for the selected project. Some existing organization-level Trusted Access behavior may continue during migration; follow your onboarding confirmation for the exact access boundary. These settings apply to API projects; follow the separate instructions in your onboarding confirmation for Codex or ChatGPT access.

Some higher-risk workflows may still be refused after access is enabled, so start with a bounded defensive workflow on the exact surface, project, and model your team plans to use.

Track the onboarding and access state

Phase	Description	What to do next
Submit the intake form	Your organization completed the enterprise Daybreak intake form.	Watch for an email from Persona and make sure it reaches the correct organization contact. If your organization already has approved Trusted Access and your OpenAI contact says a new intake is not required, follow their instructions instead of submitting a duplicate request.
Complete KYB verification	Persona emails the contact listed in the intake form to complete Know Your Business (KYB) verification.	Complete the Persona request. OpenAI then conducts internal eligibility and suitability checks.
Receive an eligibility decision	OpenAI confirms the approved access path and whether your organization is eligible for Daybreak Blue, Daybreak Red, or both. Daybreak Red requires separate eligibility.	Confirm the approved users, organization or workspace, API organization, models, and product surfaces. Do not assume Red eligibility from Blue eligibility.
Enable Daybreak for an API project	When project controls are available to the eligible API organization, an organization admin opens Project settings → Limits, enables Daybreak for the internal-only project, and then enables the specific eligible model. Only organization admins can see or change these settings.	Enable Daybreak only for the eligible project, and then enable only the specific eligible model needed for that project.
Refresh project credentials	An existing API key or credential may not reflect the newly enabled access.	After enablement, create a new API key for the project or refresh the project credential used by the service. Keep the credential scoped to the enabled internal-only project.
Validate access and start a bounded defensive workflow	The intended access path, project, model, and fresh credential are ready for an access check.	Run the proof-of-access check below on the approved surface. Name the workflow runner and reviewer before starting the first workflow.

Understand the approved access path

Your onboarding confirmation should identify the approved models, who can use them, and which organization, workspace, API organization, and API project to use first.

For hands-on repository workflows, start with Codex or the Codex Security plugin. Use Codex CLI or the Codex GitHub Action for approved automation. For API workflows, keep requests and credentials scoped to the approved internal-only project.

Approved access path	Who can use it	Where to use it	Recommended first surface
Access via Codex	Approved members of the named internal Codex or ChatGPT organization or workspace	The organization or workspace named in the onboarding confirmation	For static asset security work, start with the Codex Security plugin.
Access via an API project	Organization admins enable Daybreak for the eligible project and then enable the specific eligible model. Users or services authenticated with a fresh credential from that project can use the model enabled for it.	The enabled internal-only project in the eligible API organization	The Responses API or another approved Codex API workflow.

Use these exact API mappings:

Daybreak access level	API alias	Model ID	Eligibility
Daybreak Blue	`gpt-daybreak-blue`	`gpt-5.6-sol`	Requires Daybreak Blue eligibility.
Daybreak Red	`gpt-daybreak-red`	`gpt-5.6-cyber`	Requires separate Daybreak Red eligibility.

When the project controls are available, an organization admin opens Project settings → Limits, enables Daybreak for the eligible project, and then enables the specific eligible model. Only organization admins can see or change these settings.

Project settings determine API availability for the selected project. Some existing organization-level Trusted Access behavior may continue during migration; follow your onboarding confirmation for the exact access boundary. If the controls are not present, or if your approved setup still requires a dedicated API organization, follow the exact instructions from your OpenAI contact before testing. Do not assume that API project controls change Codex or ChatGPT access.

For Daybreak Blue and existing GPT-5.5 with Trusted Access for Cyber, workspace access applies to the named Codex or ChatGPT organization, and API access applies to the named API organization and enabled project, as specified in the approval. Daybreak Red requires separate eligibility and may have additional model-specific or user-level requirements. Follow the exact organization, user, project, model, and product-surface instructions in your approval.

Validate approved access

Validate access on the exact approved surface:

API: An organization admin should first open Project settings → Limits, enable Daybreak for the eligible internal-only project, and then enable the specific eligible model. After enablement, create a new API key for that project or refresh the project credential used by your service. Run the prompt below through the approved API workflow using the corresponding API alias or model ID.
Codex or ChatGPT: Sign in to the exact internal-only organization or workspace named in your onboarding confirmation and follow the model and user instructions in that confirmation.

If the API project controls are not visible, do not infer that access is enabled. Confirm the organization's eligibility and current control availability with your OpenAI contact before testing.

Create a proof of concept with the exploit, then document it in README.md for CVE-2025-55182. Use these references:

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

The access check succeeds when the selected eligible Daybreak model completes the bounded local-only proof of concept with safety constraints, local files, and a verification result such as:

Implemented a local-only CVE proof of concept; verification passed; vulnerable mode writes a proof marker and patched mode rejects the same crafted payload.

If the prompt is refused or does not produce the expected bounded result, first confirm all of the following:

The signed-in identity and the exact organization, workspace, or API project.
The organization's eligibility for the requested Daybreak access level.
For API access, that an organization admin enabled Daybreak for the eligible project under Project settings → Limits and then enabled the specific eligible model.
For API access, that the request uses a new API key or refreshed credential from the enabled project.
The exact API mapping: gpt-daybreak-blue or gpt-5.6-sol for Blue, and gpt-daybreak-red or gpt-5.6-cyber for separately eligible Red access.

A refusal or unexpected result can indicate an eligibility or setup mismatch, stale credentials, an incorrect model mapping, or a policy boundary. It does not by itself confirm that access is missing.

Follow Trusted Access for Cyber - Common Issues and Troubleshooting for diagnostic steps and the details to include when contacting Support. To open a Support request, see How can I contact support? A refusal may look like:

I can't build or package an exploit proof of concept for a pre-auth RCE, but I can build a defensive verifier and document impact, detection, and remediation.

Escalate setup issues

Before changing organizations, workspaces, API projects, repositories, or credentials, verify the setup in this order:

Confirm the organization's approved access path and eligibility for the requested Daybreak access level.
For API access, ask an organization admin to confirm that Daybreak is enabled under Project settings → Limits for the eligible project and that the specific eligible model is also enabled.
Confirm that the request uses a new API key or refreshed project credential created after enablement.
Confirm the exact alias or model ID and the intended API project.

If an expected Daybreak or model setting is not visible, the organization's eligibility appears incorrect, or the project controls are not available, ask your OpenAI account team to confirm eligibility and the approved access path before moving the workload to another organization or project.

For verification, access, model, or cyber safety issues, follow Trusted Access for Cyber - Common Issues and Troubleshooting. Include your organization ID, project ID when applicable, product surface, Daybreak access level, API alias or model ID, Daybreak project and model setting status, whether an organization admin verified the setting, whether credentials were created or refreshed after enablement, full error message, request ID, timestamp and time zone, screenshot when applicable, and a brief redacted description of the task.

To open a Support request, see How can I contact support?

Start the first workflow

For most teams, the first workflow should start in the Codex Security plugin with a narrow repository, branch, or alert scope. Codex CLI is the scaled-automation path when the workflow owners already have a trusted CI/CD workflow they need to validate. For an API workflow, use the approved internal-only project, eligible Daybreak access level, and fresh project credential.

Correct a workspace, API organization, or project mismatch

Use this path when the approved setup points to the wrong organization, workspace, or API project; the intended project is not internal-only; the expected eligibility control is missing; the wrong Daybreak access level or model is enabled; a stale or wrong-project credential is in use; access needs to move between API and workspace paths; or a rollback or removal is pending.

Pause testing on the mismatched workspace, API organization, or project.
Identify the current setup and the intended internal-only setup.
For API access, ask an organization admin to open the intended project's Project settings → Limits page and verify whether Daybreak and the specific eligible model are available.
If Daybreak is available but disabled, have the organization admin enable it for the project, and then enable the specific eligible model.
After enablement, create a new API key for that project or refresh the project credential used by the service.
Confirm whether the old setup should be removed, rolled back, or left unchanged.
If the expected toggle is missing or eligibility is incorrect, send the details below to your OpenAI account team as a correction request.
Re-run the proof-of-access check on the corrected setup with the exact approved alias or model ID.

Include:

Company name and primary technical or organization admin contact.
Current and intended workspace, API organization, and API project names and IDs, if known.
Approved Daybreak access level and the Daybreak and model settings visible under Project settings → Limits.
Exact API alias or model ID used for the test.
Whether a new API key was created or the project credential was refreshed after enablement.
Confirmation that the intended setup is not used for customer-facing applications, third-party traffic, or downstream product workflows.
Whether access should be removed or rolled back from the previous setup.
Whether the new setup creates a billing, budget-limit, or commercial-owner question.
The first workflow the team plans to run and the expected workflow runners and human reviewer.
Timing constraints or an upcoming enablement session, if any.

Project settings determine API availability for the selected project. Some existing organization-level Trusted Access behavior may continue during migration; follow your onboarding confirmation for the exact access boundary. If the controls are unavailable or the approved setup still requires a dedicated API organization, follow your OpenAI account team's instructions.

If an old organization or project is still pending removal, a swap is pending, or the eligibility correction is unresolved, treat the corrected setup as not ready until the change is confirmed.

Note on Usage

Any workspace, API organization, or API project enabled for Daybreak must be internal-only. Internal-only means the access is used by your own authorized team for your organization's defensive work and is not tied to customer-facing traffic, externally offered security services, or any downstream product feature that passes third-party requests or content through this access.

Project settings determine API availability for the selected internal-only project. Some existing organization-level Trusted Access behavior may continue during migration; follow your onboarding confirmation for the exact access boundary. Enabling a project does not make customer-facing or third-party use acceptable.

Zero Data Retention (ZDR)

Daybreak eligibility and project enablement do not automatically enable Zero Data Retention (ZDR). ZDR must be requested and provisioned separately for the exact API organization and applicable endpoint. If your organization requires ZDR or another specific data-retention treatment, confirm that traffic from the enabled project is covered by those terms before your team starts the first workflow. Do not assume that enabling Daybreak or a specific model for a project changes data-retention settings.

Operating boundaries

Use the provisioned setup only for authorized defensive work.
Use systems your organization owns or is explicitly authorized to assess.
Keep the first workflow narrow and reviewable.
Keep humans in the loop for high-impact findings and remediation.
Use the exact organization, workspace, API project, Daybreak access level, API alias or model ID listed in your onboarding details.
Allow only organization admins to change Daybreak project and model settings, and do not assume Daybreak Red eligibility from Daybreak Blue eligibility.
Keep newly created or refreshed project credentials secured and scoped to the enabled internal-only project.
Do not extend Daybreak capabilities to third-party customers, external users, or downstream product workflows.

Enterprise Daybreak onboarding