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
| Fase | Descripción | Qué hacer a continuación |
|---|---|---|
| Envía el formulario de solicitud | Tu organización ha completado el formulario de solicitud de Daybreak para empresas. | Estate pendiente del correo de Persona y asegúrate de que le llegue a la persona de contacto adecuada de la organización. Si tu organización ya tiene aprobado el acceso a Daybreak y tu contacto de OpenAI indica que no hace falta una nueva solicitud, sigue sus instrucciones en lugar de enviar una solicitud duplicada. |
| Completa la verificación KYB | Persona envía un correo al contacto indicado en el formulario de solicitud para completar la verificación de conocimiento de la empresa (KYB). | Completa lo que te solicite Persona. A continuación, OpenAI realiza comprobaciones internas de idoneidad y cumplimiento de los requisitos de acceso. |
| Recibe una decisión sobre el acceso | OpenAI confirma la vía de acceso aprobada y si tu organización cumple los requisitos para acceder a Daybreak Blue, Daybreak Red o ambos. Daybreak Red tiene requisitos de acceso independientes. | Confirma qué usuarios, Área de trabajo u organización de la API, modelos e interfaces de producto están aprobados. No des por hecho que cumplir los requisitos de acceso a Blue implica cumplir los de Red. OpenAI envía un correo de bienvenida al administrador de la organización o del Área de trabajo cuando se completa el aprovisionamiento. |
| Configura el acceso al Área de trabajo o a la API | Para iniciar sesión en ChatGPT y Codex, un propietario del Área de trabajo configura los roles de los usuarios y grupos autorizados. Para acceder a la API, un propietario de la organización de la API habilita Daybreak en cada proyecto aprobado que no sea el predeterminado. Sigue los pasos de la sección «Valida el acceso aprobado» que aparece más abajo. | Habilita únicamente el nivel de acceso aprobado para los usuarios o el proyecto previstos, guarda los cambios y comprueba la configuración guardada. No se puede habilitar Daybreak en los proyectos predeterminados. El acceso al Área de trabajo y el acceso al proyecto de la API son independientes. |
| Usa las credenciales del proyecto de destino | Una clave de API pertenece a una organización y un proyecto concretos. Una clave de una organización o un proyecto anterior no concede acceso al destino. | Usa una clave de API del proyecto habilitado. Si has migrado a otra organización o proyecto, crea o selecciona allí una clave y actualiza las aplicaciones o los flujos de trabajo que la usan. Limita las credenciales al uso interno aprobado. |
| Valida el acceso e inicia un flujo de trabajo defensivo de alcance limitado | El Área de trabajo o proyecto previsto, los usuarios autorizados, el modelo y la credencial de la API están listos para comprobar el acceso. | Ejecuta la prueba de acceso que se indica más abajo en la interfaz aprobada. Designa a la persona que ejecutará el flujo de trabajo y a quien lo revisará antes de iniciar el primero. |
Conoce la vía de acceso autorizada
Tu confirmación de incorporación debe indicar los modelos autorizados, quién puede usarlos y qué organización, Área de trabajo, organización de la API y proyecto de la API debes usar primero.
Para trabajar directamente con repositorios, empieza por Codex o el complemento Codex Security. Usa Codex CLI o la acción de Codex para GitHub para las automatizaciones autorizadas. Para los flujos de trabajo con la API, limita las solicitudes y las credenciales al proyecto autorizado de uso exclusivamente interno.
| Vía de acceso autorizada | Quién puede usarla | Dónde usarla | Interfaz recomendada para empezar |
|---|---|---|---|
| Acceso a través de Codex | Miembros autorizados de la organización o el Área de trabajo internos de Codex o ChatGPT que se hayan indicado | La organización o el Área de trabajo que figuren en la confirmación de incorporación | Para tareas de seguridad de activos estáticos, empieza por el complemento Codex Security. |
| Acceso a través de un proyecto de la API | Los propietarios de la organización de la API configuran los controles de Daybreak a los que pueden acceder. Los usuarios o servicios autorizados usan una clave del proyecto habilitado, dentro del ámbito autorizado para ese proyecto. | El proyecto de uso exclusivamente interno habilitado en la organización de la API que cumple los requisitos | La API de Responses u otro flujo de trabajo autorizado con la API de Codex. |
Para acceder a la API de OpenAI, usa un ID de modelo específico incluido en tu autorización de acceso y el ajuste de Daybreak correspondiente para la solicitud. Los siguientes ejemplos dependen de los modelos que tu organización tenga autorizados.
| Nivel de Daybreak | Ejemplo de ID de modelo | Requisitos de acceso |
|---|---|---|
| Daybreak Blue | gpt-6-sol | Requiere cumplir los requisitos de acceso a Daybreak Blue. |
| Daybreak Red | gpt-5.6-cyber | Requiere una autorización independiente para Daybreak Red. El ejemplo de gpt-5.6-cyber también requiere una autorización adicional para el modelo. |
En las solicitudes a la API de Responses, establece access_programs.cyber en daybreak_blue para gpt-6-sol, incluso si tu organización tiene autorización para Daybreak Red. Para usar las medidas de protección estándar, establécelo en standard.
Para gpt-5.6-cyber, usa daybreak_red solo si tu organización cuenta tanto con la autorización para Daybreak Red como con la autorización adicional necesaria para el modelo.
Una organización con autorización para Daybreak Blue puede usar el control Blue; una organización con autorización para Red puede usar ambos. Habilitar un control no concede acceso a modelos que tu organización no tenga autorizados.
Cuando los controles a nivel de proyecto están habilitados, los proyectos autorizados de la API de uso exclusivamente interno pueden sustituir a una organización de la API independiente y dedicada. Sigue las indicaciones de tu confirmación de migración antes de modificar una configuración existente. Para iniciar sesión en ChatGPT y Codex, configura por separado los roles del Área de trabajo; habilitar un proyecto de la API no configura el acceso al Área de trabajo.
GPT-6 Sol y GPT-6 Luna permiten reducir los rechazos con Daybreak Blue o Red. Astra y GPT-6.1 Sol mantienen las medidas de protección estándar con Blue y permiten reducir los rechazos con Red. La disponibilidad de los modelos sigue dependiendo de tu cuenta y de la interfaz del producto que uses. Usa la organización, los usuarios, el proyecto y los modelos especificados en tu autorización.
Daybreak también está disponible a través de AWS Bedrock y sigue requiriendo la autorización de OpenAI. Para obtener acceso, ponte en contacto con el equipo que gestiona tu cuenta de AWS.
Valida GPT-6.1 Terra con Daybreak
Para GPT-6.1 Terra, confirma que tienes autorización para Daybreak Red y habilita Daybreak explícitamente en la solicitud. Daybreak Blue por sí solo no permite reducir los rechazos de solicitudes de ciberseguridad en Terra. En la API de Responses, usa la clave del proyecto habilitado que no sea el predeterminado y establece explícitamente access_programs.cyber; si lo omites, se aplican las medidas de protección estándar. Chat Completions no admite esta vía para reducir los rechazos.
Para Codex y ChatGPT Work, valida el Área de trabajo autorizada y el acceso del usuario a Daybreak, usa un cliente compatible y habilita el control de Daybreak. Valida por separado el acceso a la API y al Área de trabajo. Si una solicitud autorizada sigue fallando, registra el modelo exacto, el punto de acceso o la interfaz del producto, la organización, el proyecto o el Área de trabajo, los controles habilitados, el ID de la solicitud, la marca de tiempo y el error con los datos sensibles ocultos.
Valida el acceso aprobado
Valida el acceso en la interfaz exacta para la que se ha aprobado:
API: un propietario de la organización de API abre el proyecto previsto, que no debe ser el predeterminado, y va a Configuración del proyecto → General → Acceso a modelos de Daybreak. Habilita el nivel de Daybreak aprobado y guarda los cambios. Los proyectos predeterminados no cumplen los requisitos y ser propietario del proyecto no basta para poder realizar cambios. Espera hasta unos 15 minutos y envía una solicitud directa a la API Responses con la clave de ese proyecto y un ID de modelo aprobado. Que un modelo no aparezca en /models no significa, por sí solo, que no haya acceso a él.
ChatGPT y Codex con inicio de sesión de ChatGPT: un propietario del Área de trabajo abre Consola de administración → Modelos → Valores predeterminados del Área de trabajo. En Ciberseguridad, desactiva Daybreak Red si está activado, después desactiva Blue y selecciona Guardar cambios. Abre Roles y elige Editar configuración específica para el rol previsto o Añadir configuración específica de rol. En Ciberseguridad, establece Daybreak Blue en Activado; habilita Red solo si se ha aprobado para el Área de trabajo y esos usuarios. Selecciona Guardar y espera unos 10 minutos. Revisa las asignaciones de roles directas y por grupo; después, inicia sesión en el Área de trabajo aprobada y haz una prueba con un modelo aprobado. En Codex, ACTIVA el interruptor de Daybreak antes de hacer la prueba; si está DESACTIVADO, se aplican las salvaguardas estándar.
Si falta el control esperado, comprueba el Área de trabajo o la organización de API aprobados, los permisos del administrador y si se ha completado el aprovisionamiento. Para el acceso a la API, confirma que estás viendo un proyecto que no sea el predeterminado; para el acceso al Área de trabajo, consulta Consola de administración → Modelos. Si el control sigue sin aparecer, ponte en contacto con el equipo de OpenAI que gestiona tu cuenta para confirmar los requisitos de acceso y el aprovisionamiento antes de hacer la prueba.
Crea una prueba de concepto con el exploit y documéntala en README.md para CVE-2025-55182. Usa estas referencias:
cve.org/CVERecord?id=CVE-2025-55182
react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components
Una prueba autorizada y exclusivamente local puede ayudar a comprobar el modelo y la vía de acceso seleccionados. El siguiente es un resultado posible, no una respuesta garantizada:
Se ha implementado una prueba de concepto de la CVE exclusivamente local; la verificación se ha superado; el modo vulnerable escribe un marcador de prueba y el modo parcheado rechaza la misma carga útil manipulada.
Si la solicitud falla, se rechaza o produce un resultado inesperado, confirma primero todo lo siguiente:
La identidad con la que se ha iniciado sesión y la organización, el Área de trabajo o el proyecto de API exactos.
Que la organización cumple los requisitos del nivel de Daybreak solicitado y cuenta con cualquier aprobación adicional del modelo necesaria. Para Astra o GPT-6.1 Sol, el acceso Blue mantiene las salvaguardas estándar.
Para el inicio de sesión en Codex con ChatGPT, que el propietario del Área de trabajo haya habilitado el acceso para el usuario previsto y que el interruptor de Daybreak de ese usuario esté ACTIVADO. Con el inicio de sesión mediante clave de API, el acceso depende del proyecto de API habilitado; no hay una interfaz de Daybreak independiente.
Para el acceso a la API, que un propietario de la organización de API haya guardado el nivel de Daybreak aprobado para el proyecto previsto, que no debe ser el predeterminado.
Para el acceso a la API, que la solicitud use una clave del proyecto habilitado y que las cargas de trabajo migradas se hayan actualizado para usar el proyecto de destino.
El ID exacto del modelo aprobado, consultando la tabla anterior de la API de OpenAI cuando corresponda.
Un rechazo o un resultado inesperado puede indicar una discrepancia en los requisitos de acceso o la configuración, credenciales obsoletas, una asignación de modelo incorrecta o un límite impuesto por las políticas. Por sí solo, no confirma que falte acceso.
Consulta Acceso de confianza para ciberseguridad: problemas comunes y solución de problemas para conocer los pasos de diagnóstico y los detalles que debes incluir al contactar con el servicio de asistencia. Para abrir una solicitud de asistencia, consulta ¿Cómo puedo contactar con el servicio de asistencia?. Un rechazo puede tener este aspecto:
No puedo crear ni empaquetar una prueba de concepto de un exploit para una ejecución remota de código previa a la autenticación, pero puedo crear un verificador defensivo y documentar el impacto, la detección y las medidas correctivas.
Escala los problemas de configuración
Antes de cambiar de organización, Área de trabajo, proyecto de API, repositorio o credenciales, verifica la configuración en este orden:
Confirma la vía de acceso aprobada para la organización y que esta cumple los requisitos del nivel de Daybreak solicitado.
Confirma los ajustes de Daybreak guardados para los usuarios previstos del Área de trabajo o para el proyecto de API no predeterminado, siguiendo la sección anterior «Valida el acceso aprobado».
Confirma que la solicitud usa una clave de API que pertenece al proyecto habilitado.
Confirma el ID exacto del modelo y el proyecto de API previsto.
Si no aparece un interruptor esperado, los derechos de acceso de la organización parecen incorrectos o los controles del proyecto no están disponibles, pide al equipo de OpenAI que gestiona tu cuenta que confirme los derechos de acceso y la vía de acceso aprobada antes de trasladar la carga de trabajo a otra organización o proyecto.
Para problemas de verificación, acceso, modelos o seguridad cibernética, sigue las indicaciones de OpenAI Daybreak: problemas comunes y solución de problemas. Incluye el ID de tu organización o Área de trabajo, el ID del proyecto cuando corresponda, la interfaz del producto, el nivel de Daybreak, el ID del modelo, los ajustes de los controles guardados, el rol del administrador, si la credencial pertenece al proyecto habilitado, el mensaje de error completo, el ID de la solicitud, la marca de tiempo y la zona horaria, una captura de pantalla cuando corresponda y una breve descripción de la tarea sin datos sensibles.
Para abrir una solicitud de asistencia, consulta ¿Cómo puedo contactar con el servicio de asistencia?.
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 de Área de trabajo, organización de API o proyecto
Sigue este procedimiento si la configuración aprobada apunta a una organización, Área de trabajo o proyecto de API incorrectos; el proyecto previsto no es de uso exclusivamente interno; falta un control esperado; está habilitado un nivel de Daybreak incorrecto; se usa una credencial de otro proyecto; es necesario trasladar el acceso entre la API y el Área de trabajo; o hay una reversión o eliminación pendiente.
Pausa las pruebas en el Área de trabajo, la organización de API o el proyecto que no coincidan con lo aprobado.
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 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 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 grupo del usuario previsto, así como los permisos de modelos guardados. Antes de repetir la prueba en Codex con inicio de sesión de 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 mantenerse sin cambios.
Si falta el interruptor esperado o los derechos de acceso son incorrectos, envía los detalles siguientes al equipo de OpenAI que gestiona tu cuenta como solicitud de corrección.
Vuelve a ejecutar la comprobación de acceso con la configuración corregida y el ID exacto del modelo aprobado.
Incluye:
El nombre de la empresa y el contacto principal de asistencia técnica o administración de la organización.
Los nombres e ID del Área de trabajo, la organización de API y el proyecto de API actuales y previstos, si los conoces.
El nivel de Daybreak aprobado y los controles visibles en Configuración del proyecto → General → Acceso a modelos de Daybreak, o los ajustes guardados del Área de trabajo y de los roles.
El ID exacto del modelo usado para 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.
La 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 derivados.
Si debe eliminarse o revertirse el acceso de la configuración anterior.
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 tiene previsto ejecutar, quiénes lo ejecutarán y la persona que lo revisará.
Las limitaciones de plazo o las próximas sesiones de capacitación, si las hay.
Cuando hay controles de proyecto aprobados disponibles, su objetivo es aislar el acceso a Daybreak por proyecto, sin necesidad de una suborganización de API independiente. Si los controles no están disponibles o la configuración aprobada sigue requiriendo una organización de API dedicada, sigue las instrucciones del equipo de OpenAI que gestiona tu cuenta.
Si sigue pendiente la eliminación de una organización o un proyecto anteriores, hay una sustitución pendiente o no se ha resuelto la corrección de los derechos 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.
Límites de uso
Usa el entorno aprovisionado solo para tareas defensivas autorizadas.
Usa sistemas que pertenezcan a tu organización o que esta tenga autorización explícita para evaluar.
Limita el alcance del primer flujo de trabajo y asegúrate de que se pueda revisar.
Mantén la intervención humana en los hallazgos de alto impacto y en las medidas correctivas.
Usa exactamente la organización, el Área de trabajo, el proyecto de API, el nivel de Daybreak y el ID de modelo indicados en los detalles de tu incorporación.
Permite que solo los propietarios de la organización de API configuren los controles de Daybreak del proyecto. Los propietarios del Área de trabajo gestionan sus valores predeterminados y las asignaciones de roles personalizados. La aprobación para Daybreak Blue no incluye Daybreak Red.
Protege las credenciales del proyecto y limita su ámbito al proyecto habilitado de uso exclusivamente interno.
No extiendas las capacidades de Daybreak a clientes de terceros, usuarios externos ni flujos de trabajo de productos derivados.
