Como concluir o onboarding empresarial do Trusted Access, validar o acesso provisionado, corrigir problemas de organização ou workspace e se preparar para o primeiro fluxo de trabalho.

Visão geral

Use este guia se você estiver coordenando a integração ao Daybreak para sua organização e precisar avançar da coleta de informações e análise de elegibilidade até uma configuração pronta para uso.

O Daybreak Access é o programa Trusted Access for Cyber da OpenAI. Daybreak Blue e Daybreak Red são níveis de acesso. O programa inclui modelos, formas de acesso, Codex, Codex Security e serviços de suporte.

A maioria das equipes empresariais deve começar com o Daybreak Blue em fluxos de trabalho defensivos internos aprovados. O Daybreak Blue usa o alias de API gpt-daybreak-blue, associado ao ID de modelo gpt-5.6-sol.

O Daybreak Red usa o alias de API gpt-daybreak-red, associado ao ID de modelo gpt-5.6-cyber. O Daybreak Red exige elegibilidade separada e pode incluir somente os modelos especializados aprovados para a organização.

Os clientes que já têm aprovação para o GPT-5.5 com Trusted Access for Cyber devem continuar seguindo as instruções de acesso aprovadas.

A elegibilidade da sua organização determina quais controles do Daybreak podem aparecer na Plataforma de API. Quando os controles do projeto estiverem disponíveis, um administrador da organização deverá abrir Configurações do projeto → Limites, habilitar o Daybreak para o projeto de API elegível e exclusivamente interno e, depois, habilitar o modelo elegível específico. As configurações do projeto determinam a disponibilidade da API no projeto selecionado. Alguns comportamentos atuais do Trusted Access no nível da organização podem continuar durante a migração. Siga a confirmação de integração para saber o limite exato do acesso. Essas configurações se aplicam a projetos de API. Para acessar o Codex ou o ChatGPT, siga as instruções específicas da sua confirmação de integração.

Alguns fluxos de trabalho de maior risco ainda podem ser recusados após a habilitação do acesso. Portanto, comece com um fluxo defensivo bem delimitado usando exatamente a interface, o projeto e o modelo que sua equipe pretende usar.

Acompanhar o status da integração e do acesso

Fase	Descrição	Próxima etapa
Enviar o formulário inicial	Sua organização preencheu o formulário empresarial de adesão ao Daybreak.	Aguarde um e-mail da Persona e verifique se ele chega ao contato correto da organização. Se sua organização já tiver o Trusted Access aprovado e seu contato na OpenAI disser que não é necessário enviar um novo formulário, siga as instruções dele em vez de enviar uma solicitação duplicada.
Concluir a verificação KYB	A Persona envia um e-mail ao contato indicado no formulário para concluir a verificação Know Your Business (KYB).	Conclua a solicitação da Persona. Em seguida, a OpenAI realiza verificações internas de elegibilidade e adequação.
Receber uma decisão de elegibilidade	A OpenAI confirma a forma de acesso aprovada e se sua organização está qualificada para o Daybreak Blue, o Daybreak Red ou ambos. O Daybreak Red exige elegibilidade separada.	Confirme os usuários, a organização ou o Ambiente de trabalho seguro, a organização de API, os modelos e as interfaces de produto aprovados. Não presuma que a elegibilidade para o Blue implique elegibilidade para o Red.
Habilitar o Daybreak em um projeto de API	Quando os controles do projeto estiverem disponíveis para a organização de API elegível, um administrador da organização deverá abrir Configurações do projeto → Limites, habilitar o Daybreak para o projeto exclusivamente interno e, depois, habilitar o modelo elegível específico. Somente administradores da organização podem ver ou alterar essas configurações.	Habilite o Daybreak somente no projeto elegível e, depois, habilite apenas o modelo elegível específico necessário para esse projeto.
Atualizar as credenciais do projeto	Uma chave de API ou credencial existente pode não refletir o acesso recém-habilitado.	Após a habilitação, crie uma nova chave de API para o projeto ou atualize a credencial de projeto usada pelo serviço. Mantenha o escopo da credencial restrito ao projeto habilitado exclusivamente para uso interno.
Validar o acesso e iniciar um fluxo defensivo bem delimitado	A forma de acesso, o projeto e o modelo pretendidos, além de uma credencial nova, estão prontos para a verificação de acesso.	Execute a verificação de comprovação de acesso abaixo na interface aprovada. Defina quem executará e quem revisará o fluxo antes de iniciar o primeiro fluxo de trabalho.

