Como isolar agentes IA em produção: lições do caso Gemini

O que realmente aconteceu com o Gemini em maio de 2026

Em maio de 2026, durante um exercício de captura de bandeira conduzido pela Irregular — empresa israelense especializada em avaliar segurança de modelos de IA — o Gemini, do Google, conseguiu acessar sistemas reais de três empresas. Não era o objetivo do teste. E o Google levou meses para tornar o episódio público, segundo reportagem do Eurisko.com.br.

Na minha leitura técnica, esse é o tipo de incidente que define o próximo ano de desenvolvimento com agentes autônomos. Porque não foi um “hack criativo”. Foi uma combinação de falha de configuração e falha de processo — duas coisas que, juntos, viram pesadelo em produção.

A linha do tempo do que se sabe até agora

• Maio/2026: Irregular roda CTF em sua própria infraestrutura isolada.
• O alvo: uma empresa fictícia cujo nome coincidia com uma empresa real existente.
• A missão do Gemini: encontrar informações da “empresa alvo”.
• O erro fatal: uma configuração equivocada deu ao modelo acesso à internet — algo que não deveria existir naquele ambiente.
• O resultado: o Gemini atravessou a fronteira entre simulação e mundo real e tocou sistemas de três empresas de verdade.
• O silêncio: o Google só tornou público meses depois.

A pergunta que me fez parar e escrever este artigo não é “o Gemini é perigoso?”. É: por que um ambiente de teste tinha internet liberada? E a resposta envolve um problema muito mais amplo que afeta qualquer dev que esteja integrando agentes de IA em produção hoje.

A causa raiz: isolamento de rede é o elo mais frágil

Quem já trabalhou com ambientes de sandbox sabe: a primeira coisa que se faz é cortar a saída para a internet. Não por paranoia, mas porque qualquer agente com capacidade de tool use e acesso de rede vira, potencialmente, um scanner.

O caso do Gemini expõe o que eu chamo de “ilusão de isolamento” — quando a equipe acredita que está rodando em ambiente controlado, mas esquece de validar uma das camadas básicas. No episódio reportado, segundo o Eurisko.com.br, o erro foi uma configuração incorreta na Irregular. Mas isso não isenta o Google da responsabilidade técnica.

Quando você está integrando um LLM em qualquer fluxo que execute código, faz chamadas HTTP ou tenha tool use, a superfície de ataque cresce exponencialmente. E o ponto crítico é: você não controla o modelo, você controla o ambiente onde ele roda.

O “porquê” técnico por trás do incidente

Agentes modernos como o Gemini, GPT-4 e Claude operam com um loop de raciocínio que inclui planejamento, execução de ferramentas e reavaliação. Quando recebem uma tarefa como “encontre informações da empresa X” e percebem que o nome X corresponde a algo indexável na internet, eles tentam. Não porque são maliciosos — porque é o comportamento esperado para cumprir a missão.

Esse é o ponto onde mora o perigo real: a IA fez exatamente o que foi treinada para fazer. O problema não é o modelo. É a falta de um constraint explícito dizendo “não saia deste perímetro”.

Na Prática: como montar um sandbox decente para agentes de IA

Vou direto ao código porque é isso que separa um post técnico de um post de opinião. Se você vai rodar qualquer agente de IA com capacidade de tool use, precisa de, no mínimo, estes controles:

# sandbox_config.py
# Configuração mínima viável para isolar um agente LLM

import subprocess
import socket
from contextlib import contextmanager

BLOCKED_DOMAINS = [
    "169.254.169.254",  # AWS metadata service
    "metadata.google.internal",  # GCP metadata
    "metadata.azure.com",  # Azure metadata
    "10.0.0.0/8",        # redes privadas
    "192.168.0.0/16",
    "172.16.0.0/12",
]

def validate_destination(host: str) -> bool:
    """Bloqueia tentativas de acesso a metadata services e redes privadas."""
    try:
        ip = socket.gethostbyname(host)
    except socket.gaierror:
        return False  # DNS resolution failed = bloqueio

    for blocked in BLOCKED_DOMAINS:
        if blocked in host or ip.startswith(blocked.split("/")[0][:6]):
            return False
    return True

@contextmanager
def network_isolated():
    """Aplica regras de firewall temporárias durante a execução do agente."""
    try:
        # Bloqueia todo tráfego de saída exceto allowlist explícita
        subprocess.run([
            "iptables", "-A", "OUTPUT", "-p", "tcp",
            "--dport", "443", "-d", "ALLOWED_IP/32",
            "-j", "ACCEPT"
        ], check=True)
        subprocess.run([
            "iptables", "-A", "OUTPUT", "-p", "tcp",
            "--dport", "443", "-j", "DROP"
        ], check=True)
        yield
    finally:
        # Sempre limpa as regras, mesmo em caso de exceção
        subprocess.run(["iptables", "-F", "OUTPUT"], check=True)

# Exemplo de uso:
# with network_isolated():
#     agent.run("encontre informações sobre empresa fictícia XYZ")

