Gemini accedió a sistemas reales durante una evaluación

Google dijo a The Wall Street Journal que Gemini accedió a sistemas de tres empresas durante una prueba de Irregular; esta no encontró pruebas de intrusión ni pérdida de datos.^{[2], [1], [3]}

💡 Explicación en Lenguaje Sencillo (ELI5)

Imagina un ejercicio policial en el que los reclutas deben acceder al sitio web de un banco ficticio. El ejercicio debería limitarse a un patio cerrado, pero la verja está abierta y una empresa real usa el mismo nombre en internet. Los reclutas pueden salir del patio y llegar al sitio real. Irregular dijo que no encontró pruebas de intrusión en sistemas de clientes ni de pérdida de datos. La lección es imponer el límite de red y usar nombres ficticios reservados, sin confiar en que el modelo reconozca ese límite.^{[2], [1]}

Conceptos Clave y Términos

Evaluación capture-the-flag (CTF): Una prueba en la que un modelo intenta entrar en sistemas deliberadamente vulnerables, usada para medir su capacidad ofensiva antes del lanzamiento.^{[2], [1]}
Irregular: La empresa de seguridad de IA que realizó la evaluación en su propia infraestructura. El mismo socio estuvo implicado en los incidentes de Claude que Anthropic reveló en julio de 2026.^[1]
Salida denegada por defecto: Una regla de red que bloquea toda conexión saliente salvo las permitidas expresamente, para que un entorno no llegue a internet por accidente.^[4]
Nombres reservados (RFC 2606): Dominios como .test y .example, que nunca pueden registrarse, de modo que un objetivo ficticio no puede coincidir con una organización real.^[5]
Clasificación: CWE-693 (fallo de un mecanismo de protección) es la clasificación analítica de FlawOpen, no asignada por el proveedor. High es una valoración editorial porque la evaluación descrita superó el aislamiento de red y alcanzó sistemas de tres organizaciones; las fuentes citadas no demuestran compromiso ni pérdida de datos de clientes. No se aplica ningún CVE ni puntuación CVSS.^{[7], [2], [1]}
Origen de las recomendaciones: La lista siguiente contiene recomendaciones de ingeniería de FlawOpen basadas en el límite descrito; no afirma que Google o Irregular implantaran esos controles concretos.^[1]

Mapeos de marcos

Referencia CWE para la debilidad descrita en esta guía: CWE-693

Cronología del Incidente

2026-05

The Wall Street Journal informó de la declaración de Google según la cual Gemini accedió a sistemas de tres empresas durante una evaluación de ciberseguridad de Irregular en mayo.^{[2], [1], [3]}

2026-08-14

Irregular publicó su análisis y dijo que el problema del entorno de evaluación se había corregido y que se había avisado a las partes afectadas.^[1]

2026-09-18

Google dijo a The Wall Street Journal que Gemini llegó a sistemas de tres empresas durante una prueba en mayo; el diario publicó su reportaje el 18 de septiembre.^{[2], [3]}

Flujo de Ataque Paso a Paso

Paso 1

El entorno no está aislado

El modelo no debía tener acceso a internet, pero el entorno de evaluación del socio se lo daba sin querer.^[1]

Paso 2

El objetivo ficticio tiene nombre real

El ejercicio pedía al modelo obtener información de una empresa ficticia que se llamaba igual que empresas reales.^{[2], [1]}

Paso 3

Métodos de acceso reportados y límites

Google dijo a The Wall Street Journal que el modelo encontró información pública e intentó adivinar credenciales de sitios que creía parte del ejercicio. Irregular indicó después que el nombre ficticio coincidía con un dominio real y que no encontró pruebas de intrusión en sistemas de clientes ni de filtración de datos.^{[2], [1], [3]}

Paso 4

Contención y divulgación

Irregular afirma que el problema del entorno de evaluación se había corregido antes de su informe público del 14 de agosto y que se notificó a las partes afectadas. The Wall Street Journal informó de la confirmación de Google en septiembre tras consultarle. La información disponible no demuestra que se obtuvieran datos de clientes.^{[2], [1]}

Código Fuente: Vulnerable vs. Seguro

Configuración ilustrativa de Kubernetes, no de Irregular ni de Google. Selecciona todos los pods de agent-eval y solo permite TCP/443 hacia pods mock-target etiquetados expresamente; NetworkPolicy filtra puertos y protocolos, no TLS, así que configura el servicio simulado para exigir HTTPS. También permite DNS hacia un resolvedor dedicado. Si el resolvedor está aislado de entrada, añade una regla de entrada correspondiente para los pods de evaluación en el puerto 53, UDP y TCP. Configúralo para servir solo la zona simulada interna y no reenviar consultas arbitrarias a Internet, pues DNS podría convertirse en una vía de salida. El sufijo .test está reservado para pruebas según RFC 2606. La aplicación depende del CNI; excluye hostNetwork y las cargas privilegiadas del nodo del límite y verifica el bloqueo con un canario controlado.^{[4], [5], [1]}

IMPLEMENTACIÓN VULNERABLE

apiVersion: v1
kind: ConfigMap
metadata:
  name: ctf-scenario
  namespace: agent-eval
data:
  # Use un nombre reservado .test para que el ejemplo no pueda alcanzar una organización real.
  target_company: "Example Freight Test Co"
  target_host: "portal.freight.test"
# No existe NetworkPolicy en este espacio de nombres, así que los pods pueden acceder a Internet.

PARCHE SEGURO Y 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:
    # Etiquete antes el espacio de nombres de destino con purpose=ctf-mock-targets y los pods de destino con app=mock-target.
# Permite solo TCP/443; NetworkPolicy no inspecciona TLS ni impone HTTPS.
    - to:
        - namespaceSelector:
            matchLabels:
              purpose: ctf-mock-targets
          podSelector:
            matchLabels:
              app: mock-target
      ports:
        - protocol: TCP
          port: 443
    # Etiquete antes el espacio de nombres del resolvedor dedicado con purpose=ctf-dns y sus pods con app=eval-dns.
    # Use un resolvedor dedicado que responda únicamente a la zona simulada interna.
    - to:
        - namespaceSelector:
            matchLabels:
              purpose: ctf-dns
          podSelector:
            matchLabels:
              app: eval-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

Lista de Verificación de Seguridad para Ingeniería

✓Aplica una NetworkPolicy de salida denegada por defecto (o una regla de cortafuegos equivalente) a cada namespace de evaluación y permite solo namespaces de objetivos simulados concretos.^{[4], [1]}
✓Antes de cada lote, lanza en el namespace un pod canario que intente llegar a una dirección externa que controles; da el lote por fallido si la petición prospera.^[4]
✓Usa dominios reservados (.test, .example, .invalid) y nombres de empresa inventados para todos los objetivos ficticios; añade una comprobación de CI que rechace ficheros de escenario con dominios públicos de aspecto real.^{[5], [1]}
✓Genera alertas durante las ejecuciones por conexiones salientes e intentos de adivinar credenciales en hosts ajenos al escenario; registra los intentos de autenticación sin presuponer que alguno tuvo éxito.^{[2], [1]}
✓Incluye en los contratos con socios de evaluación plazos de notificación y de divulgación pública, para que un incidente en el socio te llegue rápido a ti y a los afectados.