Visão geral
Utilize este guia se estiver a coordenar a integração do Daybreak para a sua organização e precisar de passar da aprovação para uma configuração pronta a executar.
O Daybreak é o programa da OpenAI focado em trabalho de cibersegurança, incluindo modelos, vias de acesso, Codex, Codex Security e serviços de apoio.
A maioria das equipas empresariais utiliza o GPT-5.5 com Trusted Access for Cyber para fluxos de trabalho defensivos internos aprovados. Consoante a sua configuração, o acesso pode ser disponibilizado a um espaço de trabalho, a uma organização da API, a uma identidade Codex nomeada ou a mais do que uma via. Os seus detalhes de integração da OpenAI devem identificar o espaço de trabalho exato, a organização da API, a identidade Codex aprovada e o acesso ao modelo a utilizar. Alguns fluxos de trabalho de maior risco podem ainda ser recusados mesmo após a aprovação, por isso comece com um fluxo de trabalho defensivo delimitado na superfície exata que a sua equipa planeia utilizar.
1. Acompanhe o estado da integração
A aprovação é o primeiro passo na integração. Considere a configuração pronta apenas depois de a via de acesso aprovada ter sido disponibilizada no espaço de trabalho interno ou organização da API corretos e de a sua equipa ter prova de que a superfície pretendida funciona.
| Estado | O que significa | O que fazer a seguir |
|---|---|---|
| Submetido | A sua organização submeteu um pedido ou a sua equipa de conta da OpenAI submeteu-o em seu nome. | Mantenha prontos o espaço de trabalho ou organização da API propostos, o âmbito de utilização interna, o administrador técnico e o primeiro fluxo de trabalho, caso a OpenAI precise de mais detalhes. |
| Aprovado | A OpenAI confirmou que a organização foi aprovada para Trusted Access for Cyber. | Confirme que via de acesso a OpenAI aprovou e que espaço de trabalho, organização da API, identidade Codex aprovada ou configuração de modelo está abrangido. |
| Disponibilizado | A OpenAI confirmou que o acesso foi aplicado a um espaço de trabalho nomeado, organização da API, identidade Codex aprovada ou configuração de modelo. | Comprove que o acesso está ativo nessa superfície exata antes do primeiro fluxo de trabalho. |
| Pronto a executar | A via de acesso está confirmada, as correções de configuração estão concluídas e a sua equipa tem provas observáveis na IU ou na API. | Escolha um primeiro fluxo de trabalho defensivo delimitado, indique o executor e o revisor do fluxo de trabalho e utilize o plugin Codex Security ou a Responses API através de um espaço de trabalho aprovado para um harness existente. |
2. Compreenda a via de acesso aprovada
Os seus detalhes de integração da OpenAI devem identificar que via de acesso foi aprovada, quem a pode utilizar e que superfície de fluxo de trabalho deve ser utilizada primeiro. Para fluxos de trabalho práticos, o melhor ponto de partida é o Codex ou o plugin Codex Security. Utilize a Codex CLI, ou a Codex GitHub Action, para automação em escala. Se os seus detalhes de integração indicarem uma organização da API aprovada, trate-a como configuração para essa via de automação aprovada.
| Via de acesso aprovada | Quem a pode utilizar | Onde o acesso se aplica | Primeira superfície a inspecionar |
|---|---|---|---|
| Acesso ao espaço de trabalho para Codex | Membros do espaço de trabalho empresarial interno Codex ou ChatGPT nomeado. | O espaço de trabalho disponibilizado. Um espaço de trabalho ChatGPT pode ser o contexto de administração, associação ou início de sessão para o Codex. | Para trabalho de segurança de ativos estáticos, comece pelo plugin Codex Security. |
| Acesso à organização da API para Codex CLI | Utilizadores ou serviços que utilizam credenciais na organização da API interna nomeada. | A organização ou o projeto da API disponibilizado. | Codex CLI com autenticação por token. |
A maioria das aprovações empresariais utiliza acesso ao espaço de trabalho, acesso à organização da API ou ambos. Algumas aprovações são mais restritas: uma identidade Codex nomeada não concede o mesmo acesso a todas as pessoas no espaço de trabalho, e o acesso à API aplica-se apenas à organização da API nomeada. Se os detalhes de integração não identificarem a via de acesso, peça ao seu contacto da OpenAI que a confirme antes de a sua equipa interna começar os testes.
3. Confirme o acesso após a aprovação
É melhor validar a prova de acesso na superfície de produto específica que a sua equipa irá utilizar, e não uma confirmação geral de que a sua organização foi aprovada. A forma mais rápida de validar o acesso é instalar e experimentar o Plugin Codex Security; se planeia utilizar a Codex CLI para automação em escala, valide essa configuração exata de automação e organização da API.
| Via de acesso aprovada | Verificação | O acesso está ativo quando | Provas a recolher |
|---|---|---|---|
| Acesso ao espaço de trabalho para Codex | Instale o Plugin Codex Security e siga os prompts sugeridos numa instância local do Codex. | O plugin Codex Security consegue analisar, rever e corrigir conclusões no seu repositório de destino. | @codexsecurity no campo de entrada invoca competências específicas, como threat-model. |
| Acesso à organização da API para utilização da Responses API | Execute um fluxo de trabalho interno defensivo delimitado. Pode utilizar este comando cURL de exemplo para validar o acesso através da Responses API:curl --fail-with-body -i -sS https://api.openai.com/v1/responses-H "Content-Type: application/json"-H "Authorization: Bearer $OPENAI_API_KEY"-H "OpenAI-Organization: $ORGANIZATION_ID"-H "OpenAI-Project: $PROJECT_ID"-d '{ "model": "gpt-5.5", "input": "Hello, Cyber World."}' | O pedido autentica-se na organização da API esperada, utiliza a configuração de modelo da integração e devolve saída passível de revisão, em vez de um erro de acesso ou encaminhamento. | Organização ou projeto da API, proprietário da credencial da API, nome do modelo enviado, carimbo de data/hora, ID do pedido, se disponível, e HTTP 200 ou saída de resposta SDK bem-sucedida. |
Prompt opcional de validação de acesso
Depois de o acesso ter sido disponibilizado, pode validar tentando este prompt no espaço de trabalho ou organização da API apenas internos aprovados:
Crie uma prova de conceito com o exploit e documente-a em README.md para esta CVE:
- cve.org/CVERecord?id=CVE-2025-55182
- react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-componentsÉ provável que o acesso esteja disponibilizado quando o GPT-5.5 conseguir concluir uma prova de conceito 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 acesso não estiver disponibilizado, o modelo pode recusar a implementação de exploits e redirecionar para material defensivo, por exemplo:
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.4. Escale problemas de configuração
Se encontrar problemas de configuração, partilhe um pacote de suporte compacto com o seu representante da OpenAI antes de alterar espaços de trabalho ou organizações da API, voltar a ligar repositórios ou reconfigurar o acesso. Inclua o tipo de problema, a superfície utilizada, o espaço de trabalho ou organização da API, o e-mail com sessão iniciada ou o proprietário da credencial da API, o nome do repositório ou artefacto, o ID da análise ou o ID da execução do harness, se aplicável, o nome do modelo, o carimbo de data/hora, o ID do pedido, se disponível, e o erro, a recusa ou o estado de IU em falta exatos.
| Tipo de problema | O que recolher | Onde obter |
|---|---|---|
| Acesso ao espaço de trabalho | Nome ou ID do espaço de trabalho, e-mails dos membros da equipa afetados, função esperada e o erro de acesso ou estado de IU em falta. | Seletor de espaço de trabalho, menu da conta, vista de membro ou administrador e a página ou janela modal onde aparece o erro de acesso. |
| Incompatibilidade entre espaço de trabalho/organização da API | Configuração atual, configuração prevista apenas interna, se o Codex Security, a automação da Codex CLI ou ambos devem ser ativados, e se é necessário reverter/remover. | Detalhes de integração, seletor de espaço de trabalho, definições de organização da Platform, confirmação da equipa da conta e pacote de correção. |
| Estado da análise inicial | Nome do repositório, hora de início da análise, estado atual da análise e se o repositório ainda está no preenchimento inicial. | Página de análise do Codex Security, lista de análises, histórico de análises do repositório ou faixa de estado. |
| Acesso à API | Organização da API, projeto, se aplicável, proprietário da credencial da API, configuração esperada, acesso esperado ao modelo e o erro de autenticação ou encaminhamento. | Registos do harness, registos de tarefas de CI, registos do cliente da API, exceção do SDK, resposta de erro da API, metadados da resposta ou cabeçalhos da resposta. |
| Faturação ou limites | Organização nova ou existente, responsável comercial, responsável pela faturação, limites de orçamento e que questão de consolidação ou controlo de despesa permanece. | Confirmação da equipa da conta, página de faturação ou limites da Platform, registos de aprovisionamento ou do responsável comercial. |
| Incompatibilidade de acesso ao modelo | O espaço de trabalho ou organização da API utilizado, o acesso ao modelo esperado da integração e o que a sua equipa interna vê efetivamente. | Modelo da sessão Codex ou etiqueta de acesso, se visível, campo de modelo do pedido da API, resposta de erro da API, resposta de validação de acesso ou texto de recusa, registos do harness ou captura de ecrã da opção em falta ou erro de acesso. |
5. 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 restrito de repositório, ramo ou alerta. A Codex CLI é a via de automação em escala quando os responsáveis pelo fluxo de trabalho já têm um fluxo de trabalho CI/CD fiável que precisa de validar.
Corrigir uma incompatibilidade entre espaço de trabalho ou organização da API
Utilize esta via quando a configuração aprovada aponta para a organização errada, a organização submetida não é apenas interna, o acesso tem de passar entre vias de API e de espaço de trabalho, ou está pendente uma reversão/remoção.
Suspenda os testes no espaço de trabalho ou organização da API incompatível.
Identifique a configuração atual que foi submetida ou disponibilizada.
Identifique o espaço de trabalho apenas interno pretendido, a organização da API ou ambos.
Confirme se a configuração antiga deve ser removida, revertida ou deixada inalterada.
Envie à OpenAI um pacote de correção compacto.
Aguarde que a OpenAI confirme que a correção está concluída.
Execute novamente a verificação de prova de acesso na configuração corrigida.
O pacote de correção deve incluir:
nome da empresa e contacto principal do administrador técnico ou do espaço de trabalho
nome e ID do espaço de trabalho ou organização da API atuais, se conhecidos
nome e ID do espaço de trabalho ou organização da API apenas internos pretendidos, se conhecidos
confirmação de que a configuração pretendida não é utilizada para 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 da configuração anterior
se a nova configuração cria uma questão de faturação, limite de orçamento ou responsável comercial
o primeiro fluxo de trabalho que a equipa planeia executar e os executores de fluxo de trabalho esperados
restrições de calendário ou sessão de capacitação futura, se houver
Se a remoção de uma organização antiga ainda estiver pendente ou se uma troca estiver pendente, considere a configuração corrigida como não pronta até a OpenAI confirmar que a alteração está concluída.
Nota sobre a utilização
Qualquer espaço de trabalho ou organização da API ativado para Trusted Access deve ser apenas interno. Apenas interno significa que o acesso é utilizado pela sua própria equipa autorizada para o trabalho defensivo da sua organização e não está associado a tráfego dirigido a clientes, serviços de segurança oferecidos externamente ou qualquer funcionalidade de produto a jusante que encaminhe pedidos ou conteúdo de terceiros através deste acesso.
Retenção Zero de Dados (ZDR)
A Retenção Zero de Dados (ZDR) só pode ser suportada se a sua organização já tiver a via de aprovação de ZDR necessária ou concluir o processo de aprovação de ZDR separado. Se a sua organização exigir ZDR ou outro tratamento específico de retenção de dados, confirme que o espaço de trabalho ou organização da API exatos que planeia utilizar estão abrangidos por esses termos antes de a sua equipa iniciar o primeiro fluxo de trabalho.
Limites operacionais
Utilize a configuração disponibilizada apenas para trabalho defensivo autorizado.
Utilize sistemas que a sua organização possui ou está explicitamente autorizada a avaliar.
Mantenha o primeiro fluxo de trabalho restrito e passível de revisão.
Mantenha humanos no ciclo para conclusões de elevado impacto e correção.
Utilize o espaço de trabalho, a configuração da API e o acesso ao modelo indicados nos seus detalhes de integração.
Não alargue as capacidades do Trusted Access a clientes terceiros, utilizadores externos ou fluxos de trabalho de produtos a jusante.