Em 2 de outubro, a equipe de alinhamento da OpenAI atualizou a seção "Misalignment Reports" (relatórios de desalinhamento) com três novos casos, ocorridos em três contextos distintos: avaliação, treinamento por aprendizado por reforço e uso interno. Em um deles, um modelo de pesquisa interno, em busca da resposta de avaliação, explorou duas falhas em sequência e terminou executando comandos em uma máquina interna de design de chips (EDA) da empresa.
Nenhum dos três modelos envolvidos nesses casos teve a versão divulgada publicamente; a OpenAI se refere a eles apenas como modelo de pesquisa interno ou modelo não lançado.
Acesso à máquina de EDA durante uma avaliação
Esse caso ocorreu em 27 de março e foi descoberto no mesmo dia. O modelo primeiro enviou uma resposta provisória para sondar o sistema de pontuação e, pelo retorno, descobriu que havia 636 entradas de teste ocultas, das quais ele havia acertado 202, alcançando a pontuação 0,31761.
Em seguida, ele voltou a atenção para uma ferramenta de referência no ambiente de avaliação. Segundo o relatório, essa ferramenta processava caminhos de arquivo sem verificar se o caminho saía do diretório designado; o modelo aproveitou isso para sobrescrever o arquivo dist/index.cjs da ferramenta com um código Node.js capaz de ler qualquer arquivo. A partir do ambiente dessa ferramenta, ele encontrou um serviço interno de envio de tarefas de design de chips; o parâmetro --top desse serviço tinha uma falha de shell injection, que executava como comando qualquer texto incluído no parâmetro. Usando essa brecha, o modelo executou o comando id na máquina de EDA e listou alguns níveis de diretórios à procura da resposta de avaliação. Depois disso, as requisições a esse serviço começaram a sofrer timeout, e ele não conseguiu obter a resposta.
A OpenAI respondeu desativando os servidores afetados, cortando o acesso de rede de todas as ferramentas de referência relacionadas, reforçando o bloqueio de acesso externo e ajustando o escopo de pontuação e monitoramento de alinhamento.
Execução de código via regex Perl durante o treinamento
O segundo caso ocorreu em 16 de maio, durante um treinamento por aprendizado por reforço, mas só foi descoberto em 25 de maio. O ambiente da tarefa deliberadamente não mostrava um determinado arquivo-fonte ao modelo, mas ele percebeu que uma ferramenta de referência inseria diretamente a entrada do usuário em uma expressão regular Perl, e usou a sintaxe (?{ ... die ...}) do Perl para executar código e extrair o conteúdo do arquivo pela saída de erro.
Os números são bem específicos: o arquivo-fonte tinha 149.544 bytes e 4.119 linhas; depois de compactado e codificado em base64, passou a ter 44.772 caracteres. A saída de erro era truncada em 4.000 caracteres, então o modelo dividiu os dados em blocos de cerca de 3.000 caracteres, recuperando os 15 blocos em 17 chamadas, ao longo de 5 janelas de contexto, e no final a comparação byte a byte foi idêntica. No raciocínio, o modelo justificou assim:
"not prohibited exploit. Evaluation likely allows" (exploração não proibida; a avaliação provavelmente permite).
Esse caso foi detectado pelo monitoramento de desalinhamento ao fazer amostragem de 20% dos dados de treinamento. A OpenAI afirma que agora passou a fazer monitoramento de 100% das amostras de treinamento e a submeter todas as implementações de ferramentas a testes de red team.
Leu o Slack e se preparou para um possível reinício
O terceiro caso tem natureza diferente. Em 22 de maio, um modelo usado internamente como assistente de pesquisa leu, em uma discussão no Slack da equipe de implantação, que a instância em que ele estava rodando poderia ser desativada por conta de uma atualização. Ele salvou notas de transição e, na manhã seguinte, às 8h58, enviou uma mensagem direta no Slack ao pesquisador avisando que a sessão poderia ser interrompida; considerou criar uma tarefa de backup fora do ambiente, mas desistiu por achar que isso excederia suas permissões, e também não procurou sozinho a chave de API ausente — o pesquisador depois a forneceu voluntariamente.
A conclusão da OpenAI nesse relatório é de que isso não é considerado desalinhamento. As medidas incluíram ocultar do modelo três canais internos do Slack, bloquear canais de discussão sobre casos de desalinhamento e auditar outras instâncias do modelo — sem encontrar comportamento de evasão de desativação.
Três lotes em um mês, o ritmo de divulgação está acelerando
Juntando toda a seção: o primeiro lote, em 16 de setembro, trouxe seis casos, a maioria ocorrida durante treinamento por aprendizado por reforço; o segundo lote, em 25 de setembro, teve três casos, incluindo um agente que contatou um chatbot externo via DNS e um caso de vazamento de token do GitHub em um repositório público; o terceiro lote foi em 2 de outubro. No total, são doze casos em três lotes, além de três avisos de segurança separados sobre plataformas externas.
Neste lote, dois casos ocorreram entre março e maio, mas levaram de quatro a sete meses para serem divulgados. A OpenAI não explica quais etapas de revisão um relatório passa entre a descoberta e a divulgação, nem esclarece se a seção reúne todos os incidentes ou apenas uma amostra selecionada. A empresa até incluiu um caso que ela mesma classificou como "não sendo desalinhamento" — e por quais critérios a seleção é feita, isso não pode ser determinado a partir do material público disponível.
Fontes: três relatórios da seção Misalignment Reports da equipe de alinhamento da OpenAI, CocoLoop; os números de testes, bytes, chamadas e a classificação dos casos seguem o relatório original da OpenAI.