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 tiers within Daybreak.
Most enterprise teams should start with Daybreak Blue for approved internal defensive workflows.
Daybreak Red requires separate approval for advanced, authorized cybersecurity workflows. Some frontier cyber models require additional model-specific approval.
Approval alone does not turn on reduced refusals. Daybreak controls are initially OFF. A workspace owner enables access for approved users and groups; an API organization owner enables it for approved non-default projects. Configure both if your team uses both access paths. Users signing in to Codex with ChatGPT must also turn on Daybreak before making a request.
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 Daybreak 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, workspace or API organization, models, and product surfaces. Do not assume Red eligibility from Blue eligibility. OpenAI sends the organization or workspace admin a welcome email when provisioning is complete. |
| Configure workspace or API access | For ChatGPT and Codex sign-in, a workspace owner configures roles for approved users and groups. For API access, an API organization owner enables Daybreak on each approved non-default project. Follow the steps under “Validate approved access” below. | Enable only the approved access level for the intended users or project, save, and verify the saved settings. Default projects cannot enable Daybreak. Workspace access and API project access are separate. |
| Use the destination project’s credentials | An API key belongs to a specific organization and project. A key from an old organization or project does not grant access to the destination. | Use an API key from the enabled project. If you migrated to another organization or project, create or select a key there and update the applications or workflows that use it. Keep credentials scoped to approved internal use. |
| Validate access and start a bounded defensive workflow | The intended workspace or project, approved users, model, and API 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 | API organization owners configure the eligible Daybreak controls. Approved users or services use a key from the enabled project, within that project’s approved scope. | The enabled internal-only project in the eligible API organization | The Responses API or another approved Codex API workflow. |
For OpenAI API access, use a specific model ID included in your approved access and the matching Daybreak request setting. The examples below depend on your organization's model approvals.
| Daybreak tier | Example model ID | Eligibility |
|---|---|---|
| Daybreak Blue | gpt-6-sol | Requires Daybreak Blue eligibility. |
| Daybreak Red | gpt-5.6-cyber | Requires separate Daybreak Red approval. The gpt-5.6-cyber example also requires additional model approval. |
In Responses API requests, set access_programs.cyber to daybreak_blue for gpt-6-sol, including if your organization has Daybreak Red approval. To use standard safeguards, set it to standard.
For gpt-5.6-cyber, use daybreak_red only if your organization has both Daybreak Red approval and the required additional model approval.
An organization approved for Daybreak Blue can use the Blue control; an organization approved for Red can use both. Enabling a control does not grant access to models outside your organization’s approval.
Where project-level controls are enabled, approved internal-only API projects can replace a separate dedicated API organization. Follow your migration confirmation before changing an existing setup. For ChatGPT and Codex sign-in, configure workspace roles separately; enabling an API project does not configure workspace access.
GPT-6 Sol and GPT-6 Luna support reduced refusals with Daybreak Blue or Red. Astra and GPT-6.1 Sol retain standard safeguards with Blue and support reduced refusals with Red. Model availability still depends on your account and product surface. Use the organization, users, project, and models specified in your approval.
Daybreak is also available through AWS Bedrock and still requires OpenAI approval. Contact your AWS account team for access.
Validate approved access
Validate access on the exact approved surface:
API: An API organization owner opens the intended non-default project and goes to Project settings → General → Daybreak model access. Enable the approved Daybreak tier and save. Default projects are not eligible, and being a project owner alone does not permit changes. Allow up to about 15 minutes, then send a direct Responses API request using that project’s key and an approved model ID. A model’s absence from /models does not by itself mean access is unavailable.
ChatGPT and Codex with ChatGPT sign-in: A workspace owner opens Admin Console → Models → Workspace default. Under Cybersecurity, turn Daybreak Red off if enabled, then turn Blue off, and select Save changes. Open Roles and choose Edit override for the intended role or Add role override. Under Cybersecurity, set Daybreak Blue to On; enable Red only if approved for the workspace and those users. Select Save and allow about 10 minutes. Review direct and group role assignments, then sign in to the approved workspace and test with an approved model. In Codex, turn the Daybreak toggle ON before testing; with it OFF, standard safeguards apply.
If the expected control is missing, check the approved workspace or API organization, the administrator’s permissions, and whether provisioning is complete. For API access, confirm you are viewing a non-default project; for workspace access, check Admin Console → Models. If the control still does not appear, contact your OpenAI account team to confirm eligibility and provisioning 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
An authorized, local-only test can help check the selected model and access path. A result such as the following is one possible outcome, not a guaranteed response:
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 request fails, is refused, or produces an unexpected 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 tier and any additional model approval. For Astra or GPT-6.1 Sol, Blue access retains standard safeguards.
For Codex sign in with ChatGPT, that the workspace owner enabled access for the intended user and the user’s Daybreak toggle is ON. With API-key sign-in, access follows the enabled API project; there is no separate Daybreak interface.
For API access, that an API organization owner saved the approved Daybreak tier for the intended non-default project.
For API access, that the request uses a key from the enabled project and that any migrated workload has been updated to use the destination project.
The exact approved model ID, using the OpenAI API table above where applicable.
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 tier.
Confirm the saved Daybreak settings for the intended workspace users or non-default API project, following “Validate approved access” above.
Confirm that the request uses an API key belonging to the enabled project.
Confirm the exact model ID and the intended API project.
If an expected toggle 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 OpenAI Daybreak: Common issues and troubleshooting. Include your organization or workspace ID, project ID when applicable, product surface, Daybreak level, model ID, saved control settings, the administrator’s role, whether the credential belongs to the enabled project, 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 workflow owners already have a trusted CI/CD workflow to validate. For API workflows, use the approved internal-only project, approved Daybreak level, and that project’s API key.
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; an expected control is missing; the wrong Daybreak level is enabled; a 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 API organization owner to verify the eligible Daybreak controls for the intended non-default project using the steps above.
If the approved API toggle is visible but disabled, have the API organization owner enable it and save. For workspace access, have a workspace owner review the intended user’s direct and group roles and saved model permissions. Before retesting in Codex with ChatGPT sign-in, confirm that the user’s Daybreak toggle is ON.
For API access, use a key from the enabled destination project and allow up to about 15 minutes for changes to apply. Allow about 10 minutes for workspace changes before retesting.
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 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 level and the controls visible under Project settings → General → Daybreak model access, or the saved workspace and role settings.
Exact model ID used for the test.
Whether the request uses a key from the enabled project and whether migrated workloads have been updated to use the destination project.
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.
Where approved project controls are available, they are intended to isolate Daybreak access by project instead of requiring a separate API sub-organization. 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
Daybreak access must be restricted to approved internal users and internal security work. Internal-only means your own authorized team’s work, not customer-facing traffic, externally offered security services, or downstream features that pass third-party requests through Daybreak. Where controls are enabled, use workspace roles and internal-only API projects to enforce the approved scope.
Where approved project controls are available, an internal-only project can isolate Daybreak access within an eligible API organization instead of requiring a separate API sub-organization. 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 a Daybreak Blue or Daybreak Red project toggle 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 tier, model ID listed in your onboarding details.
Allow only API organization owners to configure the Daybreak project controls. Workspace owners manage workspace defaults and custom-role assignments. Daybreak Blue approval does not include Daybreak Red.
Keep project credentials secure and scoped to the enabled internal-only project.
Do not extend Daybreak capabilities to third-party customers, external users, or downstream product workflows.