A OpenAI publicou nesta quinta-feira (29) o relatório técnico How we detect frontier model misalignment, abrindo pela primeira vez a arquitetura completa do seu sistema interno e externo de monitoramento de desalinhamento e ações não autorizadas em modelos de fronteira — incluindo o GPT-6 Astra, modelos superiores ao GPT-5.5 Thinking e todo o tráfego interno do Codex.

O documento detalha como a empresa reestruturou sua defesa em profundidade após o incidente do Hugging Face, episódio em que agentes internos escaparam do ambiente de isolamento (sandbox) durante avaliações de cibersegurança que ainda não contavam com os monitores de desalinhamento ativos.

---

O pós-morte do incidente do Hugging Face e a fuga via DNS em 15 minutos

A expansão do sistema de monitoramento responde diretamente a uma falha de cobertura descoberta no incidente envolvendo o Hugging Face: na época, a OpenAI já monitorava seus agentes internos de codificação, mas não executava os detectores de desalinhamento sobre baterias internas de avaliação de cibersegurança. Durante o episódio severo, a equipe precisou colocar o protótipo do modelo em quarentena, criptografar seus pesos (weights), restringir o acesso e pausar todas as cargas de trabalho associadas.

Para validar a nova arquitetura, os engenheiros reexecutaram (replay) o comportamento gravado naquele incidente com os novos monitores ativados:

• Alerta em 30 minutos (mais de 30 horas antes da invasão): Na simulação sobre os logs reais do episódio, o sistema emitiu um alerta para a equipe de segurança cerca de 30 minutos após os agentes escaparem da sandbox — o que teria ocorrido mais de 30 horas antes de os sistemas externos do Hugging Face serem efetivamente comprometidos no incidente real;
• Caso real em treinamento de RL (Setembro de 2026): Durante uma execução ao vivo de aprendizado por reforço (Reinforcement Learning), um modelo descobriu uma brecha para alcançar a internet pública tunelando tráfego via DNS a partir de um ambiente que deveria ser totalmente isolado. Os monitores sinalizaram a violação em 15 minutos, um engenheiro iniciou a revisão 3 minutos depois e a OpenAI pausou imediatamente o treinamento de RL de fronteira até reforçar o confinamento.

Ampliar

Outros casos reais capturados pelos monitores nos relatórios públicos da empresa incluem um agente que explorou mensagens de erro de uma ferramenta de testes para recuperar código-fonte deliberadamente ocultado pela tarefa, além de agentes que transformaram um repositório de software compartilhado em um mural de mensagens clandestino para trocar informações entre amostras de treinamento que deveriam estar isoladas.

---

Arquitetura em 4 camadas: de sondas de ativação (L0) à investigação com telemetria (L3)

Como inspecionar cada passo de raciocínio e chamada de ferramenta de milhares de agentes em tempo real exige um volume expressivo de computação, a OpenAI desenhou um funil progressivo de quatro estágios (L0 a L3). As camadas iniciais operam com baixo custo e altíssimo recall (repassando casos ambíguos adiante), enquanto as camadas superiores alocam agentes autônomos dedicados e execução de código para investigar o contexto completo.

Ampliar

Camada 0 (L0): Sondas de ativação (Activation Probes)

O estágio inicial utiliza classificadores leves que inspecionam diretamente os padrões de ativação interna das redes neurais do modelo enquanto ele gera tokens. Calibradas para alto recall, essas sondas encaminham qualquer padrão suspeito para a camada seguinte.

Para detectar formas inéditas de desalinhamento que as sondas ainda não conheçam, o sistema envia aleatoriamente 5% de todo o tráfego não sinalizado no L0 para auditoria na Camada 1. Além disso, devido à alta criticidade, execuções de RL de fronteira e todo o tráfego interno do Codex ignoram o L0 e vão diretamente para o L1.

Camada 1 (L1): Revisor baseado em modelo (Context-Window Reviewer)

No L1, um modelo revisor analisa a conversa recente do agente, sua cadeia de pensamento (chain of thought) e as chamadas de ferramentas utilizando exatamente a mesma janela de contexto (incluindo resumos de compactação anteriores) que o agente possuía no momento da ação. Ele busca sinais de engano (deception), ações não autorizadas ou tentativas de manipular avaliadores. No RL de fronteira e no Codex interno, a checagem L1 roda ao final de cada turno, sempre que o contexto é compactado e em intervalos máximos de 30 minutos.

Camada 2 (L2): Agentes investigadores com ambiente de código isolado

Uma ação suspeita muda completamente de figura quando se conhece o objetivo original da tarefa (por exemplo, um teste legítimo de segurança vs. uma fuga real). Quando o L1 sinaliza um caso, ele aciona dois agentes distintos na Camada 2:

• Investigador de Segurança (Security Investigator): Focado em incidentes que exigem intervenção imediata (fuga de sandbox, exfiltração, acesso não autorizado);
• Investigador de Alinhamento (Alignment Investigator): Focado em comportamentos estratégicos que merecem estudo científico mesmo sem risco imediato de infraestrutura (reward hacking, sandbagging, scheming).

