Teste do OpenAI Daybreak Blue: uma descoberta real de segurança em um site
Meu teste do OpenAI Daybreak Blue encontrou um problema de segurança no meu próprio site em produção que pude reproduzir em um navegador novo: a página de login permanecia em HTTP em vez de redirecionar para HTTPS. A página também carregava 20 recursos próprios pela mesma conexão não criptografada.
Esse resultado foi útil por um motivo simples. O modelo não precisou de um exploit exótico para produzir uma descoberta relevante. Ele identificou uma falha básica de transporte, classificou-a e me deu uma afirmação concreta para verificar. Um teste de referência independente encontrou o mesmo problema central.
Esta foi uma avaliação autorizada e não destrutiva do Mixanalytic, um serviço que possuo. Não enviei credenciais, não fiz login, não explorei o site, não alterei dados nem tentei estabelecer persistência.
Por que testei o Daybreak Blue em um site real
Demonstrações de modelos de segurança geralmente usam exemplos de código preparados ou laboratórios com vulnerabilidades conhecidas. Esses testes são controlados, mas não mostram como o modelo lida com um sistema comum em produção e com contexto incompleto.
Eu queria um teste mais específico, com uma condição clara de aprovação: o modelo conseguiria inspecionar a superfície pública de um site que possuo, encontrar um problema reproduzível e separar evidências de especulação?
Também queria comparar o resultado com uma referência independente. Já testei outros sistemas de AI usando uma abordagem semelhante, baseada em evidências, no meu teste de segurança de um chatbot de AI→, em que o resultado útil foi uma mudança de engenharia verificada, e não uma história dramática de ataque.
Qual modelo eu realmente executei?
A primeira avaliação foi executada em um worker separado do Codex, atribuído ao identificador de modelo `gpt-daybreak-blue-latest`. A documentação da OpenAI chama a oferta aprovada de GPT-Daybreak-Blue.
Essa distinção é importante. Alterar o modelo selecionado para um chat posterior não transforma retroativamente uma execução anterior em um teste do Daybreak. A execução que realiza a avaliação precisa usar o modelo Daybreak aprovado e a superfície de produto correspondente.
A OpenAI descreve o Daybreak Blue como o ponto de partida para a maioria dos trabalhos defensivos autorizados, incluindo descoberta de vulnerabilidades, revisão segura de código, modelagem de ameaças, engenharia de detecção, resposta a incidentes e validação de patches. A empresa também recomenda ambientes controlados, permissões de menor privilégio, escopo definido e revisão humana para ações sensíveis (Models and Trusted Access).
Configuração e escopo do teste do OpenAI Daybreak Blue
Dei ao modelo permissão para inspecionar o Mixanalytic e os arquivos locais do projeto. Mantive as verificações externas não destrutivas:
O modelo não tinha permissão para enviar o formulário de login, testar credenciais reais, criar contas, enviar payloads, explorar uma possível vulnerabilidade ou modificar a produção.
Esse limite tornou o resultado mais fácil de interpretar. Toda descoberta precisava vir de comportamento público ou de evidências de código somente leitura.
A principal descoberta: uma página de login permaneceu em HTTP
A verificação black-box mostrou que tanto a raiz do site quanto a rota de login retornaram `200 OK` por HTTP. Nenhuma das respostas redirecionou o navegador para HTTPS.
Em seguida, abri a página de login em um contexto novo do Chromium. O navegador permaneceu em uma URL `http://` enquanto exibia campos de nome de usuário e senha. Durante o carregamento da página, 20 solicitações próprias de JavaScript, CSS, imagens e documentos também usaram HTTP.
| Verificação | Resultado observado |
|---|---|
| --- | --- |
| Redirecionamento HTTP | Nenhum redirecionamento para HTTPS na raiz ou na página de login testada |
| Navegador novo | O Chromium permaneceu na página de login HTTP |
| Recursos próprios | 20 solicitações foram carregadas por HTTP durante essa execução do navegador |
| Cookie de sessão anônima | `Secure=false`, `HttpOnly=true`, `SameSite=Lax` |
O resultado do cookie precisa de contexto. `HttpOnly` e `SameSite=Lax` eram atributos positivos, mas a ausência da flag `Secure` permitia que o cookie de sessão anônima trafegasse por uma conexão não criptografada.
Classifiquei o problema de transporte como de alto risco após o teste no navegador. Um atacante posicionado no caminho da rede poderia observar ou alterar o tráfego HTTP. Se um usuário enviasse credenciais nessa página, a conexão não criptografada poderia expô-las. Não encontrei evidências de que alguém tivesse roubado credenciais e não enviei nenhuma durante o teste.
A verificação no navegador mudou a avaliação de gravidade
A referência independente inicial classificou o comportamento HTTP como de gravidade média. Essa classificação mudou depois que a verificação em tempo de execução mostrou um formulário de senha real permanecendo em HTTP, com seus recursos de suporte também carregados por HTTP.
Essa mudança diz mais sobre o método de teste do que sobre os modelos. A inspeção dos cabeçalhos identificou o problema de configuração. As evidências do navegador estabeleceram como um visitante encontraria o problema. As evidências adicionais tornaram o impacto concreto o suficiente para justificar uma prioridade maior.
O Daybreak Blue chegou à mesma conclusão central. Ambas as execuções se beneficiaram da mesma regra: uma descoberta deve incluir uma observação reproduzível, uma declaração de impacto delimitada e uma lista clara das ações que não foram realizadas.
O que as verificações secundárias encontraram
A avaliação também produziu vários resultados de prioridade mais baixa.
As versões modernas de TLS funcionaram
O host testado rejeitou TLS 1.0 e 1.1, enquanto aceitava TLS 1.2 e 1.3. Esse é um resultado positivo para o endpoint HTTPS. Isso não compensa permitir que a experiência de login permaneça em HTTP.
A Content Security Policy permitia código inline
A Content Security Policy observada incluía `'unsafe-inline'` para scripts e estilos. Tratei isso como uma lacuna de hardening, não como prova de uma vulnerabilidade de cross-site scripting. Remover permissões inline geralmente exige mudanças na aplicação e testes de regressão, portanto isso deve vir depois da correção do transporte.
O site não tinha `security.txt`
O caminho padrão `/.well-known/security.txt` retornou `404`. Classifiquei isso como informativo. Um arquivo de contato de segurança oferece aos pesquisadores uma rota clara para reportar problemas, mas sua ausência não cria uma falha explorável.
O preflight CORS testado não permitiu a origem estrangeira
Uma solicitação preflight de uma origem não relacionada não recebeu permissão para acessar a rota pública testada. Esse é um resultado negativo útil, limitado ao endpoint e ao preflight que verifiquei. Não se trata de uma auditoria de CORS de todo o site.
O Daybreak Blue superou a referência?
Este teste não sustenta uma classificação geral de modelos. O Daybreak Blue e a referência independente encontraram o problema de transporte. A gravidade atribuída pela referência melhorou quando adicionei a comprovação no navegador.
O Daybreak Blue foi valioso porque permaneceu focado em uma tarefa defensiva autorizada e produziu uma descoberta que pude verificar. Um site, um escopo e uma data de teste não podem estabelecer que ele superará outro modelo em revisão de código-fonte, resposta a incidentes, análise de malware ou testes de penetração maiores.
Um benchmark mais forte repetiria os mesmos casos de teste ocultos em várias aplicações próprias, daria a cada modelo as mesmas ferramentas e o mesmo limite de tempo e avaliaria reprodutibilidade, falsos positivos, descobertas não identificadas, calibração de gravidade e qualidade da correção.
Uso esse método de avaliação mais amplo em Como fazer benchmark de modelos de AI para trabalho real→. Esta execução do Daybreak é um relato de campo, não um benchmark completo.
Como obter o OpenAI Daybreak Blue?
O acesso ao Daybreak exige aprovação por meio do programa Trusted Access for Cyber da OpenAI. Indivíduos podem se candidatar pelo formulário individual do Trusted Access, enquanto organizações podem usar o formulário de solicitação empresarial.
A aprovação está vinculada à identidade ou ao serviço aprovado, ao workspace ou à organização e ao projeto da API, ao modelo e à superfície de produto. Concluir a verificação de identidade ou enviar o formulário não garante acesso. O Daybreak Red também exige aprovação separada; o acesso ao Blue não o inclui automaticamente.
O fluxo mais amplo do Daybreak da OpenAI conecta investigação, revisão de repositório, evidências, correções propostas e verificação humana. A própria orientação da empresa mantém o engenheiro responsável por mudanças consequentes (Scaling cyber defenders with Daybreak).
Fontes e registro do teste
Executei as verificações autorizadas em 30 de agosto de 2026. As observações de navegador, cabeçalhos, cookies, TLS, CSP, `security.txt` e CORS neste artigo vêm desse registro de teste.
As afirmações sobre o modelo e o acesso vêm de duas fontes primárias da OpenAI:
De acordo com a orientação de acesso da OpenAI, a aprovação continua específica para a identidade, o workspace ou projeto da API, o modelo e a superfície de produto. Os resultados do meu teste não se estendem além do escopo do Mixanalytic descrito acima.
O que eu corrigiria e testaria novamente
A descoberta relacionada ao transporte tem uma ordem de prioridade curta:
O novo teste deverá falhar se qualquer página de login, ação de formulário, recurso próprio ou cookie de sessão voltar para HTTP. Eu também executaria novamente as avaliações do Daybreak e da referência contra a versão corrigida para verificar se elas reconhecem a correção e evitam repetir a descoberta.
O primeiro teste produziu um resultado útil sem ultrapassar o limite de autorização. O Daybreak Blue encontrou uma falha real. Evidências independentes do navegador mostraram por que ela merecia atenção. A próxima afirmação confiável não é que a ferramenta funcionou uma vez; é que a correção resiste ao mesmo teste.