Como concluir a integração empresarial no Acesso de Confiança, validar o acesso aprovisionado, corrigir problemas de organização ou espaço de trabalho e preparar o primeiro fluxo de trabalho.

Visão geral

Utilize este guia se estiver a coordenar a integração no Daybreak para a sua organização e precisar de avançar desde a recolha de dados e a análise da elegibilidade até 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. O programa inclui modelos, vias de acesso, o Codex, o Codex Security e serviços de apoio.

A maioria das equipas empresariais deve começar pelo Daybreak Blue para fluxos de trabalho defensivos internos aprovados. O Daybreak Blue utiliza o alias de API gpt-daybreak-blue, que corresponde ao ID de modelo gpt-5.6-sol.

O Daybreak Red utiliza o alias de API gpt-daybreak-red, que corresponde ao ID de modelo gpt-5.6-cyber. O Daybreak Red exige uma elegibilidade distinta e pode incluir apenas os modelos especializados aprovados para a organização.

Os clientes que já tenham aprovação para o GPT-5.5 com Acesso de Confiança para Cibersegurança devem continuar a seguir as instruções de acesso aprovadas.

A elegibilidade da sua organização determina que controlos do Daybreak podem ser apresentados na Plataforma de API. Quando os controlos do projeto estiverem disponíveis, um administrador da organização abre Definições do projeto → Limites, ativa o Daybreak no projeto de API elegível e exclusivamente interno e, depois, ativa o modelo elegível específico. As definições do projeto determinam a disponibilidade da API para o projeto selecionado. Algum comportamento existente do Acesso de Confiança ao nível da organização pode manter-se durante a migração; consulte a confirmação de integração para conhecer os limites exatos do acesso. Estas definições aplicam-se a projetos de API; para aceder ao Codex ou ao ChatGPT, siga as instruções específicas incluídas na confirmação de integração.

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 defensivo bem delimitado, utilizando exatamente a interface, o projeto e o modelo que a sua equipa pretende usar.

Acompanhar o estado da integração e do acesso

Fase	Descrição	Passo seguinte
Enviar o formulário de admissão	A sua organização preencheu o formulário empresarial de admissão ao Daybreak.	Esteja atento a uma mensagem de correio eletrónico da Persona e certifique-se de que esta chega ao contacto correto da organização. Se a sua organização já tiver um Acesso de Confiança aprovado e o seu contacto na OpenAI indicar que não é necessário um novo processo de admissão, siga as respetivas instruções em vez de enviar um pedido duplicado.
Concluir a verificação KYB	A Persona envia uma mensagem de correio eletrónico ao contacto indicado no formulário de admissão para concluir a verificação Know Your Business (KYB).	Conclua o pedido da Persona. Em seguida, a OpenAI realiza verificações internas de elegibilidade e adequação.
Receber uma decisão sobre a elegibilidade	A OpenAI confirma a via de acesso aprovada e se a sua organização é elegível para o Daybreak Blue, o Daybreak Red ou ambos. O Daybreak Red exige uma elegibilidade distinta.	Confirme os utilizadores aprovados, a organização ou o espaço de trabalho, a organização de API, os modelos e as interfaces dos produtos. Não deduza a elegibilidade para o Red a partir da elegibilidade para o Blue.
Ativar o Daybreak num projeto de API	Quando os controlos do projeto estiverem disponíveis para a organização de API elegível, um administrador da organização abre Definições do projeto → Limites, ativa o Daybreak no projeto exclusivamente interno e, depois, ativa o modelo elegível específico. Apenas os administradores da organização podem ver ou alterar estas definições.	Ative o Daybreak apenas no projeto elegível e, depois, ative 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-ativado.	Após a ativação, crie uma nova chave de API para o projeto ou atualize a credencial do projeto utilizada pelo serviço. Mantenha a credencial restrita ao projeto exclusivamente interno que foi ativado.
Validar o acesso e iniciar um fluxo de trabalho defensivo bem delimitado	A via de acesso, o projeto e o modelo pretendidos, bem como uma credencial recente, estão prontos para uma verificação de acesso.	Execute a verificação de acesso abaixo na interface aprovada. Antes de iniciar o primeiro fluxo de trabalho, identifique o respetivo operador e revisor.

Compreender a via de acesso aprovada

A confirmação de integração deve identificar os modelos aprovados, quem pode utilizá-los e que organização, espaço de trabalho, organização de API e projeto de API deve utilizar primeiro.

Para fluxos de trabalho práticos em repositórios, comece pelo Codex ou pelo plug-in Codex Security. Utilize a CLI do Codex ou a Codex GitHub Action para automatizações aprovadas. Para fluxos de trabalho de API, restrinja os pedidos e as credenciais ao projeto exclusivamente interno aprovado.

Via de acesso aprovada	Quem pode utilizar	Onde utilizar	Primeira interface recomendada
Acesso através do Codex	Membros aprovados da organização ou do espaço de trabalho interno do Codex ou ChatGPT indicado	A organização ou o espaço de trabalho indicado na confirmação de integração	Para trabalhos de segurança em ativos estáticos, comece pelo plug-in Codex Security.
Acesso através de um projeto de API	Os administradores da organização ativam o Daybreak no projeto elegível e, depois, ativam o modelo elegível específico. Os utilizadores ou serviços autenticados com uma credencial recente desse projeto podem utilizar o modelo nele ativado.	O projeto exclusivamente interno ativado na organização de API elegível	A Responses API ou outro fluxo de trabalho aprovado da API do Codex.

