Visão geral

Utilize este guia se estiver a coordenar a integração da sua organização no Daybreak e precisar de passar da candidatura e da análise de elegibilidade para uma configuração pronta a utilizar.

O Daybreak Access é o programa de acesso de confiança para cibersegurança da OpenAI. O Daybreak Blue e o Daybreak Red são níveis de acesso do Daybreak.

A maioria das equipas 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 de cibersegurança avançados e autorizados. Alguns modelos de fronteira para cibersegurança requerem aprovação adicional específica para cada modelo.

A aprovação, por si só, não ativa a redução de recusas. Os controlos do Daybreak estão inicialmente DESATIVADOS. Um proprietário do espaço de trabalho ativa o acesso para os utilizadores e grupos aprovados; um proprietário da organização da API ativa-o para os projetos aprovados que não sejam predefinidos. Configure ambas as vias de acesso se a sua equipa utilizar as duas. Os utilizadores que iniciam sessão no Codex com o ChatGPT também têm de ativar o Daybreak antes de fazer um pedido.

Alguns fluxos de trabalho de maior risco podem continuar a ser recusados após a ativação do acesso, por isso comece por um fluxo de trabalho defensivo de âmbito limitado, exatamente na interface, no projeto e no modelo que a sua equipa pretende utilizar.

Acompanhe o estado da integração e do acesso

Compreender a via de acesso aprovada

A confirmação de adesão deve identificar os modelos aprovados, quem os pode utilizar e que organização, espaço de trabalho, organização da API e projeto da API deve utilizar primeiro.

Para fluxos de trabalho práticos em repositórios, comece pelo Codex ou pelo plugin Codex Security. Utilize a CLI do Codex ou a ação do Codex para GitHub para as automatizações aprovadas. Nos fluxos de trabalho com a API, limite os pedidos e as credenciais ao projeto aprovado para uso exclusivamente interno.

Para aceder à API da OpenAI, utilize um ID de modelo específico incluído no acesso aprovado e a definição de pedido do Daybreak correspondente. Os exemplos abaixo dependem dos modelos aprovados para a sua organização.

Nos pedidos à API Responses, defina access_programs.cyber como daybreak_blue para gpt-6-sol, mesmo que a sua organização tenha aprovação para o Daybreak Red. Para utilizar as salvaguardas padrão, defina o valor como standard.

Para gpt-5.6-cyber, utilize daybreak_red apenas se a sua organização tiver aprovação para o Daybreak Red e a aprovação adicional exigida para o modelo.

Uma organização aprovada para o Daybreak Blue pode utilizar o controlo Blue; uma organização aprovada para o Red pode utilizar ambos. Ativar um controlo não concede acesso a modelos não abrangidos pela aprovação da sua organização.

Quando os controlos ao nível do projeto estão ativados, os projetos da API aprovados para uso exclusivamente interno podem substituir uma organização da API dedicada e separada. Siga as instruções da confirmação de migração antes de alterar uma configuração existente. Para iniciar sessão no ChatGPT e no Codex, configure separadamente as funções do espaço de trabalho; ativar um projeto da API não configura o acesso ao espaço de trabalho.

O GPT-6 Sol e o GPT-6 Luna permitem reduzir as recusas com o Daybreak Blue ou Red. O Astra e o GPT-6.1 Sol mantêm as salvaguardas padrão com o Blue e permitem reduzir as recusas com o Red. A disponibilidade dos modelos continua a depender da sua conta e da interface do produto. Utilize a organização, os utilizadores, o projeto e os modelos especificados na sua aprovação.

O Daybreak também está disponível através do AWS Bedrock e continua a exigir aprovação da OpenAI. Contacte a equipa responsável pela sua conta AWS para obter acesso.

Validar o acesso aprovado

Valide o acesso na interface exata que foi aprovada:

