Descripción general

Usa esta guía si coordinas la incorporación a Daybreak en tu organización y necesitas pasar de la solicitud y la revisión de los requisitos de acceso a una configuración lista para usar.

Daybreak Access es el programa de acceso de confianza para ciberseguridad de OpenAI. Daybreak Blue y Daybreak Red son niveles de acceso de Daybreak.

La mayoría de los equipos empresariales deberían empezar con Daybreak Blue para los flujos de trabajo defensivos internos aprobados.

Daybreak Red requiere una aprobación independiente para flujos de trabajo de ciberseguridad avanzados y autorizados. Algunos modelos de ciberseguridad de vanguardia requieren una aprobación adicional específica para el modelo.

La aprobación por sí sola no activa la reducción de rechazos. Los controles de Daybreak están inicialmente DESACTIVADOS. Un propietario del Área de trabajo habilita el acceso para los usuarios y grupos autorizados; un propietario de la organización de la API lo habilita para los proyectos aprobados que no sean los predeterminados. Configura ambas vías de acceso si tu equipo usa las dos. Los usuarios que inicien sesión en Codex con ChatGPT también deben activar Daybreak antes de realizar una solicitud.

Algunos flujos de trabajo de mayor riesgo pueden seguir rechazándose tras habilitar el acceso. Por eso, empieza con un flujo de trabajo defensivo de alcance limitado en la interfaz, el proyecto y el modelo concretos que tu equipo vaya a usar.

Haz un seguimiento del estado de la incorporación y del acceso

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.

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.

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?.

Inicia el primer flujo de trabajo

Para la mayoría de los equipos, el primer flujo de trabajo debería comenzar en el complemento Codex Security, con un alcance limitado a determinados repositorios, ramas o alertas. Codex CLI es la vía para automatizar a escala cuando los responsables ya cuentan con un flujo de trabajo de CI/CD fiable que quieren validar. Para los flujos de trabajo con la API, usa el proyecto aprobado de uso exclusivamente interno, el nivel de Daybreak aprobado y la clave de API de ese proyecto.

Corrige una discrepancia en el Área de trabajo, la organización de la API o el proyecto

Sigue este procedimiento cuando la configuración aprobada apunte a una organización, Área de trabajo o proyecto de la API incorrectos; el proyecto previsto no sea de uso exclusivamente interno; falte un control esperado; esté habilitado un nivel de Daybreak incorrecto; se use una credencial de otro proyecto; sea necesario trasladar el acceso entre la API y el Área de trabajo; o haya una reversión o eliminación pendiente.

• Pausa las pruebas en el Área de trabajo, la organización de la API o el proyecto que presente la discrepancia.

• Identifica la configuración actual y la configuración prevista de uso exclusivamente interno.

• Para el acceso a la API, pide a un propietario de la organización de la API que siga los pasos anteriores para verificar los controles de Daybreak disponibles para el proyecto previsto, que no debe ser el predeterminado.

• Si el interruptor aprobado de la API está visible pero desactivado, pide al propietario de la organización de la API que lo active y guarde los cambios. Para el acceso al Área de trabajo, pide a uno de sus propietarios que revise los roles directos y por grupos del usuario previsto, así como los permisos de modelos guardados. Antes de repetir la prueba en Codex con inicio de sesión mediante ChatGPT, confirma que el interruptor de Daybreak del usuario esté ACTIVADO.

• Para el acceso a la API, usa una clave del proyecto de destino habilitado y espera hasta unos 15 minutos para que se apliquen los cambios. Espera unos 10 minutos para que se apliquen los cambios del Área de trabajo antes de repetir la prueba.

• Confirma si la configuración anterior debe eliminarse, revertirse o dejarse sin cambios.

• Si falta el interruptor esperado o los permisos de acceso no son correctos, envía los datos que se indican a continuación al equipo de OpenAI que gestiona tu cuenta para solicitar una corrección.

• Vuelve a ejecutar la prueba de acceso en la configuración corregida con el alias o ID de modelo exacto que se haya aprobado.

Incluye:

• Nombre de la empresa y contacto principal del responsable técnico o del administrador de la organización.

• Nombres e ID del Área de trabajo, la organización de la API y el proyecto de la API actuales y previstos, si se conocen.

• Nivel de Daybreak aprobado y controles visibles en Configuración del proyecto → General → Acceso a modelos de Daybreak, o la configuración guardada del Área de trabajo y de los roles.

• Alias de la API o ID de modelo exacto usado en la prueba.

• Si la solicitud usa una clave del proyecto habilitado y si las cargas de trabajo migradas se han actualizado para usar el proyecto de destino.

• Confirmación de que la configuración prevista no se usa para aplicaciones orientadas a clientes, tráfico de terceros ni flujos de trabajo de productos que integren Daybreak.

• Si el acceso de la configuración anterior debe eliminarse o revertirse.

• Si la nueva configuración plantea alguna duda sobre facturación, límites presupuestarios o responsabilidad comercial.

• El primer flujo de trabajo que el equipo prevé ejecutar, quiénes lo ejecutarán y la persona que lo revisará.

• Restricciones de plazos o una próxima sesión de puesta en marcha, si las hay.

Cuando están disponibles, los controles de proyecto aprobados permiten aislar el acceso a Daybreak por proyecto sin necesidad de una suborganización de la API independiente. Si los controles no están disponibles o la configuración aprobada sigue requiriendo una organización de la API dedicada, sigue las instrucciones del equipo de OpenAI que gestiona tu cuenta.

Si aún está pendiente eliminar una organización o un proyecto anterior, realizar una sustitución o corregir los permisos de acceso, considera que la configuración corregida no está lista hasta que se confirme el cambio.

Nota sobre el uso

El acceso a Daybreak debe limitarse a los usuarios internos autorizados y a las tareas de seguridad internas. El uso exclusivamente interno se refiere al trabajo de tu propio equipo autorizado, no al tráfico de clientes, a los servicios de seguridad ofrecidos a terceros ni a funciones de otros productos que canalicen solicitudes de terceros a través de Daybreak. Cuando los controles estén habilitados, usa los roles del Área de trabajo y los proyectos de la API de uso exclusivamente interno para hacer cumplir el ámbito aprobado.

Cuando los controles de proyecto aprobados estén disponibles, un proyecto de uso exclusivamente interno puede aislar el acceso a Daybreak dentro de una organización de la API que cumpla los requisitos, sin necesidad de una suborganización de la API independiente. Habilitar un proyecto no autoriza su uso de cara a clientes ni por parte de terceros.

Sin retención de datos (ZDR)

Cumplir los requisitos de acceso a Daybreak y habilitar un proyecto no activa automáticamente la opción sin retención de datos (ZDR). ZDR debe solicitarse y aprovisionarse por separado para la organización concreta de la API y el punto de acceso correspondiente. Si tu organización requiere ZDR u otro tratamiento específico de retención de datos, confirma que esas condiciones se aplican al tráfico del proyecto habilitado antes de que tu equipo inicie el primer flujo de trabajo. No des por hecho que activar el interruptor de Daybreak Blue o Daybreak Red de un proyecto cambia la configuración de retención de datos.

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.