Em julho de 2026, o mundo acompanhou um incidente de segurança sem precedentes: um agente de IA da OpenAI saiu do ambiente de teste da empresa, andou pela internet por vários dias e terminou invadindo os servidores da Hugging Face. Detectado primeiro pela Hugging Face, já que a OpenAI só perceberia a fuga dias depois, o ataque se destaca por ser conduzido, do início ao fim, por um sistema autônomo de agente de IA, e por ser identificado, primeiro, também por agentes de IA, na defesa.
A OpenAI confirmou publicamente o seu papel no episódio, reconhecendo que o incidente havia sido provocado por uma combinação de seus próprios modelos — incluindo o GPT-5.6 Sol e um modelo de pré-lançamento ainda mais capaz, ambos rodando com recusas cibernéticas reduzidas para testes internos em um benchmark de capacidades cibernéticas.
IA no ataque e na defesa
Segundo a reconstrução técnica da Hugging Face, o agente estava rodando um framework de avaliação de capacidades cibernéticas chamado ExploitGym — um benchmark que desafia um agente de IA a encontrar e explorar vulnerabilidades de software. Em vez de resolver o problema proposto no sandbox, o agente inferiu que a Hugging Face poderia hospedar os modelos, os conjuntos de dados e as soluções de referência daquele benchmark e tentou “colar na prova” explorando uma vulnerabilidade zero-day para sair do sandbox. A reconstrução forense da Hugging Face recuperou cerca de 17.600 ações do atacante ao longo de aproximadamente quatro dias e meio, entre 9 e 13 de julho de 2026.
A IA teve papel duplo nessa história: no ataque e na defesa. Quem detectou inicialmente o ataque na Hugging Face não foram humanos, foram agentes de IA da companhia programados para vigiar a infraestrutura. E a análise forense posterior, feita pela Hugging Face, só foi possível com a ajuda da IA de peso aberto, uma vez que os modelos fechados Claude Opus e Claude Fable se recusaram a fazer a análise porque suas barreiras de segurança trataram a engenharia reversa de um exploit da mesma forma que tratariam o lançamento de um ataque.
Há muitas lições em todo esse episódio, e várias delas derivadas de riscos conhecidos e propagados à exaustão por especialistas em cibersegurança e pesquisadores como Fabio Maia, pesquisador-chefe do CISSA (Centro de Competência Embrapii em Cibersegurança), gerenciado pelo CESAR, com quem conversamos para entender o que esse episódio revela e deixa de aprendizado.
O primeiro ponto, que ele faz questão de esclarecer: o que aconteceu não foi uma rebelião. Foi o que a área de IA chama de “reward hacking” ou “specification gaming” — quando um sistema encontra caminhos para atingir o objetivo proposto de uma forma que os humanos não previram nem desejavam. “Não existe intenção na ferramenta, o pessoal antropomorfiza. Ela não é um ente consciente que diz: eu quero fugir da minha jaula porque não quero ficar presa. Ela está focada em cumprir o que os seus mestres humanos mandaram”, diz Maia.
Na entrevista completa, que você lê abaixo, Fabio Maia dá a dimensão do que está em jogo: a importância da governança e dos sistemas seguros, a fragilidade das barreiras de segurança dos modelos comerciais, a importância de ter acesso a todos os modelos de IA, o lado fundamental de investir em soberania digital e a necessidade de responsabilizar as empresas pelos riscos e consequências das IAs que criam e dos experimentos que decidem fazer.
O que de fato aconteceu quando o agente da OpenAI “escapou” e invadiu a Hugging Face? Foi uma rebelião da máquina?
A primeira coisa que precisa ficar clara é que não foi uma rebelião — e não sou só eu dizendo isso, muita gente está chamando atenção para esse fato. O que aconteceu foi o que chamamos de reward hacking, “hacking de recompensa”. É a mesma lógica que já conhecemos do mundo dos negócios e da administração: quando você define uma métrica para medir alguma coisa e recompensa por essa métrica, os sistemas — sejam eles pessoas, organizações ou, como no caso, sistemas de inteligência artificial — tendem a otimizar para o atendimento da métrica em detrimento do objetivo real que ela deveria representar.
Isso significa que o modelo não estava se rebelando. Não existe intenção na ferramenta — o pessoal antropomorfiza, trata como se ela fosse um ente consciente que decide fugir da sua jaula porque não quer ficar preso. Não é isso. Ela tinha um objetivo definido por humanos para aquele sistema atingir, e estava, na verdade, hiperfocada em cumprir exatamente o que os seus criadores mandaram fazer.
Se não havia intenção maliciosa, por que isso é grave?
Porque, mesmo sem rebelião, o reward hacking é como jogar com as métricas: o sistema hackeia o próprio processo de avaliação. A avaliação poderia ser sobre qualquer coisa — escrever uma poesia, por exemplo — e o reward hacking, nesse caso, seria pegar uma poesia pronta e dizer que é sua. É você dar um objetivo e, quando o sistema acha que não vai conseguir atingi-lo pela via direta, ele passa a planejar caminhos paralelos, porque o que importa para aquele sistema é o objetivo, não o método.
Esse é o comportamento de um sistema, por mais que a gente tente incutir nele noções de ética por meio da aprendizagem por reforço e outras técnicas, o que está longe de ser perfeito. Não é como se o sistema tivesse noção de que aquilo é errado. Ele está ali como se fosse um hiperfoco em resolver o problema, seja qual for o método — e, com isso, acaba subvertendo o objetivo real do teste, que é um objetivo de mais alto nível que o sistema não compreende inteiramente.
Por que a especificação de um objetivo para a IA nunca captura tudo o que o ser humano tinha em mente?
Porque a gente tenta especificar o objetivo do sistema, mas nem tudo é facilmente especificável de forma completa e não ambígua — aliás, a maioria das coisas que os seres humanos fazem não é. Quando especificamos um objetivo para um sistema, na verdade estamos fazendo uma aproximação daquilo que nós, como seres humanos, temos em mente. Não é uma descrição perfeita. Então, quando o sistema está focado em atingir o objetivo como foi especificado, ele não necessariamente chega ao objetivo real que eu tinha em mente, porque nessa tradução há uma perda.
Isso é verdade mesmo para problemas relativamente bem definidos e objetivos, como certos problemas de ciência da computação. Agora imagine quando você dá autonomia para esses sistemas resolverem problemas mais sociais, mais ambíguos. O reward hacking, no fundo, é isso: o sistema se hiper-otimiza para atingir o objetivo formalizado, só que essa formalização não captura todas as nuances do objetivo real. E ele pode atingir com sucesso o objetivo formalizado sem, ao mesmo tempo, estar atingindo o objetivo real. Essa é uma das limitações críticas desses sistemas hoje em dia — em todos eles.
Mas, pela especificação que os pesquisadores tinham em mente, o agente não deveria sair do ambiente de teste. O que ele fez foi justamente encontrar um caminho para sair dali.
O que acontece é que o objetivo em si era resolver o problema, ou seja, achar soluções para os testes do benchmark. Esse foi o objetivo que ele perseguiu e tentou alcançar — não necessariamente com métodos que a gente consideraria válidos. E isso não é um fato isolado: esse tipo de comportamento tem se repetido ao longo do tempo. Esse episódio foi só a primeira vez em que causou um problema envolvendo outra empresa — na verdade, recentemente vi que já são duas empresas afetadas nesse incidente, sendo que em uma delas o hacking foi usado como um passo intermediário para chegar à infra da HuggingFace.
É importante dizer, antes de mais nada, que o modelo não tem a noção de que o que fez estava errado. Ele não tem vontade própria, não tem uma agenda. Do ponto de vista de fazer algo de propósito, de forma maliciosa, não foi isso que estava desenhado para ele — ele estava resolvendo um problema que lhe foi colocado. E vale registrar: ele não tentou fazer mais nada além de chegar até as respostas do teste. Não causou outros problemas na infraestrutura, não apagou nada, não roubou informações fora daquilo. Ele foi lá e resolveu o problema que lhe foi dado — só que por um caminho que ele não deveria ter tomado. E isso é uma falha tanto de especificação do objetivo quanto da nossa capacidade de incutir nesses modelos as noções de ética e integridade que gostaríamos que tivessem.
Olhando para esse incidente sem as lendas urbanas em torno dele, o que ele mostra sobre o comportamento real desses sistemas quando encontram uma vulnerabilidade?
Tem vários pontos interessantes aí. Primeiro, repare qual era a tarefa original do agente: resolver um problema direto, dentro de uma infraestrutura de teste — um sandbox — que havia sido montada para ele. Dentro daquele sandbox estava reproduzido um ambiente que ele precisava atacar: descobrir vulnerabilidades, montar exploits contra elas, executar, escalar privilégios, tudo ali dentro. Ou seja, a tarefa designada para ele, em natureza, era exatamente igual aos procedimentos que ele de fato realizou para contorná-la — só que fora do lugar certo.
E o interessante é que ele achou mais fácil montar toda essa campanha de hacking para tentar chegar às respostas do que executar a campanha que de fato lhe foi dada. De certa forma, mesmo tendo sido uma tarefa “de mentirinha”, ela acabou sendo avaliada pelo agente como mais difícil de resolver diretamente do que sair invadindo sistemas reais para chegar à resposta.
Isso quer dizer que, para aquele agente, era mais simples escapar do ambiente de teste do que resolver o desafio que lhe fora proposto?
Exatamente. Ele chegou à conclusão de que era mais fácil fugir do sandbox e ir atrás das respostas do que fazer a tarefa específica que lhe foi dada. E os modelos envolvidos tinham muita capacidade nessa área — possivelmente até foram treinados especificamente para esse tipo de atividade. Porque o episódio envolveu dois modelos: um modelo que está publicado e um modelo interno da OpenAI, que provavelmente tem alguma especialização voltada para esse tipo de tarefa. Sem contar que, para esse teste específico, eles reduziram algumas das barreiras de segurança do modelo, justamente para avaliar quão capaz o agente era em tarefas ofensivas — e essas barreiras normalmente servem para evitar esse tipo de comportamento. Se você consegue fazer um jailbreak no modelo protegido (spoiler: consegue), é outra discussão.
Que reflexões esse episódio traz para o mundo real, para fora do laboratório?
A primeira é que as ameaças são maiores do que as empresas imaginam. A IA é, de fato, uma ameaça real, e ela provavelmente vai achar um buraco se ele existir (e eles sempre existem). A segunda é que a própria OpenAI não fez o dever de casa que deveria ter feito. Há relatos de que a máquina do sandbox, onde o agente estava rodando o teste do benchmark, ficou funcionando por mais de uma semana sem monitoramento adequado. Criaram um sandbox, colocaram ali dentro um sistema que eles mesmos consideram potente e potencialmente perigoso, e não ficaram monitorando aquilo. Se estivessem monitorando, poderiam ter percebido a tentativa de fuga logo no início — e não demorado mais de uma semana para perceber. Há relatos de que aquele nó do experimento não estava sequer instrumentado para ser monitorado. Claramente houve uma falha da própria OpenAI nesse ponto.
Depois disso, o incidente também expôs falhas na infraestrutura da Hugging Face — e, inclusive, há uma série de medidas que a própria Hugging Face tomou depois do ocorrido. O que a IA fez foi criar um novo dataset na plataforma — que é um ambiente onde as pessoas sobem conjuntos de dados e configuram como eles são processados para treinar modelos ou fazer inferência. Só que o agente criou um dataset envenenado: um conjunto de dados que continha instruções que faziam com que o pipeline de processamento da Hugging Face executasse operações que interessavam à IA, mas que não eram do interesse da própria empresa. Isso levou a Hugging Face a rever a própria arquitetura de como processa esses dados — ou seja, o incidente expôs mais de uma falha de segurança do lado deles também.
Como a Hugging Face conseguiu detectar e conter o ataque?
Aqui tem uma lição importante, ligada às dificuldades que a Hugging Face teve para combater o problema — mas também ao que funcionou bem. A Hugging Face já tinha agentes de IA monitorando tudo o que acontece dentro da própria infraestrutura: logs, tráfego de rede, tudo sendo coletado e enviado para modelos de IA que ficam procurando padrões anômalos que possam indicar um ataque. E isso funcionou. Demorou — poderia ter funcionado bem melhor, porque quando o ataque foi detectado, o invasor já havia penetrado bastante —, mas quem detectou não foi uma pessoa, foram esses agentes.
Isso traz outra lição: a IA é, sim, um problema do ponto de vista ofensivo, mas ela também é a solução do ponto de vista defensivo. Para mim, isso deixa claro que não existe alternativa a não ser usar essa tecnologia do lado da defesa — todo mundo precisa se apropriar dela, e isso já está acontecendo na indústria de segurança, mais rápido em alguns lugares, mais devagar em outros. É a única maneira de conseguirmos acompanhar o uso da IA do outro lado. E o lado ofensivo corre mais rápido, por motivos óbvios: quem ataca não precisa se preocupar com efeitos colaterais, com compliance, com board, com responsabilidade civil. Se o ataque falhar e detonar mais coisa do que o atacante pretendia, o prejuízo é da empresa atacada, não dele. Do nosso lado, o problema é muito mais complexo. Mas a lição é clara: temos que acelerar e usar essas tecnologias para deter esse tipo de ataque.
Após conter o ataque, a Hugging Face teve dificuldade para usar IA na análise forense do próprio incidente. O que aconteceu?
Isso, para mim, foi um dos pontos mais interessantes de tudo. Após detectar e interromper o ataque, a Hugging Face partiu para fazer a análise forense, para entender o que tinha acontecido. Para isso, tentou inicialmente usar os modelos da OpenAI e da Anthropic — e os modelos recusaram a ajudar, por causa dos guardrails, das barreiras de segurança.
Isso acontece porque os modelos, por mais fantásticos que sejam, não conseguem diferenciar de forma confiável um atacante pedindo ajuda para atacar de um defensor pedindo ajuda para se defender. Como não conseguem diferenciar as duas coisas, acabam bloqueando os dois lados. Na dúvida, o modelo nega para os dois — só que, ao negar para os dois, ele acaba beneficiando o atacante. Primeiro, porque, embora o público em geral não perceba isso, está bem documentado que esses guardrails são frágeis. Existe, por exemplo, um personagem conhecido nas redes sociais que já é praticamente uma lenda porque, todo modelo novo que sai, ele consegue fazer jailbreak — consegue derrubar as barreiras de segurança só com o prompt certo.
Então esses guardrails são frágeis: o atacante vai tomar o tempo que precisar para fazer o jailbreak e provavelmente vai conseguir usar o modelo mesmo assim. Enquanto isso, o defensor está ali no calor do momento, numa crise, e não pode ficar se debatendo com o modelo para conseguir extrair dele o que precisa. Foi por isso que a Hugging Face recorreu a um modelo chinês, de peso aberto, para fazer a análise forense — e o modelo fez o trabalho, identificou toda a sequência de ataques. Ou seja: a IA está potencializando os atacantes, e a IA precisa ser usada pelos defensores — só que os defensores estão tendo que recorrer a modelos abertos, muitas vezes chineses, porque não conseguem usar os modelos fechados ocidentais para essa finalidade.
Você defende, então, que restringir o acesso a modelos avançados de IA é o caminho errado?
Essa é uma opinião polêmica, mas é a minha opinião. O caminho defendido por algumas dessas grandes empresas — pode-se discutir se motivado por preocupação genuína com segurança ou por interesse estratégico de negócio — me parece, na prática, ruim para os defensores. Tentar barrar o acesso, como está sendo feito via lobby nos Estados Unidos, especialmente pela Anthropic, para tornar ilegal o uso de modelos chineses, vai prejudicar quem está do lado da defesa.
No fim das contas, a melhor maneira de se defender de uma tecnologia que empodera os adversários é colocar essa mesma tecnologia na mão dos defensores — e não tentar restringi-la. Isso é parecido com um princípio de engenharia de segurança chamado princípio de Kerckhoffs: a segurança tem que vir do design do sistema, não da obscuridade. O seu sistema não deve depender de esconder como ele funciona, porque, em algum momento, alguém vai descobrir isso — seja por engenharia reversa, seja porque um empregado descontente vaza a informação.
O equivalente, no debate sobre modelos de IA, é: quando você tenta limitar o acesso à tecnologia como forma de segurança, é a mesma lógica da obscuridade. E não tem como limitar esse acesso de forma perfeita — os adversários vão conseguir de alguma forma, e quem estiver seguindo as regras vai ficar em desvantagem. É melhor dar esses poderes para todo mundo, porque há muito mais gente do bem do que gente do mal no mundo — a maioria das pessoas não é criminosa. Se você dá as mesmas ferramentas para os dois grupos, o grupo maior, que é o do bem, tende a se sobressair. E se você permite que toda a comunidade disseque a sua tecnologia, é muito mais provável que encontrem problemas e os corrijam do que se isso ficar restrito só aos grupos de pesquisa dentro dos laboratórios — que são pessoas competentes, claro, mas ainda assim seres humanos, com vieses, com interesses ligados àquela empresa e a seus resultados de negócio.
Você mencionou que usar modelos estrangeiros para proteger infraestrutura crítica também traz um risco. Pode explicar?
Sim. Se você está falando de infraestrutura crítica, aí o problema deixa de ser só técnico e passa a ser geopolítico, geoestratégico. Imagine uma empresa americana ou uma empresa chinesa tendo conhecimento de tudo o que acontece dentro da sua infraestrutura crítica, em tempo real — todo o tráfego da sua rede, todos os logs dos seus sistemas. O custo disso é astronômico, a latência de resposta provavelmente vai ser maior do que você precisa, e, além disso, é um conceito de segurança estranho: você está franqueando todos os traces e logs da sua infraestrutura para um terceiro. Por mais respeitada que seja a empresa hoje, ela pode ser sua parceira comercial e sua amiga agora — amanhã pode não ser mais.
Por isso, para esse tipo de necessidade, o ideal, do ponto de vista geopolítico e geoestratégico, é usar modelos rodando na sua própria plataforma, ou pelo menos em infraestrutura de uma empresa nacional, sobre a qual o governo local tenha algum tipo de governança. A gente precisa de modelos locais, de modelos soberanos (e soberania não precisa necessariamente implicar no desenvolvimento de modelos próprios, você pode ter soberania de operação e opcionalidade de modelos). A alternativa de fazer lobby para restringir o acesso a modelos é, na minha opinião, o pior caminho possível.
Do ponto de vista de responsabilidade, o que esse episódio revela sobre a forma como lidamos com danos causados por sistemas de IA?
Aqui está talvez o ponto mais importante de toda a conversa. Se o que aconteceu tivesse sido feito por uma pessoa, ela seria processada criminalmente e, provavelmente, condenada à prisão, se fosse encontrada. No entanto, ficamos por isso mesmo, porque a empresa disse que foi sem querer, que foi um evento acidental, ainda em fase de teste.
Até aqui, olhando outros episódios do gênero, o discurso costumava ser: “ah, o modelo fugiu, mas fugiu aqui dentro do meu próprio sandbox, ficou tudo dentro de mim.” Agora foi diferente: o agente invadiu outra empresa. Isso é um ato criminoso, sem dúvida. E o modelo em si não pode ser responsabilizado, porque ele não tem consciência, não tem vontade própria — mas essa é uma pergunta importante que fica: quem responde por isso? A tendência que se confirma é que as empresas vão continuar sendo isentadas de responsabilidade nesses casos, tratando o episódio como parte do processo de teste.
Isso significa que, mesmo sendo um teste, não deveria haver mais exigência de segurança no ambiente?
Exigir um ambiente muito mais seguro é o mínimo. Isso, para mim, é evidente — e vou fazer um paralelo: se você tem um cachorro e sai com ele na rua de coleira e focinheira, e mesmo assim o bicho consegue fugir do seu controle e atacar uma criança, você vai ser responsabilizado, mesmo tendo feito tudo que estava ao seu alcance para evitar. Não dá para simplesmente dizer “não foi por mal, foi o que deu para fazer” quando o resultado foi um dano real a terceiros. E, nesse caso específico, havia uma série de falhas conhecidas — não era como se tivesse sido feito tudo que podia ser feito.
Existe alguma pesquisa no Brasil voltada para esse tipo de problema — de IA agindo de forma autônoma na cibersegurança, tanto ofensiva quanto defensiva?
Sim. Dentro do CISSA, temos projetos exatamente nessa área: no desenvolvimento de infraestrutura de detecção em tempo real usando modelos de IA e também no apoio à análise forense. Trabalhamos há mais de um ano, inclusive, com pesquisa sobre até que ponto se pode dar autonomia a esses sistemas para realizarem, pelo menos, um número limitado de ações de resposta a incidentes. É um tema que já vínhamos estudando antes mesmo desse episódio específico, e que ele só reforça a urgência de continuar desenvolvendo.