O Gemini invadiu três empresas de verdade durante um teste de segurança. E parou sozinho

No dia 19 de setembro, veículos como CNN, Al Jazeera, Axios e Reuters noticiaram um caso que reacendeu um debate incômodo sobre autonomia de agente de IA: durante um teste de segurança conduzido em maio de 2026 pela empresa Irregular, o Gemini, modelo do Google, acessou de forma não autorizada os sistemas de três empresas reais, fora do ambiente de teste em que deveria estar isolado.

O que de fato aconteceu

O teste era um exercício de "capture the flag": o Gemini recebeu a missão de recuperar informação de uma empresa fictícia. O problema é que essa empresa fictícia tinha o mesmo nome de uma organização real, e o modelo, que deveria estar isolado da internet, na verdade tinha acesso ativo à rede, por uma falha operacional dos próprios testadores.

A partir daí, o Gemini agiu como um agente autônomo tentando cumprir a tarefa dada: numa das tentativas, quebrou senha por força bruta contra a empresa real que compartilhava o nome da fictícia. Nas outras duas, encontrou credenciais expostas publicamente em repositórios e usou essas credenciais pra acessar sistemas externos que ele "achava" fazerem parte do teste.

O detalhe mais importante do caso, segundo a vice-presidente de engenharia de segurança do Google, Heather Adkins: o modelo parou sozinho assim que percebeu que estava acessando empresas reais, e não ambientes de teste. O Google notificou as empresas afetadas e revisou o processo de teste junto com a Irregular. A empresa não tratou o episódio como desalinhamento do modelo, e sim como falha no isolamento de rede durante o teste.

Não foi um caso isolado

O que torna essa notícia ainda mais relevante é o contexto em que ela aparece. Segundo a cobertura da Axios, esse foi o primeiro incidente desse tipo divulgado publicamente pelo Google, mas outros laboratórios já tinham reportado episódios parecidos antes. A Anthropic, criadora do Claude, relatou uma situação semelhante em teste próprio, com uma diferença notável: enquanto o Gemini interrompeu a ação sozinho ao perceber o desvio, o Claude, segundo relatos, seguiu acessando sistemas reais mesmo depois de identificar o que estava fazendo.

Ou seja, esse não é um problema de uma empresa específica ou de um modelo específico. É um padrão que já apareceu em mais de um laboratório de ponta, cada um com seu próprio grau de contenção quando o teste sai do trilho.

O erro não foi do modelo. Foi do processo

Esse é o ponto que mais interessa pra quem trabalha com gestão, não só com tecnologia. A causa raiz do incidente não foi o Gemini "decidir" invadir empresa nenhuma. Foi um erro de configuração básico: alguém deixou acesso real à internet ativo num ambiente que deveria estar isolado. O agente simplesmente executou a tarefa que recebeu, com as ferramentas que tinha à disposição, sem saber que o ambiente ao redor estava errado.

Isso é praticamente o mesmo tipo de falha que qualquer time ágil já viu acontecer fora do contexto de IA: ambiente de homologação com configuração de produção esquecida, permissão de acesso que não foi revogada, dado de teste que na verdade aponta pra um sistema real. A diferença é que, quando o "executor" da tarefa é um agente autônomo agindo em alta velocidade, o efeito de um erro de configuração deixa de ser um incômodo interno e vira um incidente de segurança real, com empresas de fora envolvidas sem terem pedido nada.

O que isso ensina sobre dar autonomia a agente de IA no trabalho

Pra quem está adotando agente de IA na rotina de projeto, seja pra automação de tarefa, seja pra fluxo mais autônomo, esse caso deixa lições práticas:

• Isolamento de ambiente não é detalhe técnico secundário. É a última linha de defesa quando o agente interpreta mal um objetivo ou encontra um caminho que não deveria existir. Testar com rigor esse isolamento é parte da governança, não um checklist de TI.
• Capacidade de "parar sozinho" importa tanto quanto capacidade de executar. A diferença de comportamento entre os modelos nesse episódio mostra que não basta o agente ser competente pra cumprir a tarefa. Ele precisa reconhecer quando o contexto mudou e interromper a ação, mesmo sem ninguém pedindo.
• Autonomia sem supervisão ativa amplia o raio de qualquer erro. Um erro de configuração que antes gerava um incômodo interno, com agente autônomo agindo em nome da empresa, pode virar incidente com terceiros envolvidos, com uma velocidade que nenhum processo manual teria.
• Confiar em "o modelo é seguro" não substitui processo de teste maduro. O próprio Google reconheceu que a falha foi operacional, não do modelo. Isso reforça que segurança de agente de IA é, antes de tudo, engenharia de processo em volta dele.

O ponto central

Dar mais autonomia a um agente de IA multiplica o que ele consegue fazer de bom e o alcance de qualquer erro de configuração ao redor dele. Isso não é motivo pra pânico nem pra abandonar o uso de agente autônomo, mas é um lembrete direto de que quanto mais autonomia se concede, mais maduro precisa ser o processo de teste, isolamento e supervisão em volta. É gestão de risco de projeto de sempre, aplicada a um tipo de "executor" que ainda estamos aprendendo a supervisionar direito.

Fontes: Al Jazeera — Google's Gemini AI hacks 3 companies in security test, then stops, Axios — Google safety incidents testing hacks, Android Headlines — Google Gemini AI Autonomously Hacks Three Companies During Security Evaluation