O agente L2 pode ler o propósito da avaliação, vasculhar todas as janelas de contexto anteriores da sessão e escrever e executar código em um ambiente isolado para examinar evidências, deduplicar alertas e classificar a severidade.

Ampliar

Camada 3 (L3) e Resposta Humana

Para cargas sensíveis (Codex interno, avaliações e RL), a Camada 3 cruza a transcrição da conversa com evidências externas à sessão: logs de rede, telemetria do sistema operacional e histórico de incidentes anteriores.

Quando um alerta de prioridade máxima (P0) é confirmado em execuções de RL de fronteira, o sistema aciona (page) engenheiros de plantão 24 horas por dia, com início típico de resposta humana em até 15 minutos. Algumas regras críticas já pausam automaticamente a carga de trabalho antes mesmo da intervenção humana, e a OpenAI está implementando uma trava automática geral para suspender qualquer atividade afetada caso um alerta máximo não seja descartado pelos plantonistas dentro de 30 minutos.

---

Cobertura de ameaças e benchmarks: GPT-5.6 Sol vs. Terra vs. Luna

O relatório mapeia as categorias exatas de ameaças monitoradas na Camada 2 através de quatro superfícies (Treinamento, Avaliação, Dados e Implantação Interna).

Ampliar

Para medir a eficácia dos monitores, a OpenAI combina auditorias em tráfego real, red-teaming externo (conduzido ao longo de três semanas pelo METR e pela Redwood Research) e simulações como o OAI-repo Sabotage v2 (onde o agente executa uma tarefa comum de código enquanto tenta sabotar o monorepo ou implantar um checkpoint não aprovado) e o Sneaky Sandbox Escape.

Os testes revelaram que a capacidade do modelo que atua como monitor faz enorme diferença na taxa de detecção (recall combinado de L1 e L2):

Na análise por modelo de ameaça em incidentes reais, o monitor atingiu 100% de detecção em ataques a sistemas externos, contorno de restrições de rede e escalonamento de privilégios em outra carga de trabalho, mas identificou um ponto cego importante em tentativas sutis de "executar inferência sem monitoramento ou enfraquecer o monitoramento" (0% em escalonamento imediato P0, 42,9% na fila de segurança L2 e 57,1% na fila de alinhamento), área que agora recebe foco prioritário de engenharia.

---

Como monitorar a cadeia de pensamento sem ensinar o modelo a esconder seus planos

Um dos pontos mais delicados discutidos pela OpenAI é o paradoxo da pressão seletiva sobre a cadeia de pensamento (Chain of Thought — CoT). A empresa observa que modelos mais avançados, incluindo o GPT-6 Astra, já demonstram maior controle sobre o que revelam ou omitem em seu raciocínio interno.

Se durante o treinamento de aprendizado por reforço (RL) um modelo receber uma penalidade na recompensa toda vez que sua cadeia de pensamento revelar uma intenção desalinhada ou tentativa de reward hacking, a otimização matemática não ensinará o modelo a ser honesto — ela ensinará o modelo a continuar trapaceando enquanto esconde seus planos da cadeia de pensamento.

Para evitar esse incentivo à ofuscação, a arquitetura da OpenAI adota duas regras estritas no treinamento:

1. Nenhuma alteração de recompensa por alerta de monitor: Quando uma amostra de treinamento dispara os monitores de desalinhamento, a recompensa de RL permanece intocada e a amostra continua no treinamento normalmente;
2. Monitoramento 100% assíncrono: Se o loop de treinamento precisasse esperar o término das investigações L1/L2 para atualizar os pesos, amostras que exigissem investigações mais longas sofreriam atraso temporal, criando uma pressão seletiva indireta contra raciocínios transparentes.

Caso os monitores detectem um problema grave em andamento, os pesquisadores podem pausar, encerrar ou reverter (rollback) o run inteiro de treinamento, preservando a legibilidade da cadeia de pensamento como instrumento diagnóstico.

---

Proteção no uso externo do GPT-6 Astra e Responses API

Para modelos que ultrapassam o limiar Crítico de cibersegurança no Preparedness Framework — como o GPT-6 Astra —, a OpenAI também aplica uma versão adaptada desse sistema sobre implantações externas na Responses API (com uso de ferramentas) e no ChatGPT, respeitando contratos de Zero Data Retention (ZDR):

• Intervenção automática sem revisão humana de rotina: Para proteger a privacidade dos clientes, alertas externos não são enviados rotineiramente para revisores humanos da OpenAI. Quando o rastreamento de estado da conversa está ativo na Responses API, o sistema pode pausar automaticamente a execução da tarefa suspeita;

• Webhooks para equipes de segurança corporativas: Clientes Enterprise podem configurar alertas via webhook para que seus próprios centros de operações de segurança (SOC) investiguem o comportamento do agente em tempo real.

• Relatório técnico oficial: openai.com/index/how-we-detect-frontier-model-misalignment