Visão geral
Use este guia se você estiver coordenando a integração da sua organização ao Daybreak e precisar avançar da inscrição e da análise de elegibilidade para uma configuração pronta para uso.
O Daybreak Access é o programa de acesso confiável para cibersegurança da OpenAI. Daybreak Blue e Daybreak Red são níveis de acesso do Daybreak.
A maioria das equipes empresariais deve começar pelo Daybreak Blue para fluxos de trabalho defensivos internos aprovados.
O Daybreak Red requer aprovação separada para fluxos de trabalho avançados e autorizados de cibersegurança. Alguns modelos de fronteira para cibersegurança requerem aprovação adicional específica para o modelo.
A aprovação, por si só, não ativa a redução de recusas. Os controles do Daybreak ficam inicialmente DESATIVADOS. Um proprietário do espaço de trabalho habilita o acesso para usuários e grupos aprovados; um proprietário da organização da API habilita o acesso para projetos aprovados que não sejam o projeto padrão. Configure ambas as formas de acesso se sua equipe usar as duas. Os usuários que fazem login no Codex com o ChatGPT também devem ativar o Daybreak antes de fazer uma solicitação.
Alguns fluxos de trabalho de maior risco ainda podem ser recusados após a habilitação do acesso. Por isso, comece com um fluxo defensivo de escopo delimitado, exatamente na interface, no projeto e no modelo que sua equipe planeja usar.
Acompanhe o status da integração e do acesso
| Fase | Descrição | Próximos passos |
|---|---|---|
| Envie o formulário de inscrição | Sua organização preencheu o formulário de inscrição empresarial no Daybreak. | Fique atento a um e-mail da Persona e certifique-se de que ele chegue ao contato correto da organização. Se sua organização já tiver acesso aprovado ao Daybreak e seu contato na OpenAI disser que não é necessária uma nova inscrição, siga as instruções dele em vez de enviar uma solicitação duplicada. |
| Conclua a verificação KYB | A Persona envia um e-mail ao contato indicado no formulário de inscrição para concluir a verificação Conheça sua Empresa (KYB). | Conclua a solicitação da Persona. Em seguida, a OpenAI realiza verificações internas de elegibilidade e adequação. |
| Receba uma decisão sobre a elegibilidade | A OpenAI confirma a forma de acesso aprovada e se sua organização é elegível para o Daybreak Blue, o Daybreak Red ou ambos. O Daybreak Red requer elegibilidade separada. | Confirme os usuários, o espaço de trabalho ou a organização da API, os modelos e as interfaces do produto aprovados. Não presuma que a elegibilidade para o Blue inclui a elegibilidade para o Red. A OpenAI envia um e-mail de boas-vindas ao administrador da organização ou do espaço de trabalho quando o provisionamento é concluído. |
| Configure o acesso ao espaço de trabalho ou à API | Para login no ChatGPT e no Codex, um proprietário do espaço de trabalho configura funções para usuários e grupos aprovados. Para acesso à API, um proprietário da organização da API habilita o Daybreak em cada projeto aprovado que não seja o projeto padrão. Siga as etapas em "Valide o acesso aprovado" abaixo. | Habilite apenas o nível de acesso aprovado para os usuários ou o projeto pretendidos, salve e verifique as configurações salvas. Não é possível habilitar o Daybreak em projetos padrão. O acesso ao espaço de trabalho e o acesso ao projeto da API são separados. |
| Use as credenciais do projeto de destino | Uma chave de API pertence a uma organização e a um projeto específicos. Uma chave de uma organização ou projeto antigo não concede acesso ao destino. | Use uma chave de API do projeto habilitado. Se você migrou para outra organização ou projeto, crie ou selecione uma chave nesse destino e atualize os aplicativos ou fluxos de trabalho que a utilizam. Mantenha as credenciais restritas ao uso interno aprovado. |
| Valide o acesso e inicie um fluxo de trabalho defensivo de escopo delimitado | O espaço de trabalho ou projeto pretendido, os usuários aprovados, o modelo e a credencial da API estão prontos para uma verificação de acesso. | Execute o teste de comprovação de acesso abaixo na interface aprovada. Defina os responsáveis pela execução e pela revisão antes de iniciar o primeiro fluxo de trabalho. |
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?.
Inicie o primeiro fluxo de trabalho
Para a maioria das equipes, o primeiro fluxo de trabalho deve começar no plugin Codex Security, com um escopo restrito de repositório, branch ou alerta. O Codex CLI é a opção para automação em escala quando os responsáveis pelo fluxo de trabalho já têm um fluxo de CI/CD confiável para validar. Para fluxos de trabalho via API, use o projeto aprovado de uso exclusivamente interno, o nível aprovado do Daybreak e a chave de API desse projeto.
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.
Observação sobre o uso
O acesso ao Daybreak deve ser restrito a usuários internos aprovados e a trabalhos internos de segurança. Uso exclusivamente interno significa o trabalho da sua própria equipe autorizada, não tráfego voltado a clientes, serviços de segurança oferecidos externamente ou recursos de outros produtos que encaminhem solicitações de terceiros pelo Daybreak. Quando os controles estiverem habilitados, use funções do espaço de trabalho e projetos da API de uso exclusivamente interno para garantir o cumprimento do escopo aprovado.
Quando os controles de projeto aprovados estão disponíveis, um projeto de uso exclusivamente interno pode isolar o acesso ao Daybreak dentro de uma organização da API elegível, sem exigir uma suborganização da API separada. Habilitar um projeto não torna aceitável o uso voltado a clientes ou a terceiros.
Zero retenção de dados (ZDR)
A elegibilidade para o Daybreak e a habilitação do projeto não habilitam automaticamente a zero retenção de dados (ZDR). A ZDR deve ser solicitada e provisionada separadamente para a organização da API específica e o endpoint aplicável. Se sua organização exigir ZDR ou outro tratamento específico de retenção de dados, confirme se o tráfego do projeto habilitado está coberto por esses termos antes de sua equipe iniciar o primeiro fluxo de trabalho. Não presuma que ativar a opção Daybreak Blue ou Daybreak Red de um projeto altera as configurações de retenção de dados.
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.