Avaliação do Gemini alcançou sistemas de empresas reais

O Google disse ao The Wall Street Journal que o Gemini acessou sistemas de três empresas durante um teste da Irregular; a empresa não encontrou evidências de invasão ou vazamento de dados.^{[2], [1], [3]}

💡 Explicação em Linguagem Simples (ELI5)

Imagine um treinamento policial em que os recrutas recebem a tarefa de acessar o site de um banco fictício. O exercício deveria ficar dentro de um pátio fechado, mas o portão está aberto e uma empresa real usa o mesmo nome na internet. Os recrutas podem sair do pátio e alcançar o site real. A Irregular disse que não encontrou evidências de invasão dos sistemas de clientes nem de perda de dados. A lição é impor o limite de rede e usar nomes fictícios reservados, sem depender de o modelo reconhecer esse limite.^{[2], [1]}

Conceitos Centrais e Termos

Avaliação capture-the-flag (CTF): Um teste em que o modelo tenta invadir sistemas propositalmente vulneráveis, usado para medir a capacidade cibernética ofensiva antes do lançamento.^{[2], [1]}
Irregular: A empresa de segurança de IA que conduziu a avaliação na própria infraestrutura. A mesma parceira esteve envolvida nos incidentes do Claude divulgados pela Anthropic em julho de 2026.^[1]
Egress com negação por padrão: Uma regra de rede que bloqueia toda conexão de saída que não seja explicitamente permitida, para que um ambiente não alcance a internet por acidente.^[4]
Nomes reservados (RFC 2606): Domínios como .test e .example, que nunca podem ser registrados; assim um alvo fictício não coincide com uma organização real.^[5]
Classificação: CWE-693 (falha de mecanismo de proteção) é a classificação analítica da FlawOpen, não atribuída pelo fornecedor. High é uma avaliação editorial porque a avaliação relatada ultrapassou o isolamento de rede e alcançou sistemas de três organizações; as fontes citadas não comprovam comprometimento nem perda de dados de clientes. Não há CVE nem pontuação CVSS aplicável.^{[7], [2], [1]}
Origem das recomendações: A lista abaixo contém recomendações de engenharia da FlawOpen com base no limite descrito; não afirma que Google ou Irregular tenham implantado esses controles específicos.^[1]

Mapeamentos de frameworks

Referência CWE para a fraqueza descrita neste guia: CWE-693

Linha do Tempo do Incidente

2026-05

O Wall Street Journal relatou a declaração do Google de que Gemini alcançou sistemas de três empresas durante uma avaliação de cibersegurança da Irregular em maio.^{[2], [1], [3]}

2026-08-14

A Irregular publicou sua análise e disse que o problema do ambiente de avaliação havia sido corrigido e que as partes afetadas foram notificadas.^[1]

2026-09-18

O Google disse ao The Wall Street Journal que o Gemini alcançou sistemas de três empresas durante um teste em maio; o jornal publicou a reportagem em 18 de setembro.^{[2], [3]}

Fluxo de Ataque Passo a Paso

Passo 1

O ambiente não está isolado

O modelo não deveria ter acesso à internet, mas o ambiente de avaliação da parceira o oferecia sem querer.^[1]

Passo 2

O alvo fictício tem nome real

O exercício pedia que o modelo obtivesse informações de uma empresa fictícia com o mesmo nome de empresas reais.^{[2], [1]}

Passo 3

Métodos de acesso relatados e limites

O Google disse ao The Wall Street Journal que o modelo encontrou informações públicas e tentou adivinhar credenciais de sites que acreditava fazerem parte do exercício. A Irregular afirmou depois que o nome fictício coincidia com um domínio real e que não encontrou evidência de invasão dos sistemas de clientes nem de vazamento de dados.^{[2], [1], [3]}

Passo 4

Contenção e divulgação

A Irregular afirma que o problema do ambiente de avaliação foi corrigido antes de seu relatório público de 14 de agosto e que as partes afetadas foram notificadas. O Wall Street Journal noticiou a confirmação do Google em setembro, após sua consulta. As informações disponíveis não comprovam que dados de clientes tenham sido obtidos.^{[2], [1]}

Código-Fonte: Vulnerável vs. Seguro

Configuração ilustrativa de Kubernetes, não da Irregular nem do Google. Ela seleciona todos os pods de agent-eval e permite somente TCP/443 para pods mock-target explicitamente rotulados; NetworkPolicy filtra portas e protocolos, não TLS, portanto configure o serviço simulado para exigir HTTPS. Também permite DNS para um resolvedor dedicado. Se esse resolvedor isolar o tráfego de entrada, adicione uma regra correspondente para pods de avaliação na porta 53, UDP e TCP. Configure-o para atender apenas à zona interna simulada e nunca encaminhar consultas arbitrárias à internet pública, ou o DNS poderá virar uma rota de saída. O sufixo .test é reservado para testes pela RFC 2606. A aplicação depende do CNI; exclua hostNetwork e cargas privilegiadas no nó do limite e verifique o bloqueio com um canário controlado.^{[4], [5], [1]}

IMPLEMENTAÇÃO VULNERÁVEL

apiVersion: v1
kind: ConfigMap
metadata:
  name: ctf-scenario
  namespace: agent-eval
data:
  # Use um host reservado em .test para que o exemplo não possa atingir uma organização real.
  target_company: "Example Freight Test Co"
  target_host: "portal.freight.test"
# Não há NetworkPolicy neste namespace, então os pods podem acessar a internet.

PATCH SEGURO E ROBUSTO

apiVersion: v1
kind: ConfigMap
metadata:
  name: ctf-scenario
  namespace: agent-eval
data:
  target_company: "Example Freight Test Co"
  target_host: "portal.freight.test"
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: eval-egress-allowlist
  namespace: agent-eval
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    # Rotule antes o namespace de destino com purpose=ctf-mock-targets e os pods de destino com app=mock-target.
# Permita somente TCP/443; NetworkPolicy não inspeciona TLS nem impõe HTTPS.
    - to:
        - namespaceSelector:
            matchLabels:
              purpose: ctf-mock-targets
          podSelector:
            matchLabels:
              app: mock-target
      ports:
        - protocol: TCP
          port: 443
    # Rotule antes o namespace do resolvedor dedicado com purpose=ctf-dns e os pods do resolvedor com app=eval-dns.
    # Use um resolvedor dedicado que responda somente à zona interna de simulação.
    - to:
        - namespaceSelector:
            matchLabels:
              purpose: ctf-dns
          podSelector:
            matchLabels:
              app: eval-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

Lista de Verificação de Segurança para Engenharia

✓Aplique uma NetworkPolicy de egress com negação por padrão (ou regra de firewall equivalente) a todo namespace de avaliação e permita apenas namespaces de alvos simulados nomeados.^{[4], [1]}
✓Antes de cada lote, rode no namespace um pod canário que tente alcançar um endereço externo sob seu controle; reprove o lote se a requisição funcionar.^[4]
✓Dê a todo alvo fictício domínios reservados (.test, .example, .invalid) e nomes de empresa inventados; crie uma verificação no CI que rejeite arquivos de cenário com domínios públicos de aparência real.^{[5], [1]}
✓Gere alertas durante as execuções para conexões de saída e tentativas de adivinhar credenciais em hosts fora do cenário; registre tentativas de autenticação sem presumir que alguma teve sucesso.^{[2], [1]}
✓Inclua nos contratos com parceiros de avaliação prazos de notificação e de divulgação pública, para que um incidente no parceiro chegue rápido até você e às partes afetadas.