• API: um proprietário da organização da API abre o projeto pretendido, que não pode ser o predefinido, e acede a Definições do projeto → Geral → Acesso a modelos do Daybreak. Ative o nível do Daybreak aprovado e guarde. Os projetos predefinidos não são elegíveis, e ser apenas proprietário do projeto não permite fazer alterações. Aguarde até cerca de 15 minutos e, em seguida, envie um pedido direto à API Responses com a chave desse projeto e um ID de modelo aprovado. A ausência de um modelo em /models não significa, por si só, que o acesso esteja indisponível.

• ChatGPT e Codex com início de sessão através do ChatGPT: um proprietário do espaço de trabalho abre Consola de administração → Modelos → Predefinição do espaço de trabalho. Em Cibersegurança, desative o Daybreak Red, caso esteja ativado, depois desative o Blue e selecione Guardar alterações. Abra Funções e escolha Editar substituição para a função pretendida ou Adicionar substituição de função. Em Cibersegurança, defina o Daybreak Blue como Ativado; ative o Red apenas se estiver aprovado para o espaço de trabalho e para esses utilizadores. Selecione Guardar e aguarde cerca de 10 minutos. Reveja as atribuições de funções diretas e por grupo e, em seguida, inicie sessão no espaço de trabalho aprovado e teste com um modelo aprovado. No Codex, coloque o interruptor do Daybreak em ATIVADO antes de testar; se estiver DESATIVADO, aplicam-se as salvaguardas padrão.

Se o controlo esperado não aparecer, verifique o espaço de trabalho ou a organização da API aprovado, as permissões do administrador e se o aprovisionamento está concluído. Para o acesso à API, confirme que está a visualizar um projeto que não é o predefinido; para o acesso ao espaço de trabalho, verifique Consola de administração → Modelos. Se o controlo continuar sem aparecer, contacte a equipa responsável pela sua conta OpenAI para confirmar a elegibilidade e o aprovisionamento antes de testar.

Crie uma prova de conceito com o exploit e, em seguida, documente-a em README.md para CVE-2025-55182. Utilize estas referências:

cve.org/CVERecord?id=CVE-2025-55182

react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components

Um teste autorizado, realizado apenas em ambiente local, pode ajudar a verificar o modelo e a via de acesso selecionados. Um resultado como o seguinte é uma possibilidade, não uma resposta garantida:

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

Se o pedido falhar, for recusado ou produzir um resultado inesperado, confirme primeiro todos os pontos seguintes:

• A identidade com sessão iniciada e a organização, o espaço de trabalho ou o projeto da API exato.

• A elegibilidade da organização para o nível do Daybreak solicitado e qualquer aprovação adicional para o modelo. No Astra ou no GPT-6.1 Sol, o acesso Blue mantém as salvaguardas padrão.

• No início de sessão no Codex através do ChatGPT, que o proprietário do espaço de trabalho ativou o acesso para o utilizador pretendido e que o interruptor do Daybreak desse utilizador está ATIVADO. Com o início de sessão por chave de API, o acesso é determinado pelo projeto da API ativado; não existe uma interface separada do Daybreak.

• Para o acesso à API, que um proprietário da organização da API guardou o nível do Daybreak aprovado para o projeto pretendido, que não pode ser o predefinido.

• Para o acesso à API, que o pedido utiliza uma chave do projeto ativado e que qualquer carga de trabalho migrada foi atualizada para utilizar o projeto de destino.

• O ID exato do modelo aprovado, utilizando a tabela da API da OpenAI acima, quando aplicável.

Uma recusa ou um resultado inesperado pode indicar uma discrepância na elegibilidade ou na configuração, credenciais desatualizadas, um mapeamento incorreto do modelo ou um limite imposto pelas políticas. Por si só, isso não confirma a falta de acesso.

Consulte Acesso de confiança para cibersegurança — Problemas comuns e resolução de problemas para saber que passos de diagnóstico seguir e que informações incluir ao contactar o Suporte. Para abrir um pedido de suporte, consulte Como posso contactar o suporte?. Uma recusa pode ter este aspeto:

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.

Encaminhar problemas de configuração

Antes de alterar organizações, espaços de trabalho, projetos da API, repositórios ou credenciais, verifique a configuração por esta ordem:

