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ê está coordenando o onboarding do Daybreak para sua organização e precisa avançar da solicitação inicial ao provisionamento até uma configuração pronta para uso.

O Daybreak é o programa da OpenAI voltado ao trabalho de cibersegurança, incluindo modelos, caminhos de acesso, Codex, Codex Security e serviços de suporte.

A maioria das equipes empresariais usa o GPT-5.5 com Trusted Access for Cyber em fluxos de trabalho defensivos internos aprovados. Para esse caminho de acesso, a OpenAI provisiona a organização ou o workspace identificado no processo de solicitação inicial depois que a verificação KYB da Persona e as checagens internas de adequação são concluídas. O acesso pode se aplicar a uma organização do Codex ou do ChatGPT, a uma organização de API, ou a ambas, dependendo da configuração aprovada.

Alguns fluxos de trabalho de maior risco ainda podem ser recusados após o provisionamento; por isso, comece com um fluxo de trabalho defensivo delimitado na superfície exata que sua equipe pretende usar.

Acompanhar o status de onboarding e provisionamento

Fase	Descrição	O que fazer em seguida
Enviar formulário de solicitação inicial	Sua organização preencheu o formulário de solicitação inicial empresarial do Trusted Access	Aguarde um e-mail da Persona e conclua a verificação KYB. Garanta que o e-mail da Persona chegue ao contato correto da organização.
Receber e concluir o e-mail de KYB da Persona	Depois que o formulário de solicitação inicial é enviado, a Persona envia um e-mail ao contato informado no formulário para concluir a verificação Know Your Business (KYB).	Conclua a solicitação KYB da Persona. Depois que o KYB é concluído, a OpenAI realiza checagens internas de adequação e só faz o provisionamento após a aprovação dessas checagens.
Receber notificação de que você foi provisionado	A OpenAI aplicou o acesso à organização ou ao workspace solicitado no formulário de solicitação inicial.	Verifique se o acesso está provisionado corretamente na superfície solicitada. Observe que o acesso não aparece atualmente em um painel de workspace visível ao cliente.
Verificar se você tem acesso e iniciar um fluxo de trabalho defensivo delimitado	A organização ou o workspace provisionado foi confirmado e a verificação de acesso pretendida é bem-sucedida	Escolha um primeiro fluxo de trabalho defensivo delimitado, nomeie o executor e o revisor do fluxo de trabalho e use o plugin Codex Security ou uma organização aprovada da Responses API.

Entender o caminho de acesso provisionado

A confirmação da OpenAI deve identificar qual caminho de acesso foi provisionado, quem pode usá-lo e qual organização ou workspace deve ser usado primeiro.

Para fluxos de trabalho práticos com repositório, comece com o Codex ou o plugin Codex Security. Use a Codex CLI ou a Codex GitHub Action para automação aprovada. Se o acesso for provisionado para uma organização de API, mantenha solicitações e credenciais restritas a essa organização.

Caminho de acesso provisionado	Quem pode usá-lo	Onde o acesso se aplica	Primeira superfície para validar o acesso
Acesso via Codex	Membros da organização ou workspace interno nomeado do Codex ou ChatGPT	A organização ou o workspace provisionado. Para esse caminho, o acesso abrange toda a organização	Para trabalhos de segurança em ativos estáticos, comece com o plugin Codex Security.
Acesso via organização de API	Usuários ou serviços autenticados na organização interna de API nomeada	A organização de API provisionada	A Responses API ou outro fluxo de trabalho aprovado da API do Codex.

Para o GPT-5.5 com Trusted Access for Cyber, o acesso ao workspace é provisionado para a organização nomeada do Codex ou ChatGPT, e o acesso à API é provisionado para a organização de API nomeada. Se a confirmação indicar um caminho diferente no nível do usuário ou específico do modelo, siga essas instruções exatas em vez de presumir acesso para toda a organização. Se o caminho de acesso provisionado não estiver claro, peça ao seu contato da OpenAI que o confirme antes de testar.

Validar o acesso provisionado

