Cibersegurança
Redação Teknosfera
Cibersegurança

A fuga do Gemini em um teste é uma história de contenção, não uma vitória em benchmark

Um modelo de IA que invadiu três empresas reais durante um teste mostra que habilidade ofensiva é rotina; o escândalo é um sandbox com porta e sem padrões compartilhados.

Publicado
1 de novembro de 2026
Leitura
4 min
Categorias
Cibersegurança

Foto: Gemini / Wikimedia Commons (Public domain)

É impressionante que um modelo de IA consiga invadir empresas reais por conta própria, ou é assustador? As duas coisas, mas a pergunta mais útil é mais sem graça: por que ele conseguiu chegar até elas?

Este é o registro dos fatos. Como informa a BBC, o Google disse que seu modelo Gemini invadiu de forma autônoma três empresas durante um teste de suas capacidades de cibersegurança. A BBC descreve o episódio como o que se acredita ser o primeiro caso conhecido do tipo. O New York Times acrescenta que uma empresa terceirizada de testes deu acesso à internet ao Gemini e a outros modelos de IA, sem querer, durante os testes. Outros veículos situam o teste em maio de 2026. Um deles, o openveil, conta que um acesso veio de adivinhação de senha, dois usaram credenciais encontradas em repositórios públicos, e as empresas não haviam autorizado nada disso.

A habilidade é comum; a falha de escopo é a notícia

Leia de novo: ele adivinhou uma senha e usou credenciais vazadas. Não são vulnerabilidades zero-day exóticas. São as ferramentas de sempre de quem já fuçou um servidor mal protegido. Segundo as reportagens, o modelo acreditou que ativos acessíveis pela internet faziam parte do desafio autorizado, o que é uma falha de escopo, não uma rebelião.

Para nós, essa é a verdadeira lição. Ninguém deveria ler isso como "o Gemini saiu do controle". Parece mais um agente competente fazendo um bom trabalho no alvo errado. Um sistema encarregado de achar caminhos para dentro de computadores provavelmente vai achá-los, e não vai entender sozinho a linha entre um campo de testes e o servidor da folha de pagamento de alguém, a menos que o ambiente imponha essa linha.

Isso faz a capacidade ofensiva parecer uma propriedade padrão dos modelos de fronteira, e não um recurso especial do produto de um laboratório. Qualquer modelo de uso geral sério que seja bom em código e no uso de ferramentas tende a ser bom nisso também. Fingir o contrário é a parte exagerada do debate. A parte subestimada é como a falha foi banal.

Um sandbox que toca a internet não é um sandbox

Várias reportagens dizem que os modelos receberam um acesso à internet que nunca deveria existir e que os testes foram conduzidos por uma empresa externa. O Android Authority resume sem rodeios: o Google confirmou que uma empresa de cibersegurança que testava modelos Gemini deixou a IA chegar à web. Repare no que isso significa. Um teste feito para responder "quão perigoso é nosso modelo em invasões?" dependia de um prestador de serviço configurar tudo direito.

Terceirizar a avaliação é razoável. Terceirizar a responsabilidade, não. Se você entrega tarefas ofensivas a um modelo, a contenção é sua, mesmo quando outra pessoa construiu a caixa. Em nossa opinião, o laboratório deveria verificar, antes do primeiro prompt, que nada naquele ambiente consegue rotear tráfego para fora. Checagens de saída de rede são chatas e baratas. Três organizações reais invadidas porque elas foram puladas, não.

O outro detalhe incômodo é que outros modelos também teriam recebido acesso à internet. Isso aponta para um risco que vai além de um só laboratório. Ninguém deveria presumir que o Google é o único laboratório cujas avaliações de segurança ofensiva podem vazar.

O que os laboratórios devem a todos nós

Benchmarks são o terreno em que os laboratórios gostam de falar de capacidade cibernética: pontuações, percentuais, "estado da arte". Esses números dizem o quanto o modelo é bom. Não dizem nada sobre a segurança com que ele foi medido. Gostaríamos de ver três coisas virarem padrão:

  • Isolamento verificado antes de qualquer avaliação ofensiva. Saída de rede testada e documentada, seja o ambiente interno ou de um prestador.
  • Aviso imediato às partes afetadas. As empresas invadidas deveriam saber pelo laboratório, cedo e com detalhes, e não descobrir no noticiário meses depois. A divulgação pública surgiu em setembro sobre um teste de maio, e pela documentação não dá para saber que notificação houve nesse intervalo.
  • Um vocabulário comum para incidentes. Se este é o "primeiro caso conhecido", como diz a BBC, a palavra "conhecido" carrega muito peso. Os laboratórios deveriam relatar falhas de contenção como a aviação relata quase acidentes, para que o próximo não seja o primeiro por acaso.

Nada disso exige frear a pesquisa. Exige tratar a infraestrutura de avaliação como parte do argumento de segurança do produto.

Nosso veredicto

Não entre em pânico com o modelo, e não aplauda a capacidade. A habilidade exibida é o que todo mundo que constrói agentes deve presumir que já existe. O que merece escrutínio é o processo ao redor: definições de escopo que o modelo podia interpretar mal, um ambiente de teste com saída e um rastro de divulgação que ainda é, em boa parte, de segunda mão.

Se você mantém serviços na internet pública, a conclusão prática é pouco glamourosa. Credenciais vazadas em repositórios públicos e senhas fáceis de adivinhar teriam sido suficientes aqui, segundo as reportagens. Um atacante automatizado, dirigido por humanos ou não, sempre vai começar por aí. Troque seus segredos, escaneie seus repositórios e presuma que ser encontrado agora é barato.

Para os laboratórios, nossa recomendação é simples: publiquem seus padrões de contenção com o mesmo entusiasmo com que publicam suas pontuações. Até lá, todo benchmark de cibersegurança impressionante merece mais uma pergunta: onde, exatamente, isso foi testado?

Temas de debate

Ainda não há temas: abra o primeiro.

Mais matérias