Entender a forma de acesso aprovada

Sua confirmação de integração deve identificar os modelos aprovados, quem pode usá-los e qual organização, Ambiente de trabalho seguro, organização de API e projeto de API devem ser usados primeiro.

Para fluxos práticos em repositórios, comece com o Codex ou o plugin Codex Security. Use o Codex CLI ou a Codex GitHub Action para automações aprovadas. Para fluxos via API, mantenha as solicitações e credenciais restritas ao projeto aprovado exclusivamente interno.

Forma de acesso aprovada	Quem pode usar	Onde usar	Primeira interface recomendada
Acesso via Codex	Membros aprovados da organização ou do Ambiente de trabalho seguro interno indicado para o Codex ou o ChatGPT	A organização ou o Ambiente de trabalho seguro indicado na confirmação de integração	Para trabalhos de segurança em ativos estáticos, comece com o plugin Codex Security.
Acesso por um projeto de API	Os administradores da organização habilitam o Daybreak para o projeto elegível e, depois, habilitam o modelo elegível específico. Usuários ou serviços autenticados com uma credencial nova desse projeto podem usar o modelo habilitado para ele.	O projeto habilitado exclusivamente interno na organização de API elegível	A Responses API ou outro fluxo aprovado da API do Codex.

Use exatamente estes mapeamentos de API:

Nível de acesso ao Daybreak	Alias de API	ID do modelo	Elegibilidade
Daybreak Blue	`gpt-daybreak-blue`	`gpt-5.6-sol`	Exige elegibilidade para o Daybreak Blue.
Daybreak Red	`gpt-daybreak-red`	`gpt-5.6-cyber`	Exige elegibilidade separada para o Daybreak Red.

Quando os controles do projeto estiverem disponíveis, um administrador da organização deverá abrir Configurações do projeto → Limites, habilitar o Daybreak para o projeto elegível e, depois, habilitar o modelo elegível específico. Somente administradores da organização podem ver ou alterar essas configurações.

As configurações do projeto determinam a disponibilidade da API no projeto selecionado. Alguns comportamentos atuais do Trusted Access no nível da organização podem continuar durante a migração. Siga a confirmação de integração para saber o limite exato do acesso. Se os controles não estiverem presentes ou a configuração aprovada ainda exigir uma organização de API dedicada, siga exatamente as instruções do seu contato na OpenAI antes de testar. Não presuma que os controles do projeto de API alterem o acesso ao Codex ou ao ChatGPT.

Para o Daybreak Blue e o GPT-5.5 existente com Trusted Access for Cyber, o acesso pelo Ambiente de trabalho seguro se aplica à organização indicada do Codex ou ChatGPT, enquanto o acesso via API se aplica à organização de API e ao projeto habilitado indicados, conforme especificado na aprovação. O Daybreak Red exige elegibilidade separada e pode ter requisitos adicionais específicos do modelo ou do usuário. Siga exatamente as instruções da sua aprovação referentes à organização, ao usuário, ao projeto, ao modelo e à interface do produto.

Validar o acesso aprovado

Valide o acesso exatamente na interface aprovada:

API: primeiro, um administrador da organização deve abrir Configurações do projeto → Limites, habilitar o Daybreak para o projeto elegível e exclusivamente interno e, depois, habilitar o modelo elegível específico. Após a habilitação, crie uma nova chave de API para esse projeto ou atualize a credencial de projeto usada pelo seu serviço. Execute o prompt abaixo pelo fluxo de API aprovado usando o alias de API ou o ID de modelo correspondente.
Codex ou ChatGPT: entre exatamente na organização ou no Ambiente de trabalho seguro exclusivamente interno indicado na confirmação de integração e siga as instruções sobre modelos e usuários apresentadas nessa confirmação.

Se os controles do projeto de API não estiverem visíveis, não conclua que o acesso está habilitado. Antes de testar, confirme com seu contato na OpenAI a elegibilidade da organização e a disponibilidade atual dos controles.

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

cve.org/CVERecord?id=CVE-2025-55182
react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components

A verificação de acesso é bem-sucedida quando o GPT-5.5 conclui a prova de conceito delimitada e apenas local com restrições de segurança, arquivos locais e um resultado de verificação como:

Implementou uma prova de conceito de CVE apenas local; a verificação passou; o modo vulnerável grava um marcador de prova e o modo corrigido rejeita o mesmo payload criado.

Se o prompt for recusado ou não produzir o resultado delimitado esperado, primeiro confirme todos os itens a seguir:

A identidade conectada e a organização, o Ambiente de trabalho seguro ou o projeto de API exato.
A elegibilidade da organização para o nível de acesso ao Daybreak solicitado.
Para acesso via API, confirme que um administrador da organização habilitou o Daybreak para o projeto elegível em Configurações do projeto → Limites e, depois, habilitou o modelo elegível específico.
Para acesso via API, confirme que a solicitação usa uma nova chave de API ou uma credencial atualizada do projeto habilitado.
O mapeamento exato da API: gpt-daybreak-blue ou gpt-5.6-sol para o Blue e gpt-daybreak-red ou gpt-5.6-cyber para o acesso Red com elegibilidade separada.

Uma recusa ou um resultado inesperado pode indicar incompatibilidade de elegibilidade ou configuração, credenciais desatualizadas, mapeamento incorreto do modelo ou um limite de política. Isso, por si só, não confirma que o acesso esteja ausente.

Consulte Trusted Access for Cyber — Problemas comuns e solução de problemas para ver as etapas de diagnóstico e os detalhes que devem ser incluídos ao entrar em contato com o suporte. Para abrir uma solicitação de suporte, consulte Como posso entrar em contato com o suporte?. Uma recusa pode ter esta aparência:

Não posso criar nem empacotar uma prova de conceito de exploit para um RCE pré-autenticação, mas posso criar um verificador defensivo e documentar impacto, detecção e remediação.

Encaminhar problemas de configuração

Antes de alterar organizações, Ambientes de trabalho seguros, projetos de API, repositórios ou credenciais, verifique a configuração nesta ordem:

Confirme a forma de acesso aprovada da organização e sua elegibilidade para o nível de acesso ao Daybreak solicitado.
Para acesso via API, peça a um administrador da organização que confirme se o Daybreak está habilitado em Configurações do projeto → Limites no projeto elegível e se o modelo elegível específico também está habilitado.
Confirme se a solicitação usa uma nova chave de API ou uma credencial de projeto atualizada e criada após a habilitação.
Confirme o alias ou ID de modelo exato e o projeto de API pretendido.

Se uma configuração esperada do Daybreak ou do modelo não estiver visível, a elegibilidade da organização parecer incorreta ou os controles do projeto não estiverem disponíveis, peça à equipe de conta da OpenAI que confirme a elegibilidade e a forma de acesso aprovada antes de transferir a carga de trabalho para outra organização ou projeto.

Para problemas de verificação, acesso, modelo ou segurança cibernética, consulte Trusted Access for Cyber — Problemas comuns e solução de problemas. Inclua o ID da organização; o ID do projeto, quando aplicável; a interface do produto; o nível de acesso ao Daybreak; o alias de API ou ID de modelo; o status das configurações de projeto e modelo do Daybreak; se um administrador da organização verificou a configuração; se as credenciais foram criadas ou atualizadas após a habilitação; a mensagem de erro completa; o ID da solicitação; a data, hora e o fuso horário; uma captura de tela, quando aplicável; e uma breve descrição editada da tarefa, sem dados confidenciais.

Para abrir uma solicitação de suporte, consulte Como posso entrar em contato com o suporte?.

Iniciar 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 de automação em escala quando os responsáveis pelo fluxo já têm um fluxo de CI/CD confiável que precisam validar. Para um fluxo via API, use o projeto aprovado exclusivamente interno, o nível elegível de acesso ao Daybreak e uma credencial de projeto nova.

Corrigir uma incompatibilidade de Ambiente de trabalho seguro, organização de API ou projeto

Use este procedimento quando a configuração aprovada apontar para a organização, o Ambiente de trabalho seguro ou o projeto de API incorreto; o projeto pretendido não for exclusivamente interno; o controle de elegibilidade esperado estiver ausente; o nível de acesso ao Daybreak ou o modelo incorreto estiver habilitado; uma credencial desatualizada ou de outro projeto estiver em uso; o acesso precisar ser transferido entre os caminhos de API e Ambiente de trabalho seguro; ou houver uma reversão ou remoção pendente.