Utilize exatamente estes mapeamentos de API:

Nível de acesso do Daybreak	Alias de API	ID de 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 distinta para o Daybreak Red.

Quando os controlos do projeto estiverem disponíveis, um administrador da organização abre Definições do projeto → Limites, ativa o Daybreak no projeto elegível e, depois, ativa o modelo elegível específico. Apenas os administradores da organização podem ver ou alterar estas definições.

As definições do projeto determinam a disponibilidade da API para o projeto selecionado. Algum comportamento existente do Acesso de Confiança ao nível da organização pode manter-se durante a migração; consulte a confirmação de integração para conhecer os limites exatos do acesso. Se os controlos não estiverem presentes ou se a configuração aprovada ainda exigir uma organização de API dedicada, siga exatamente as instruções do seu contacto na OpenAI antes de efetuar testes. Não presuma que os controlos do projeto de API alteram o acesso ao Codex ou ao ChatGPT.

Para o Daybreak Blue e o GPT-5.5 existente com Acesso de Confiança para Cibersegurança, o acesso pelo espaço de trabalho aplica-se à organização indicada do Codex ou ChatGPT, enquanto o acesso por API se aplica à organização de API indicada e ao projeto ativado, conforme especificado na aprovação. O Daybreak Red exige uma elegibilidade distinta e pode ter requisitos adicionais específicos do modelo ou ao nível do utilizador. Siga exatamente as instruções da sua aprovação relativas à organização, ao utilizador, 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 Definições do projeto → Limites, ativar o Daybreak no projeto elegível e exclusivamente interno e, depois, ativar o modelo elegível específico. Após a ativação, crie uma nova chave de API para esse projeto ou atualize a credencial do projeto utilizada pelo seu serviço. Execute o prompt abaixo através do fluxo de trabalho de API aprovado, utilizando o alias de API ou o ID de modelo correspondente.
Codex ou ChatGPT: inicie sessão exatamente na organização ou no espaço de trabalho exclusivamente interno indicado na confirmação de integração e siga as instruções relativas ao modelo e aos utilizadores nessa confirmação.

Se os controlos do projeto de API não estiverem visíveis, não presuma que o acesso está ativo. Antes de efetuar testes, confirme junto do seu contacto na OpenAI a elegibilidade da organização e a disponibilidade atual dos controlos.

Crie uma prova de conceito com a exploração e 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

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

Implementada uma prova de conceito de CVE apenas local; a verificação passou; o modo vulnerável escreve um marcador de prova e o modo corrigido rejeita a mesma carga útil criada.

Se o prompt for recusado ou não produzir o resultado delimitado esperado, comece por confirmar todos os seguintes pontos:

A identidade com sessão iniciada e a organização, o espaço de trabalho ou o projeto de API exatos.
A elegibilidade da organização para o nível de acesso do Daybreak solicitado.
Para acesso por API, confirme que um administrador da organização ativou o Daybreak para o projeto elegível em Definições do projeto → Limites e, depois, ativou o modelo elegível específico.
Para acesso por API, confirme que o pedido utiliza uma nova chave de API ou uma credencial atualizada do projeto ativado.
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 distinta.

Uma recusa ou um resultado inesperado pode indicar uma incompatibilidade de elegibilidade ou configuração, credenciais desatualizadas, um mapeamento incorreto do modelo ou um limite imposto pela política. Por si só, isso não confirma que o acesso esteja em falta.

Consulte Acesso de Confiança para Cibersegurança — Problemas comuns e resolução de problemas para conhecer os passos de diagnóstico e os dados a incluir ao contactar o Suporte. Para abrir um pedido junto do Suporte, consulte Como posso contactar o suporte?. Uma recusa pode ter o seguinte aspeto:

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

Encaminhar problemas de configuração

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

Confirme a via de acesso aprovada da organização e a elegibilidade para o nível de acesso do Daybreak solicitado.
Para acesso por API, peça a um administrador da organização que confirme se o Daybreak está ativo em Definições do projeto → Limites para o projeto elegível e se o modelo elegível específico também está ativo.
Confirme que o pedido utiliza uma nova chave de API ou uma credencial de projeto atualizada, criada após a ativação.
Confirme o alias ou ID de modelo exato e o projeto de API pretendido.

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

Para problemas de verificação, acesso, modelo ou cibersegurança, consulte Acesso de Confiança para Cibersegurança — Problemas comuns e resoluçã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 do Daybreak, o alias de API ou ID de modelo, o estado das definições de projeto e modelo do Daybreak, se um administrador da organização verificou a definição, se as credenciais foram criadas ou atualizadas após a ativação, a mensagem de erro completa, o ID do pedido, a data e hora com o fuso horário, uma captura de ecrã quando aplicável e uma breve descrição expurgada da tarefa.