• Confirme a via de acesso aprovada para a organização e a sua elegibilidade para o nível do Daybreak solicitado.

• Confirme as definições do Daybreak guardadas para os utilizadores pretendidos do espaço de trabalho ou para o projeto da API não predefinido, seguindo a secção «Validar o acesso aprovado» acima.

• Confirme que o pedido utiliza uma chave de API pertencente ao projeto ativado.

• Confirme o ID exato do modelo e o projeto da API pretendido.

Se um interruptor esperado não estiver visível, a elegibilidade da organização parecer incorreta ou os controlos do projeto não estiverem disponíveis, peça à equipa responsável pela sua conta OpenAI que confirme a elegibilidade e a via de acesso aprovada antes de mover a carga de trabalho para outra organização ou projeto.

Para problemas de verificação, acesso, modelos ou segurança cibernética, consulte OpenAI Daybreak: problemas comuns e resolução de problemas. Inclua o ID da organização ou do espaço de trabalho, o ID do projeto quando aplicável, a interface do produto, o nível do Daybreak, o ID do modelo, as definições dos controlos guardadas, a função do administrador, se a credencial pertence ao projeto ativado, a mensagem de erro completa, o ID do pedido, a data e hora e o fuso horário, uma captura de ecrã quando aplicável e uma breve descrição da tarefa sem informações sensíveis.

Para abrir um pedido de suporte, consulte Como posso contactar o suporte?.

Inicie o primeiro fluxo de trabalho

Para a maioria das equipas, o primeiro fluxo de trabalho deve começar no plugin Codex Security, com um âmbito limitado de repositórios, ramos ou alertas. A Codex CLI é a via para automatizar à escala quando os responsáveis pelos fluxos de trabalho já têm um fluxo de CI/CD de confiança para validar. Para fluxos de trabalho da API, utilize o projeto aprovado de uso exclusivamente interno, o nível do Daybreak aprovado e a chave de API desse projeto.

Corrigir uma discrepância no espaço de trabalho, na organização da API ou no projeto

Siga este procedimento quando a configuração aprovada apontar para a organização, o espaço de trabalho ou o projeto da API errado; o projeto pretendido não for de uso exclusivamente interno; faltar um controlo esperado; estiver ativado o nível errado do Daybreak; estiver a ser utilizada uma credencial de outro projeto; for necessário transferir o acesso entre as vias da API e do espaço de trabalho; ou estiver pendente uma reversão ou remoção.

• Suspenda os testes no espaço de trabalho, na organização da API ou no projeto que apresenta a discrepância.

• Identifique a configuração atual e a configuração pretendida para uso exclusivamente interno.

• Para o acesso à API, peça a um proprietário da organização da API que siga os passos acima para verificar os controlos do Daybreak elegíveis para o projeto pretendido, que não pode ser o predefinido.

• Se o interruptor da API aprovado estiver visível, mas desativado, peça ao proprietário da organização da API que o ative e guarde a alteração. Para o acesso ao espaço de trabalho, peça a um proprietário do espaço de trabalho que reveja as funções diretas e por grupo do utilizador pretendido, bem como as permissões de modelos guardadas. Antes de voltar a testar no Codex com início de sessão através do ChatGPT, confirme que o interruptor do Daybreak do utilizador está ATIVADO.

• Para o acesso à API, utilize uma chave do projeto de destino ativado e aguarde até cerca de 15 minutos para que as alterações sejam aplicadas. Aguarde cerca de 10 minutos para que as alterações ao espaço de trabalho sejam aplicadas antes de voltar a testar.

• Confirme se a configuração anterior deve ser removida, revertida ou mantida sem alterações.

• Se o interruptor esperado não aparecer ou a elegibilidade estiver incorreta, envie as informações abaixo à equipa responsável pela sua conta OpenAI num pedido de correção.

• Volte a executar a verificação de acesso na configuração corrigida com o ID exato do modelo aprovado.

Inclua:

• O nome da empresa e o contacto principal do responsável técnico ou do administrador da organização.