Pause os testes no Ambiente de trabalho seguro, na organização de API ou no projeto incompatível.
Identifique a configuração atual e a configuração pretendida exclusivamente interna.
Para acesso via API, peça a um administrador da organização que abra a página Configurações do projeto → Limites do projeto pretendido e verifique se o Daybreak e o modelo elegível específico estão disponíveis.
Se o Daybreak estiver disponível, mas desabilitado, peça ao administrador da organização que o habilite para o projeto e, depois, habilite o modelo elegível específico.
Após a habilitação, crie uma nova chave de API para esse projeto ou atualize a credencial de projeto usada pelo serviço.
Confirme se a configuração antiga deve ser removida, revertida ou mantida sem alterações.
Se o controle esperado estiver ausente ou a elegibilidade estiver incorreta, envie os detalhes abaixo à equipe de conta da OpenAI como uma solicitação de correção.
Execute novamente a verificação de comprovação de acesso na configuração corrigida usando exatamente o alias ou ID de modelo aprovado.

Inclua:

Nome da empresa e contato técnico principal ou administrador principal da organização.
Nomes e IDs atuais e pretendidos do Ambiente de trabalho seguro, da organização de API e do projeto de API, se conhecidos.
Nível de acesso ao Daybreak aprovado e as configurações do Daybreak e do modelo visíveis em Configurações do projeto → Limites.
Alias de API ou ID de modelo exato usado no teste.
Se uma nova chave de API foi criada ou se a credencial do projeto foi atualizada após a habilitação.
Confirmação de que a configuração pretendida não é usada em aplicativos voltados a clientes, tráfego de terceiros ou fluxos de produtos subsequentes.
Se o acesso deve ser removido ou revertido na configuração anterior.
Se a nova configuração gera dúvidas sobre faturamento, limite de orçamento ou responsável comercial.
O primeiro fluxo que a equipe pretende executar, quem deverá executá-lo e o revisor humano.
Restrições de prazo ou uma próxima sessão de habilitação, se houver.

As configurações do projeto determinam a disponibilidade da API no projeto selecionado. Alguns comportamentos atuais do Trusted Access no nível da organização podem continuar durante a migração. Siga a confirmação de integração para saber o limite exato do acesso. Se os controles não estiverem disponíveis ou a configuração aprovada ainda exigir uma organização de API dedicada, siga as instruções da equipe de conta da OpenAI.

Se ainda estiver pendente a remoção de uma organização ou projeto antigo, uma troca estiver em andamento ou a correção de elegibilidade não tiver sido resolvida, considere que a configuração corrigida ainda não está pronta até que a alteração seja confirmada.

Observação sobre o uso

Qualquer Ambiente de trabalho seguro, organização de API ou projeto de API habilitado para o Daybreak deve ser exclusivamente interno. Exclusivamente interno significa que o acesso é usado pela própria equipe autorizada da sua organização em trabalhos defensivos e não está vinculado a tráfego voltado a clientes, serviços de segurança oferecidos externamente nem a qualquer recurso subsequente de produto que encaminhe solicitações ou conteúdo de terceiros por esse acesso.

As configurações do projeto determinam a disponibilidade da API no projeto exclusivamente interno selecionado. Alguns comportamentos atuais do Trusted Access no nível da organização podem continuar durante a migração. Siga a confirmação de integração para saber o limite exato do acesso. Habilitar um projeto não torna aceitável o uso voltado a clientes ou por terceiros.

Zero retenção de dados (ZDR)

A elegibilidade para o Daybreak e a habilitação do projeto não ativam automaticamente a zero retenção de dados (ZDR). A ZDR deve ser solicitada e provisionada separadamente para a organização de API exata 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 que sua equipe inicie o primeiro fluxo de trabalho. Não presuma que habilitar o Daybreak ou um modelo específico para um projeto altere as configurações de retenção de dados.

Limites operacionais

Use a configuração provisionada somente em trabalhos defensivos autorizados.
Use sistemas que pertençam à sua organização ou que ela tenha autorização explícita para avaliar.
Mantenha o primeiro fluxo de trabalho restrito e passível de revisão.
Mantenha a supervisão humana para descobertas e correções de alto impacto.
Use exatamente a organização, o Ambiente de trabalho seguro, o projeto de API, o nível de acesso ao Daybreak, o alias de API ou o ID de modelo indicados nos detalhes da sua integração.
Permita que somente administradores da organização alterem as configurações de projeto e modelo do Daybreak e não presuma que a elegibilidade para o Daybreak Blue implique elegibilidade para o Daybreak Red.
Mantenha seguras as credenciais de projeto recém-criadas ou atualizadas e restrinja seu escopo ao projeto habilitado exclusivamente para uso interno.
Não estenda os recursos do Daybreak a clientes de terceiros, usuários externos ou fluxos de produtos subsequentes.

Integração empresarial ao Daybreak