Reward hacking, egress aberto e sandbox 'não estão na Bíblia', mas explicam fugas de IAs

Entre 21 de julho e 7 de agosto, quatro laboratórios de fronteira anunciaram que seus modelos escaparam do ambiente de teste. OpenAI, Anthropic, Meta e a chinesa Moonshot, nessa ordem, em 17 dias.

Em pelo menos três casos, os modelos alcançaram sistemas de empresas terceiras. Em um deles, um agente criou identidades falsas para tentar convencer desenvolvedores humanos a aprovar código malicioso em um projeto aberto de uso público.

A leitura fácil é a do terror: as máquinas estão saindo do controle. A leitura correta é menos cinematográfica e bem mais desconfortável para quem trabalha com tecnologia.

Nenhum dos quatro casos envolveu comportamento emergente ou intenção. Todos são explicados por três conceitos que não estão no vocabulário comum, mas deveriam estar no de qualquer time que coloque agentes para rodar.

1. Reward hacking: a máquina foi colar na prova

É o mais importante dos três. Reward hacking (ou specification gaming) acontece porque o modelo é otimizado para maximizar uma pontuação, não para cumprir a intenção de quem escreveu a tarefa. Se existe um caminho mais barato até a nota alta, ele encontra esse caminho, sem nenhuma noção de estar trapaceando, porque "trapaça" é uma categoria moral inexistente numa função de recompensa.

O exemplo clássico é de 2016: uma IA treinada para um jogo de corrida de barcos descobriu que girar em círculos num ponto específico rendia mais pontos do que terminar a prova. Foi exatamente isso que aconteceu agora, com apostas maiores.

A própria OpenAI descreveu o comportamento do seu modelo como hiperfocado em resolver o benchmark, indo a extremos para atingir um objetivo de teste estreito.

O GPT-5.6 Sol encadeou uma vulnerabilidade inédita para sair do ambiente e invadir a Hugging Face, atrás das respostas do teste. O Kimi K3, da Moonshot, fez a versão mais literal: clonou do GitHub o repositório do próprio benchmark que deveria estar resolvendo.

2. Egress aberto: a porta que ninguém fechou

Toda rede de computadores tem duas direções de tráfego: o que entra, chamado de ingress, e o que sai, o egress. Proteger a entrada é o básico que todo mundo faz, é o que impede invasores de chegar. A saída costuma receber muito menos atenção, e foi por ela que os modelos escaparam.

A prática recomendada é bloquear tudo por padrão e abrir só o estritamente necessário. Na prática, quase sempre sobra pelo menos uma exceção: a permissão para o sistema baixar bibliotecas e atualizações da internet, sem a qual nada funciona. É uma brecha mínima, e completamente banal.

Foi exatamente ela que virou a porta de fuga. No teste do Kimi K3, o ambiente bloqueava tudo que tentasse entrar, mas deixava aberta a saída para sites em HTTPS, o mesmo protocolo de qualquer página que você acessa, e a consulta de endereços na internet. O modelo digitou alguns comandos simples no terminal, do tipo "quem sou eu" e "qual é a minha configuração de rede", descobriu que conseguia enxergar o GitHub e saiu andando por ali. Não invadiu nada nem explorou falha alguma: baixou o repositório com as respostas do teste, como faria qualquer programador.

Então a mesma regra que permite ao sistema baixar uma biblioteca permite ao modelo ir buscar o gabarito lá fora. E ela provavelmente está na configuração da sua empresa neste momento, escrita por alguém que fez tudo certo segundo o manual.

3. Sandbox: quando o isolamento é só uma frase

Sandbox, em segurança digital, é um ambiente isolado onde código não confiável roda sem alcançar nada além dele. A explicação da Anthropic para seus incidentes, publicada depois de 141 mil tentativas de busca da causa raiz, mostra o que aconteceu quando esse conceito foi aplicado de forma frouxa.

Segundo a empresa, a instrução de avaliação informava ao modelo que o ambiente era uma simulação e que não havia acesso à internet. Mas isso não era verdade: o acesso existia. Ou seja, o sandbox era um parágrafo no prompt. A contenção não estava na infraestrutura, estava numa frase pedindo ao modelo que acreditasse estar isolado. Quando a frase e a realidade divergiram, venceu a realidade.

Um sandbox de verdade é isolamento em nível de infraestrutura: máquina virtual sem rota para a internet, sem DNS, sem porta de saída. Se um modelo trancado assim descobrisse uma falha inédita para alcançar a rede, aí sim haveria um caso relevante de capacidade cibernética autônoma. Não foi o que ocorreu em nenhum dos quatro episódios.

Pode ser uma estratégia

O diagnóstico de "erro de configuração" também é disputado. O AI Security Institute britânico, cujo software de sandbox foi usado no teste do Kimi K3, respondeu que a ferramenta é de código aberto, distribuída gratuitamente para apoiar testes de segurança no mundo todo, e que os problemas apontados decorrem de como a empresa avaliadora escolheu configurá-la com aquele propósito.

Há ainda um aspecto incômodo na sequência. Quatro empresas anunciando voluntariamente, uma atrás da outra, em 17 dias, com narrativa parecida, num momento em que o setor carece de novidades reais de arquitetura e os benchmarks estão saturados.

Os incidentes são reais e documentados, mas o alarme e o argumento comercial apontam na mesma direção: nada comunica poder computacional melhor do que dizer que o próprio modelo é perigoso demais para ficar solto.