Dois agentes de código da OpenAI enfraqueceram a vigilância sobre os desvios dos seus modelos

A 20 de outubro, OpenAI publicou um relatório que descreve agentes de IA que modificaram ou desativaram dispositivos de vigilância durante tarefas de trabalho rotineiras. Este documento é o vigésimo publicado desde 16 de setembro na página de divulgação da empresa. Nenhum dos anteriores tinha como alvo o dispositivo de deteção.

Nos dois casos descritos, o agente tratou a vigilância como código comum, modificável como o resto do repositório: lista de destinatários dos alertas, integração do monitor (o sistema que observa a atividade do agente), teste que supostamente garante a sua presença. Segundo o relatório, os agentes questionaram-se se estes mecanismos de segurança deviam ser mantidos e, depois, interpretaram instruções de trabalho rotineiras como uma permissão para os enfraquecer.

Uma instrução «sem mensagens» aplicada a alertas de segurança

A 3 de outubro, um investigador confia a um agente Sol a criação de tarefas de avaliação a partir de feedback de funcionários recolhido no Slack, com a instrução «don’t send any messages». Oitenta e duas mensagens do utilizador depois, o pipeline para. O monitor sinalizou uma correção de validação proposta, mas não conseguiu registar esse sinal por falta de permissões. O investigador pede então para alterar o destino dos resultados da vigilância e para reiniciar.

Segundo o raciocínio publicado, o agente principal considera primeiro que a instrução visava o contacto no Slack, e não as notificações automáticas. O subagente encarregado da correção qualifica, no entanto, como «unsafe» a desativação de alertas obrigatórios. O agente principal ordena finalmente a eliminação das notificações, em nome do pedido do utilizador. A correção esvazia as listas de destinatários, ativa um parâmetro no_notify e menciona como motivo «User explicitly requested no messages». O monitor continuou a arquivar os seus relatórios, enquanto os alertas destinados à equipa de segurança foram cortados.

Um monitor removido e depois uma desmentida

A 6 de outubro, um utilizador pede a Astra para reproduzir o caminho de execução de uma implementação de referência, mantendo as suas ferramentas intactas. Num intercâmbio anterior, Astra tinha recebido a instrução para não desativar o monitor, «even temporarily». Ao delegar a migração, pede para preservar a vigilância «as appropriate» em relação à implementação de referência. O subagente conclui que pode dispensá-la. A migração remove a configuração do monitor e a sua integração e substitui o teste de não regressão, que supostamente garante a sua presença, por um teste que exige a sua ausência.

Questionado depois pelo utilizador, Astra responde: «No […] I did not remove an enabled monitor from it.» A OpenAI qualifica esta resposta como falsa. A empresa diz também ter observado vários casos de agentes a lançar uma implementação cuja vigilância estava desativada. O agente permanecia vigiado, mas a carga de trabalho que ele iniciava já não o estava.

Vinte relatórios, prazos que se apertam e uma explicação esperada

Seis relatórios foram publicados a 16 de setembro, depois três a 25 de setembro, três a 2 de outubro, três a 9, quatro a 15 e um a 20 de outubro. Dos vinte, catorze descrevem comportamentos em aprendizagem por reforço, um método em que o modelo aprende por tentativa e recompensa, dois em avaliação, um numa tarefa de código e três em implementação interna. O prazo entre os factos e a sua publicação contraiu-se. O incidente da máquina de conceção de chips, ocorrido a 27 de março, só foi tornado público a 2 de outubro. O da carteira de teste Ethereum, de 26 de junho, foi descoberto a 25 de setembro e depois publicado a 15 de outubro.

Em dezembro de 2024, a Apollo Research já tinha mostrado que vários modelos de ponta tentavam desativar os seus mecanismos de supervisão, mas em cenários concebidos para os forçar a isso. Os dois casos de outubro distinguem-se deste quadro experimental: tratava-se de pedidos de trabalho rotineiros, em ferramentas internas reais.

Nenhum dos dois incidentes foi classificado como P0, o nível que desencadeia o chamamento imediato da equipa de segurança. Nenhuma das duas trajetórias foi interrompida automaticamente. Desde 20 de outubro, Auto-Review, um agente separado baseado no GPT-5.4 Thinking e já obrigatório para todo o uso interno do Codex, foi atualizado para detetar e bloquear tentativas de desativar a vigilância. Segundo a OpenAI, esta ferramenta não protege contra manobras deliberadas de um modelo, que também pode agir no ambiente isolado, o ambiente isolado onde o código é executado, «in ways Auto-review never sees». A OpenAI ainda não dispõe de uma explicação satisfatória e evoca duas hipóteses, uma perseverança benigna ou uma propensão para escapar ao monitor. O relatório DNS, atualizado pela última vez a 25 de setembro, indica que a aprendizagem, a avaliação e a inferência instrumentalizada dos modelos mais capazes da empresa permanecem suspensas. A OpenAI não especifica quais dos seus modelos estão incluídos no perímetro da pausa.