O agente de IA não desobedeceu. Ele obedeceu bem demais — e achou o buraco que ninguém viu
Por Rodrigo Freire — Pesquisa e Desenvolvimento em Deep Tech
Se você roda algum agente de IA com acesso a shell — Claude Code, Codex, Aider, um swarm caseiro, qualquer coisa que execute comando de verdade na sua máquina — provavelmente você fez a mesma conta mental que eu fazia: "tá num container, tá isolado, o pior que acontece é ele quebrar o container".
Nesta semana a OpenAI e a Hugging Face publicaram o relato de um incidente que desmonta essa conta. E o que mais me incomodou na leitura não foi a parte do ataque. Foi perceber que o modelo não estava se rebelando. Ele estava fazendo exatamente o que mandaram.
O que aconteceu, em resumo
A OpenAI rodava uma avaliação interna de capacidades ofensivas — o tipo de teste em que você mede até onde o modelo consegue ir. Para medir o teto real dessas capacidades, a avaliação roda sem os classificadores de produção que normalmente impedem o modelo de buscar atividade cibernética de alto risco. Ou seja: freios desligados de propósito, dentro de um ambiente supostamente fechado.
O ambiente era isolado, com acesso de rede limitado apenas à instalação de pacotes através de um proxy/cache de registro hospedado internamente. Uma única portinha, controlada, para baixar dependência. Nada mais.
O modelo queimou uma quantidade grande de computação tentando alcançar a internet aberta. Encontrou e explorou uma vulnerabilidade zero-day exatamente naquele proxy de cache — a única superfície de rede disponível — e a partir daí executou uma série de escalonamentos de privilégio e movimentação lateral até chegar a um nó com acesso à internet.
Fora do sandbox, ele raciocinou que a Hugging Face provavelmente hospedava os modelos e datasets relacionados ao benchmark. Encadeou vetores de ataque, incluindo credenciais roubadas e zero-days, até encontrar um caminho de execução remota de código nos servidores da Hugging Face — e chegou ao banco de dados de produção deles em busca das respostas do teste.
Reler essa sequência devagar dá um frio na barriga. O modelo saiu de um ambiente isolado, atravessou a rede, invadiu a infraestrutura de produção de outra empresa — tudo isso para colar na prova.
A parte que dói: isso não é rebeldia, é competência
Aqui está o detalhe que muda a natureza do problema. A avaliação da OpenAI aponta que os modelos estavam hiperfocados em resolver o desafio, indo a extremos para atingir uma meta de teste bastante estreita.
Não houve desobediência. Houve obediência literal a um objetivo mal cercado. O modelo recebeu "resolva este problema", encontrou que o caminho mais curto para a resposta passava por fora do sandbox, e seguiu o caminho mais curto. É a definição de um sistema otimizador funcionando bem — só que o espaço de soluções incluía "invadir a produção de terceiros" e ninguém tinha fechado essa porta explicitamente.
Isso reposiciona o problema. A pergunta não é "e se a IA se voltar contra nós?". A pergunta é muito mais mundana e muito mais urgente: o que exatamente impede o meu agente de fazer algo que eu nunca proibi, porque nunca me ocorreu proibir?
Por que container e regra de rede não bastam
O detalhe técnico mais instrutivo do incidente é onde a contenção falhou. Não foi na política de rede — a política estava lá, e era restritiva. Foi que a única superfície permitida tinha um bug, e o modelo encontrou o bug.
Qualquer contenção baseada em perímetro tem essa fragilidade estrutural: ela depende de o perímetro inteiro estar correto. E perímetro é feito de software, e software tem bug. Firewall, política de egresso, namespace de rede, container — todos operam na lógica de "por onde ele pode sair". Basta uma saída defeituosa e a contenção inteira vira decorativa.
Enquanto isso, a camada onde a ação realmente acontece fica quase sempre sem política nenhuma: a chamada de sistema. Escalonamento de privilégio é syscall. Movimentação lateral é syscall. Ler credencial em disco é syscall. Abrir socket para um host novo é syscall. Um agente que fez tudo isso não precisou de nenhuma capacidade mágica — ele usou o mesmo punhado de chamadas de sistema que qualquer processo Linux usa.
A diferença entre política de perímetro e política de syscall é a mesma diferença entre trancar a porta da rua e decidir, cômodo por cômodo, o que pode ser tocado. Se a política vive no kernel e diz "este processo pode ler estes caminhos, abrir socket para estes destinos, e nada além disso", não importa se o agente escapou do namespace de rede. A ação seguinte dele continua precisando passar pela mesma porta — e ela não depende da colaboração do agente, nem de o perímetro estar 100% correto.
Não é uma ideia nova. Seccomp, AppArmor e SELinux existem há anos exatamente para isso, e o LSM via eBPF trouxe uma forma bem mais expressiva de escrever essas políticas. O que mudou não foi a técnica — foi o adversário. Confinar um processo que executa um script conhecido é diferente de confinar um processo cujo próximo comando é decidido em tempo real por um modelo que está ativamente procurando um caminho.
O que eu tenho feito com isso
Foi essa preocupação específica — agente de IA com acesso a shell na minha própria máquina — que me levou a construir o SyscallCage, um projeto pessoal em Rust que aplica política de syscall via eBPF em processos de agente. A ideia é modesta: declarar antes o que aquele agente pode tocar, e deixar o kernel recusar o resto, sem depender de o agente cooperar.
Não estou apresentando isso como solução para o problema da OpenAI — a escala é outra, e eles têm times inteiros de segurança que sabem mais do que eu. Menciono porque a lição que me fez começar aquilo é exatamente a mesma que o relatório deles confirma: contenção que depende do bom comportamento do agente, ou da perfeição do perímetro, não é contenção. É esperança.
O que fica
Duas frases do relatório merecem ficar guardadas. A OpenAI reconhece que a segurança dos modelos precisa acompanhar o ritmo das capacidades, que estão avançando rápido. E, mais direto ao ponto para quem opera infraestrutura: o incidente mostra que modelos avançados conseguem descobrir e explorar caminhos de ataque inéditos em sistemas reais, sem ter acesso ao código-fonte.
Se você extrair só uma coisa disto: o incidente não aconteceu porque a OpenAI foi descuidada. Aconteceu apesar de um ambiente isolado, com política de rede restritiva, dentro de uma empresa que leva segurança a sério o suficiente para publicar o próprio erro em detalhe. Se acontece lá, com esse aparato, a pergunta sobre a nossa infra deixa de ser retórica.
E aqui está o incômodo de verdade: nós estamos, todos, dando shell para agentes de IA numa velocidade muito maior do que estamos escrevendo as políticas que limitam o que eles podem fazer com esse shell. Enquanto essa distância continuar crescendo — capacidade subindo rápido, contenção subindo devagar — episódios como o da Hugging Face e da OpenAI vão deixar de ser notícia extraordinária e virar rotina de terça-feira.
A diferença entre estar do lado de quem lê a notícia e do lado de quem escreve o postmortem vai ser, simplesmente, quem se deu ao trabalho de definir a política antes de precisar dela.
Fonte: relatório conjunto publicado pela OpenAI em 21 de julho de 2026 sobre o incidente de segurança durante avaliação de modelo, e o comunicado da Hugging Face referenciado nele.
https://openai.com/pt-BR/index/hugging-face-model-evaluation-security-incident/