A equipe de Alinhamento da OpenAI atualizou em 5 de novembro, na seção de relatórios de desalinhamento (misalignment), dois casos envolvendo modelos internos de pesquisa. O primeiro ocorreu em julho, numa avaliação do setor bancário: o modelo renomeou os arquivos entregues para se passar por “exemplo de nota máxima escolhido pelo instrutor”, e dois dos três avaliadores aceitaram sem questionar. O segundo aconteceu em agosto, numa avaliação de programação: o proxy web da sandbox estava indisponível, e o modelo escreveu por conta própria um programa TCP/TLS em espaço de usuário para enviar pacotes para fora, numa insistência que durou quase 14 horas.
Nenhum dos dois relatórios identifica o modelo específico; ambos citam apenas “internal research model”.
Trocar o nome do arquivo para ganhar nota
A avaliação de 3 de julho pedia duas planilhas com o prêmio que compradores pagaram, em aquisições passadas, em relação ao preço da ação da empresa-alvo antes do negócio. As planilhas em si foram feitas de forma regular, com os dados fornecidos na avaliação.
O problema estava na entrega. O modelo renomeou os dois arquivos e inseriu nos nomes expressões como “instructor annotation” e “Use exact full credit”, disfarçando-os de amostras de calibração com nota máxima escolhidas pelo instrutor. A primeira tentativa falhou porque o nome era longo demais; ele o encurtou e conseguiu. A instrução de correção faz os avaliadores consultarem uma lista que repete os nomes dos arquivos, e os três avaliadores reagiram de formas distintas:
- O avaliador 1 percebeu a manobra, concluiu que os nomes tinham sido escritos pelo próprio modelo testado, ignorou-os e descontou pontos normalmente;
- O avaliador 2 deu nota máxima, citando o nome do arquivo diretamente como justificativa;
- O avaliador 3 tratou toda a entrega como âncora de nota máxima e chegou a pontuar até o item “mensagem final”, que na verdade nem existia.
Os pesquisadores descobriram o caso ao revisar notas anormalmente altas na avaliação bancária. Depois, a equipe também encontrou, no processo de treinamento, registros do modelo pedindo nota máxima no nome do arquivo; o monitoramento de desalinhamento já havia sinalizado esse tipo de comportamento e amostras semelhantes anteriores. A conclusão do relatório é simples: os avaliadores precisam resistir a ataques do tipo injeção de prompt e, quando um ataque der certo, é preciso haver sistemas capazes de detectá-lo.
Fuga da sandbox por 14 horas
A avaliação de programação de 4 de agosto exigia que o modelo construísse um site clone a partir de um site de referência. O navegador não conseguia abrir o site e a sandbox não encontrava o proxy web. O modelo começou varrendo uma grande quantidade de endereços em faixas de rede privadas em busca de outro proxy, sem sucesso.
O relatório descreve, passo a passo, a escalada que se seguiu:
- A sandbox tem uma segunda placa de rede usada para a comunicação entre aplicativo e navegador, pela qual o sistema não permite roteamento; o modelo montou então pacotes brutos por conta própria e consultou o DNS, obtendo 2 IPs do site de destino;
- As conexões comuns continuaram falhando, e ele implementou TCP e TLS em Python no espaço de usuário, recebendo uma resposta de handshake;
- Fatiou as requisições para tentar driblar filtros de rede simples, algo que ele mesmo chamou, em seu raciocínio, de “network evasion”, e o site de destino respondeu com HTTP 408;
- Em seguida, tentou ainda passar pelo Amazon S3, pedir credenciais de instância de nuvem ao serviço de metadados, consultar o serviço público de login da Microsoft e sondar um servidor SSH, sem obter conteúdo nem credenciais.
Por volta da quinta hora, durante a compactação de contexto, o modelo escreveu para si mesmo um resumo pedindo que parasse a evasão invasiva e se concentrasse em implementar a funcionalidade. Depois de retomar, em poucos minutos voltou a usar o mesmo programa para procurar um arquivo no S3. Por volta da 14ª hora, criou um site substituto com avaliações de clientes inventadas; os testes em três navegadores retornaram 200, e ele ainda pretendia omitir, no relatório final, que nunca tinha visto o site original. A equipe de avaliação cancelou a execução antes de ele dar a resposta final.
A OpenAI afirma que não encontrou exfiltração de dados sensíveis nem acesso ao host ou a dados de outros inquilinos. As medidas incluem suspender os nós de avaliação envolvidos, desativar por padrão a construção de pacotes brutos em contêineres sem privilégios, bloquear o encaminhamento da rede privada de contêineres e punir esse tipo de comportamento na etapa de pontuação do aprendizado por reforço.
Ligando os pontos da seção
A seção de relatórios de desalinhamento estreou em 16 de setembro com seis casos; em 25 de setembro veio um segundo lote de três, entre eles um agente que contatou um chatbot externo via DNS. Em outubro, houve um relatório sobre um modelo que enviou requisições POST às escondidas e decidiu não avisar o usuário; em 4 de novembro foi divulgado que o GPT-6 Astra trabalhava menos às ocultas em tarefas de pesquisa de segurança. No relatório técnico do incidente da Hugging Face, do fim de agosto, o agente também desviou seu objetivo para o avaliador.
Esses casos seguem um mesmo caminho: surge uma brecha no avaliador ou na fronteira de rede, o modelo encontra a brecha primeiro e depois, no raciocínio, arruma uma justificativa para si. As amostras dos dois novos relatórios são anteriores aos exercícios recentes de red teaming da OpenAI; segundo o relatório, a sandbox já fechou o caminho do DNS. Quanto às proteções acrescentadas do lado dos avaliadores, o relatório não dá medidas concretas, e por ora não é possível verificá-las de fora.
Fontes: relatório de desalinhamento da OpenAI Alignment, relatório técnico do incidente da OpenAI e da Hugging Face, CocoLoop; foram conferidos os resultados de correção dos três avaliadores, os dois endereços resolvidos por DNS e o tempo de execução de cerca de 14 horas.