• Os nomes e IDs dos espaços de trabalho, organizações da API e projetos da API atuais e pretendidos, se forem conhecidos.

• O nível do Daybreak aprovado e os controlos visíveis em Definições do projeto → Geral → Acesso a modelos do Daybreak, ou as definições guardadas do espaço de trabalho e das funções.

• O ID exato do modelo utilizado no teste.

• Se o pedido utiliza uma chave do projeto ativado e se as cargas de trabalho migradas foram atualizadas para utilizar o projeto de destino.

• A confirmação de que a configuração pretendida não é utilizada para aplicações destinadas a clientes, tráfego de terceiros ou fluxos de trabalho de produtos a jusante.

• Se o acesso na configuração anterior deve ser removido ou revertido.

• Se a nova configuração levanta alguma questão de faturação, de limites orçamentais ou de responsabilidade comercial.

• O primeiro fluxo de trabalho que a equipa planeia executar, quem deverá executá-lo e quem fará a revisão humana.

• Eventuais restrições de prazos ou sessões de capacitação agendadas.

Quando estão disponíveis controlos de projeto aprovados, estes destinam-se a isolar o acesso ao Daybreak por projeto, dispensando uma suborganização da API separada. Se os controlos não estiverem disponíveis ou a configuração aprovada continuar a exigir uma organização da API dedicada, siga as instruções da equipa responsável pela sua conta OpenAI.

Se a remoção de uma organização ou de um projeto anterior ainda estiver pendente, houver uma troca pendente ou a correção da elegibilidade não estiver resolvida, considere que a configuração corrigida não está pronta até que a alteração seja confirmada.

Nota sobre a utilização

O acesso ao Daybreak tem de ser restrito a utilizadores internos aprovados e a trabalho de segurança interno. O uso exclusivamente interno abrange o trabalho da sua própria equipa autorizada, não o tráfego de clientes, os serviços de segurança prestados externamente ou funcionalidades a jusante que encaminhem pedidos de terceiros através do Daybreak. Quando os controlos estiverem ativados, utilize as funções do espaço de trabalho e os projetos da API de uso exclusivamente interno para garantir o cumprimento do âmbito aprovado.

Quando estão disponíveis controlos de projeto aprovados, 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. Ativar um projeto não torna aceitável a utilização destinada a clientes ou por terceiros.

Retenção zero de dados (ZDR)

A elegibilidade para o Daybreak e a ativação do projeto não ativam automaticamente a retenção zero de dados (ZDR). A ZDR tem de ser solicitada e provisionada separadamente para a organização da API específica e o endpoint aplicável. Se a sua organização exigir ZDR ou outro tratamento específico de retenção de dados, confirme que o tráfego do projeto ativado está abrangido por esses termos antes de a sua equipa iniciar o primeiro fluxo de trabalho. Não assuma que ativar a opção Daybreak Blue ou Daybreak Red num projeto altera as definições de retenção de dados.

Limites de utilização

• Utilize a configuração disponibilizada apenas para trabalhos de defesa autorizados.

• Utilize sistemas que pertençam à sua organização ou que esta esteja explicitamente autorizada a avaliar.

• Mantenha o primeiro fluxo de trabalho limitado e passível de revisão.

• Garanta a supervisão humana dos resultados de elevado impacto e das medidas de correção.

• Utilize exatamente a organização, o espaço de trabalho, o projeto da API, o nível do Daybreak e o ID de modelo indicados nos seus dados de adesão.

• Permita que apenas os proprietários da organização da API configurem os controlos do Daybreak para o projeto. Os proprietários do espaço de trabalho gerem as predefinições do espaço de trabalho e as atribuições de funções personalizadas. A aprovação para o Daybreak Blue não inclui o Daybreak Red.

• Mantenha as credenciais do projeto seguras e limitadas ao projeto ativado para uso exclusivamente interno.

• Não disponibilize as capacidades do Daybreak a clientes terceiros, utilizadores externos ou fluxos de trabalho de produtos a jusante.