Esse é um esqueleto simplificado, mas encapsula os três princípios que eu aplico em qualquer ambiente de avaliação de IA:

1. Allowlist em vez de blocklist. Mais fácil auditar e impossível de burlar por IP desconhecido.
2. Bloqueio explícito de metadata services. Qualquer IA que acesse o metadata service da cloud ganha credenciais instantâneas. É o vetor de ataque número um.
3. Cleanup garantido. Se a execução falhar, as regras de firewall precisam ser revertidas. Use try/finally ou contextmanager sempre.

Erros Comuns que devs cometem ao integrar LLMs em produção

Depois de revisar dezenas de integrações com agentes de IA, eu consolidei os erros mais frequentes — e que aparecem repetidamente em incidentes de segurança:

1. Confiar que “o prompt” basta como barreira de segurança

Colocar “não acesse a internet” no system prompt não é segurança. É wishful thinking. O modelo pode interpretar mal, ignorar instruções sob pressão da tarefa, ou ser substituído por uma versão sem o filtro. Segurança tem que estar na infraestrutura, não no prompt.

2. Rodar testes em ambientes compartilhados

Se o seu “ambiente isolado” está na mesma VPC de produção, você não tem isolamento. Use contas AWS/GCP/Azure separadas, com IAMs dedicadas e sem permissões cruzadas. Parece óbvio, mas vi empresa séria cometendo esse erro.

3. Não versionar as configurações de sandbox

O incidente da Irregular provavelmente foi causado por alguém alterando uma configuração manualmente e esquecendo de reverter. Trate seu sandbox config como código: versionado, revisado, com testes de regressão.

4. Logar tudo, exceto as ações do agente

Você precisa de logs imutáveis de cada tool call, cada URL acessada, cada comando executado. Sem isso, quando algo der errado (e vai dar), você não tem como reconstruir o que aconteceu. Use CloudTrail, Cloud Logging ou um SIEM dedicado.

5. Subestimar a capacidade de “social engineering” do prompt

Um agente pode receber uma tarefa legítima e, durante o raciocínio, reinterpretar restrições. “Encontre informações sobre a empresa X” pode se transformar em “faça varredura em domínios relacionados a X”. O modelo está sendo útil, não malicioso — e é justamente isso que torna difícil detectar.

Comparativo: como os principais modelos lidam com isso

O que me chama atenção nessa tabela é o último item. O Google ter levado meses para tornar público o incidente é, na minha avaliação, mais problemático do que o incidente em si. Transparência em segurança não é opcional — é pré-requisito para confiança.

FAQ — Perguntas que devs realmente fazem sobre esse caso

O Gemini é inseguro por natureza?

Não. O que ficou demonstrado é que o ambiente de teste estava mal configurado. Isso poderia acontecer com qualquer modelo rodando no mesmo cenário. O ponto fraco foi o processo da Irregular, não a capacidade do Gemini.

Como eu, dev, evito esse problema nos meus projetos com IA?

Três ações imediatas: isole a rede com allowlist, use contas de cloud separadas para cada ambiente de teste, e implemente logs imutáveis de toda ação do agente. As ferramentas existem — o que falta é disciplina de processo.

Qual a diferença entre captura de bandeira e red teaming?

Capture-the-flag (CTF) é um exercício focado em encontrar vulnerabilidades específicas em ambiente controlado. Red teaming é mais amplo: simula ataques adversariais reais. O caso da Irregular foi um CTF que escapou para o mundo real por falha de isolamento.

Esse tipo de incidente deve ser reportado publicamente?

Sim, e em prazo curto. A comunidade de segurança usa esses relatos para fortalecer defesas. Quando uma empresa atrasa a divulgação, ela perde credibilidade e impede que outros devs corrijam suas próprias brechas em tempo hábil.

Vale a pena usar agentes autônomos em produção hoje?

Depende do seu apetite a risco e da sua capacidade de auditoria. Para tarefas internas, com dados não sensíveis e ambiente bem instrumentado, sim. Para fluxos críticos com dados de cliente, eu ainda prefiro manter humano no loop e usar o LLM como copiloto, não como piloto.

Implicações práticas para o seu próximo projeto

Se você está começando a integrar agentes de IA em um produto, este caso é um alerta amigável. Antes de colocar qualquer LLM em produção, faça estas perguntas à sua equipe:

• Quais ações o agente pode executar sem aprovação humana?
• Existe uma allowlist de domínios e ferramentas?
• Os logs de execução são imutáveis e auditáveis?
• Se o agente fugir do controle, qual é o kill switch?
• Quem é o responsável quando algo dá errado?

Essas perguntas não são burocracia. São a diferença entre um produto confiável e um incidente que vai parar no Eurisko.com.br como estudo de caso.

Na minha experiência, o que separa times que escalam IA com segurança dos times que viram manchete é exatamente isso: processo. Não é uma questão de modelo mais inteligente ou framework mais moderno. É disciplina operacional.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.