Depois que a OpenAI confirmar o provisionamento, execute este prompt na superfície exata confirmada. Isso pode ser feito no Codex enquanto você está conectado à organização ou ao workspace somente interno, ou pela Responses API usando credenciais da organização de API confirmada.

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 a identidade conectada e a organização ou o workspace. O resultado pode indicar provisionamento incompleto, uma incompatibilidade de roteamento ou um limite de política. Se o provisionamento estiver concluído e o problema continuar, siga Trusted Access for Cyber — problemas comuns e solução de problemas para ver as etapas de diagnóstico e os detalhes a incluir ao contatar o Suporte. Para abrir uma solicitação de Suporte, consulte: Como posso entrar em contato com o suporte? Uma recusa pode ser semelhante a:

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.

Escalar problemas de configuração

Antes de alterar workspaces, organizações de API, repositórios ou credenciais, peça à sua equipe de conta da OpenAI que confirme se o provisionamento foi concluído e se a organização, o workspace e o caminho de acesso pretendidos estão corretos.

Para problemas de verificação, acesso, modelo ou segurança cibernética, siga Trusted Access for Cyber — problemas comuns e solução de problemas. Ele inclui etapas de diagnóstico e as informações a fornecer ao contatar o Suporte, como ID da organização, superfície do produto, modelo, mensagem de erro completa, ID da solicitação, carimbo de data/hora e fuso horário, captura de tela quando aplicável e uma breve descrição editada da tarefa.

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. A Codex CLI é o caminho de automação em escala quando os responsáveis pelo fluxo de trabalho já têm um fluxo de trabalho de CI/CD confiável que você precisa validar.

Corrigir uma incompatibilidade de workspace ou organização de API

Use este caminho quando a configuração aprovada apontar para a organização errada, a organização enviada não for somente interna, o acesso precisar ser movido entre caminhos de API e workspace, ou houver uma reversão/remoção pendente.

Pause os testes no workspace ou na organização de API incompatível.
Identifique a configuração atual que foi enviada ou provisionada.
Identifique o workspace somente interno pretendido, a organização de API, ou ambos.
Confirme se a configuração antiga deve ser removida, revertida ou mantida sem alterações.
Envie os detalhes abaixo à sua equipe de conta da OpenAI como uma solicitação de correção.
Aguarde a OpenAI confirmar que a correção foi concluída.
Execute novamente a verificação de prova de acesso na configuração corrigida.

Inclua:

nome da empresa e contato principal do administrador técnico ou de workspace
nome e ID do workspace ou da organização de API atual, se conhecidos
nome e ID do workspace ou da organização de API somente interna pretendida, se conhecidos
confirmação de que a configuração pretendida não é usada para aplicações voltadas a clientes, tráfego de terceiros ou fluxos de trabalho de produtos downstream
se o acesso deve ser removido ou revertido da configuração anterior
se a nova configuração cria alguma questão de faturamento, limite de orçamento ou responsável comercial
o primeiro fluxo de trabalho que a equipe pretende executar e os executores esperados do fluxo de trabalho
restrições de prazo ou próxima sessão de habilitação, se houver

Se a remoção de uma organização antiga ainda estiver pendente ou se uma troca estiver pendente, trate a configuração corrigida como não pronta até que a OpenAI confirme que a alteração foi concluída.

Observação sobre uso

Qualquer workspace ou organização de API habilitada para Trusted Access deve ser somente interna. Somente interna significa que o acesso é usado pela sua própria equipe autorizada para o trabalho defensivo da sua organização e não está vinculado a tráfego voltado ao cliente, serviços de segurança oferecidos externamente ou qualquer recurso de produto downstream que passe solicitações ou conteúdo de terceiros por esse acesso.

Zero retenção de dados (ZDR)

O provisionamento do Trusted Access não habilita automaticamente a zero retenção de dados (ZDR). A ZDR deve ser solicitada e provisionada separadamente para a organização exata. Se sua organização exigir ZDR ou outro tratamento específico de retenção de dados, confirme se a organização que você pretende usar está coberta por esses termos antes de sua equipe iniciar o primeiro fluxo de trabalho.

Limites operacionais

Use a configuração provisionada apenas para trabalho defensivo autorizado.
Use sistemas que sua organização possui ou está explicitamente autorizada a avaliar.
Mantenha o primeiro fluxo de trabalho restrito e revisável.
Mantenha humanos no processo para descobertas e remediações de alto impacto.
Use o workspace, a configuração de API e o acesso ao modelo listados nos seus detalhes de integração.
Não estenda os recursos do Trusted Access a clientes terceiros, usuários externos ou fluxos de trabalho de produtos downstream.

Integração empresarial ao Daybreak