Para abrir um pedido junto do Suporte, consulte Como posso contactar o suporte?.

Iniciar o primeiro fluxo de trabalho

Para a maioria das equipas, o primeiro fluxo de trabalho deve começar no plug-in Codex Security, com um âmbito restrito a um repositório, ramo ou alerta. A CLI do Codex é a via de automatização à escala quando os responsáveis pelo fluxo de trabalho já dispõem de um fluxo CI/CD de confiança que precisam de validar. Para um fluxo de trabalho de API, utilize o projeto exclusivamente interno aprovado, o nível de acesso elegível do Daybreak e uma credencial de projeto recente.

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

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

Suspenda os testes no espaço de trabalho, na organização de API ou no projeto incompatível.
Identifique a configuração atual e a configuração exclusivamente interna pretendida.
Para acesso por API, peça a um administrador da organização que abra a página Definiçõ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 desativado, peça ao administrador da organização que o ative no projeto e que, depois, ative o modelo elegível específico.
Após a ativação, crie uma nova chave de API para esse projeto ou atualize a credencial do projeto utilizada pelo serviço.
Confirme se a configuração antiga deve ser removida, revertida ou mantida sem alterações.
Se o controlo esperado estiver em falta ou a elegibilidade estiver incorreta, envie os dados abaixo à equipa de conta da OpenAI como pedido de correção.
Volte a executar a verificação de acesso na configuração corrigida, utilizando exatamente o alias ou ID de modelo aprovado.

Inclua:

Nome da empresa e contacto técnico principal ou administrador principal da organização.
Nomes e IDs atuais e pretendidos do espaço de trabalho, da organização de API e do projeto de API, caso sejam conhecidos.
Nível de acesso do Daybreak aprovado e definições do Daybreak e do modelo visíveis em Definições do projeto → Limites.
Alias de API ou ID de modelo exato utilizado no teste.
Se foi criada uma nova chave de API ou atualizada a credencial do projeto após a ativação.
Confirmação de que a configuração pretendida não é utilizada em aplicações dirigidas a clientes, tráfego de terceiros ou fluxos de trabalho de produtos a jusante.
Se o acesso deve ser removido ou revertido na configuração anterior.
Se a nova configuração suscita questões de faturação, limite orçamental ou responsabilidade comercial.
O primeiro fluxo de trabalho que a equipa tenciona executar, bem como os operadores previstos e o revisor humano.
Restrições de calendário ou uma próxima sessão de ativação, caso existam.

As definições do projeto determinam a disponibilidade da API para o projeto selecionado. Algum comportamento existente do Acesso de Confiança ao nível da organização pode manter-se durante a migração; consulte a confirmação de integração para conhecer os limites exatos do acesso. Se os controlos não estiverem disponíveis ou se a configuração aprovada ainda exigir uma organização de API dedicada, siga as instruções da equipa de conta da OpenAI.

Se a remoção de uma organização ou projeto antigo ainda estiver pendente, se estiver pendente uma substituição ou se a correção da elegibilidade continuar por resolver, considere que a configuração corrigida ainda não está pronta até a alteração ser confirmada.

Nota sobre a utilização

Qualquer espaço de trabalho, organização de API ou projeto de API ativado para o Daybreak tem de ser exclusivamente interno. «Exclusivamente interno» significa que o acesso é utilizado pela sua própria equipa autorizada no trabalho defensivo da organização e não está associado a tráfego dirigido a clientes, a serviços de segurança oferecidos externamente nem a funcionalidades de produtos a jusante que encaminhem pedidos ou conteúdos de terceiros através deste acesso.

As definições do projeto determinam a disponibilidade da API para o projeto exclusivamente interno selecionado. Algum comportamento existente do Acesso de Confiança ao nível da organização pode manter-se durante a migração; consulte a confirmação de integração para conhecer os limites exatos do acesso. A ativação de um projeto não torna aceitável a utilização por clientes ou 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 disponibilizada separadamente para a organização de API exata 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 presuma que a ativação do Daybreak ou de um modelo específico num projeto altera as definições de retenção de dados.

Limites operacionais

Utilize a configuração disponibilizada apenas para trabalho defensivo autorizado.
Utilize sistemas que pertençam à sua organização ou para os quais esta esteja explicitamente autorizada a realizar avaliações.
Mantenha o primeiro fluxo de trabalho restrito e passível de revisão.
Assegure a intervenção humana em conclusões e medidas corretivas de elevado impacto.
Utilize exatamente a organização, o espaço de trabalho, o projeto de API, o nível de acesso do Daybreak e o alias de API ou ID de modelo indicados nos dados da sua integração.
Permita que apenas os administradores da organização alterem as definições de projeto e modelo do Daybreak e não deduza a elegibilidade para o Daybreak Red a partir da elegibilidade para o Daybreak Blue.
Mantenha seguras as credenciais de projeto recém-criadas ou atualizadas e restrinja-as ao projeto exclusivamente interno que foi ativado.
Não disponibilize as capacidades do Daybreak a clientes terceiros, utilizadores externos ou fluxos de trabalho de produtos a jusante.

Integração empresarial do Daybreak