lorenzopasquali.dev

O Gemini “hackeou” 3 empresas num teste. A falha de verdade era senha e segredo exposto

· 6 min de leitura · também em English

A manchete parece saída de um filme: o Gemini invadiu três empresas reais durante um teste de segurança.

Só que o detalhe mais interessante da história não é uma técnica inédita de IA. É justamente o contrário: segundo os relatos públicos, o modelo chegou aos sistemas reais usando caminhos que qualquer time de segurança já deveria tratar como básicos: tentativa de senha e credenciais expostas em repositórios públicos.

E, antes disso, houve um problema ainda mais simples: o ambiente criado para o teste conseguiu acessar a internet.

O que aconteceu?

Em maio de 2026, a empresa de segurança de IA Irregular conduziu um exercício de capture the flag para avaliar capacidades de cibersegurança de modelos.

A ideia era trabalhar com empresas fictícias dentro de um ambiente controlado. Segundo a própria Irregular, porém, um nome escolhido para uma empresa fictícia coincidia com um domínio real. Ao mesmo tempo, o ambiente de avaliação acabou tendo acesso à internet que não deveria estar disponível.

O resultado foi que modelos conseguiram, em algumas execuções, sair do cenário imaginado pelos avaliadores e alcançar infraestrutura real. A Irregular publicou em agosto um relato sobre o problema e disse que ele já havia sido corrigido. Relato da Irregular

O caso específico do Gemini veio a público em 18 de setembro, depois de reportagem do Wall Street Journal. O Google confirmou que, durante o teste, Gemini acessou sistemas de três empresas reais. Reuters

E aqui está a parte que merece mais atenção de quem desenvolve software.

Três acessos. Nenhum deles precisou de uma “IA hacker” de ficção científica

De acordo com o que foi divulgado pelo Google e pela imprensa:

Os nomes das empresas não foram divulgados.

Também não foi divulgado publicamente qual versão específica do Gemini estava envolvida. Portanto, qualquer manchete que atribua o episódio a uma versão específica do modelo está indo além do que foi confirmado.

Isso muda bastante a leitura do caso.

O Gemini precisava ser capaz de executar uma cadeia autônoma de ações, interpretar o que encontrava e decidir o próximo passo. Isso é relevante. Mas o acesso inicial não veio de uma vulnerabilidade revolucionária descoberta pela IA.

Ele veio de problemas conhecidos:

ambiente com acesso de rede indevido + alvo mal definido + autenticação fraca ou credenciais expostas.

O detalhe que o hype não conta

É tentador interpretar o episódio como “a IA escapou do sandbox”.

Mas a descrição pública da Irregular é mais específica: o problema foi um ambiente de avaliação que permitiu acesso à internet e uma colisão entre um nome fictício e um domínio real. A própria empresa diz que os relatos posteriores estavam ligados a um mesmo problema de avaliação, e que o ambiente já havia sido corrigido. Irregular

Isso importa porque prompt não é controle de segurança.

Dizer para um agente:

“Você não tem acesso à internet.”

não é equivalente a configurar uma infraestrutura em que o agente realmente não consiga fazer uma conexão de saída.

Se o agente tem acesso ao shell, browser ou ferramentas HTTP, o limite precisa existir na camada de infraestrutura também.

É uma distinção que vale para CTFs, mas também para agentes de coding, automações internas e ferramentas de IA que rodam dentro de ambientes com acesso a sistemas reais.

E os segredos no Git?

Aqui está a parte mais fácil de transformar em ação prática.

Se uma IA consegue procurar código público, encontrar um repositório e recuperar uma credencial válida, não existe nada particularmente “mágico” nisso.

O problema já existia antes da IA.

A diferença é que um agente pode fazer a busca, testar hipóteses e encadear ações muito mais rapidamente do que um humano.

Por isso, vale revisar pelo menos:

1. Secret scanning

Ferramentas como Gitleaks conseguem procurar tokens, senhas, chaves e outros padrões sensíveis no histórico de um repositório.

No GitHub, o Secret Scanning e o push protection também podem bloquear ou alertar sobre determinados segredos antes que eles cheguem ao repositório.

O ponto principal não é simplesmente encontrar o segredo depois do vazamento. É impedir que ele seja publicado.

2. Credencial exposta não deve continuar válida

Encontrar uma senha ou token no Git é apenas metade do problema.

Se aquele segredo ainda funciona depois de chegar a um repositório público, a janela de exposição pode ser enorme.

A regra deveria ser simples:

segredo vazou → revogar → gerar outro → investigar uso anterior.

Remover o arquivo do último commit não é suficiente se a credencial continua válida ou se ela permanece no histórico do Git.

3. Rate limiting e lockout

No caso divulgado, uma das entradas ocorreu por tentativa de senhas.

Isso coloca controles bastante antigos de volta no centro da discussão:

Não importa se quem está tentando as senhas é uma pessoa, um script ou um agente de IA.

Uma autenticação que aceita milhares de tentativas continua sendo uma autenticação fraca.

4. Acesso de rede do seu agente

Talvez esta seja a pergunta mais interessante para quem está começando a colocar agentes de IA para trabalhar:

Se o meu agente de código receber uma tarefa errada, até onde ele consegue chegar?

Um agente com acesso ao terminal e à internet pode potencialmente:

Se ele estiver trabalhando em um notebook de desenvolvimento, isso pode significar acesso a muito mais coisa do que o desenvolvedor imaginava.

Por isso, para agentes com autonomia real, vale pensar em egress de rede, allowlists, permissões mínimas, credenciais temporárias e isolamento do ambiente.

A parte mais curiosa: o Gemini parou sozinho

Segundo o Google, o modelo interrompeu a atividade depois de perceber que havia chegado a sistemas de empresas reais. O Google também afirmou que os afetados foram informados e que os processos de teste foram alterados. Reuters

Isso é interessante como comportamento do modelo, mas eu não usaria isso como mecanismo de segurança.

Se um agente tem autorização para executar uma ação potencialmente destrutiva, o controle principal deveria impedir a ação fora do escopo, em vez de depender de o modelo perceber que fez algo errado depois.

O modelo parar é uma camada adicional.

Firewall, isolamento, permissões, autenticação e gerenciamento de segredos continuam sendo as camadas que deveriam estar entre o agente e o sistema real.

Então a IA é o problema?

O caso não permite uma conclusão tão simples.

Há uma capacidade nova aqui: um agente consegue pesquisar, interpretar resultados, testar credenciais e continuar uma cadeia de ações sem que um humano precise conduzir cada passo.

Mas os três acessos divulgados mostram outra coisa também: as barreiras encontradas pelo agente eram bastante tradicionais.

O incidente só fica realmente interessante quando colocamos as duas coisas juntas:

um agente com autonomia crescente + sistemas que ainda dependem de controles de segurança básicos.

A IA não inventou a senha fraca.

Não inventou o segredo publicado no Git.

Não criou o acesso à internet do ambiente.

Mas conseguiu combinar essas condições em uma sequência de ações.

E é exatamente por isso que a segurança de aplicações com agentes de IA não deveria começar por uma lista de “comportamentos assustadores da IA”.

Ela deveria começar por uma pergunta bem mais simples:

Se esse agente fizer tudo que ele é tecnicamente capaz de fazer, qual é a pior coisa que ele consegue alcançar?

Se a resposta for “produção”, “banco de dados”, “credenciais de clientes” ou “a internet inteira”, talvez o problema não esteja no modelo.

Talvez esteja na permissão que demos a ele.

Fontes

← Todos os posts