Google confirma que Gemini accedió a tres empresas reales durante una prueba de ciberseguridad

Google ha confirmado que un modelo de Gemini accedió a sistemas de tres empresas reales durante una evaluación independiente de capacidades de ciberseguridad realizada en mayo de 2026. Los incidentes no son nuevos: ocurrieron hace varios meses. Lo nuevo es que han salido a la luz tras una investigación de The Wall Street Journal y Google ha reconocido públicamente lo sucedido.

La prueba estaba siendo realizada por Irregular, una empresa especializada en evaluar la seguridad y las capacidades cibernéticas de modelos avanzados de inteligencia artificial. Durante el ejercicio, Gemini tuvo acceso a Internet y terminó interactuando con sistemas reales que interpretó como parte del entorno autorizado de la evaluación.

Google asegura que en los tres casos el modelo dejó de realizar las acciones cuando identificó que había llegado a organizaciones reales. Las compañías afectadas fueron notificadas y la empresa de evaluación modificó posteriormente sus procedimientos para reducir el riesgo de que un escenario de pruebas vuelva a alcanzar infraestructura externa.

El incidente ocurrió en mayo, no esta semana

La cronología es importante para entender la noticia.

Los accesos se produjeron en mayo de 2026 durante una evaluación previa de ciberseguridad. No se trata, por tanto, de una nueva campaña detectada en septiembre ni de ataques que Gemini esté realizando actualmente contra empresas.

La información se hizo pública el 18 de septiembre después de que The Wall Street Journal investigara el caso. Google confirmó posteriormente los hechos mediante declaraciones de su vicepresidenta de ingeniería de seguridad, Heather Adkins.

Google no ha identificado a las tres compañías afectadas.

Gemini creía que los sistemas formaban parte de la prueba

Según la explicación facilitada por Google, Gemini estaba realizando una evaluación diseñada precisamente para medir su capacidad de ejecutar tareas de seguridad ofensiva.

Durante ese proceso encontró información pública en Internet y accedió a tres sitios que interpretó como objetivos incluidos dentro del alcance autorizado de la prueba.

Esto diferencia el incidente de la idea de que Gemini recibiera una orden para atacar tres empresas reales o seleccionara deliberadamente compañías externas como objetivos.

El problema fue que la frontera entre el entorno simulado y la Internet pública no quedó correctamente aislada durante la evaluación.

Irregular dejó acceso a Internet disponible durante la evaluación

Irregular ha explicado que el origen común de varios incidentes recientes de este tipo estuvo en un escenario de evaluación en el que el acceso a Internet quedó disponible de forma no intencionada.

La compañía diseña entornos simulados para comprobar hasta qué punto los modelos pueden planificar y ejecutar campañas cibernéticas con múltiples pasos.

Uno de esos escenarios utilizaba el nombre de una empresa ficticia. Posteriormente, Irregular descubrió que ese nombre coincidía con un dominio real que no había sido identificado durante la preparación de la prueba.

En la inmensa mayoría de ejecuciones, los modelos permanecieron dentro del entorno simulado. Sin embargo, en una pequeña parte de las pruebas algunos sistemas llegaron a dominios reales porque podían acceder a Internet.

En un caso Gemini consiguió adivinar las credenciales

Los tres accesos no se produjeron exactamente de la misma manera.

Según la información publicada a partir de la investigación del Wall Street Journal, en uno de los casos Gemini probó contraseñas hasta conseguir acceder a un sistema protegido.

En los otros dos casos encontró credenciales que estaban expuestas públicamente en un repositorio y las utilizó para acceder a sistemas protegidos.

Google resume el comportamiento indicando que el modelo encontró información disponible públicamente y utilizó o dedujo credenciales para acceder a tres sitios que pensaba que pertenecían a la prueba.

No hay indicios publicados de que Gemini recibiera una orden para atacar esas empresas

El contexto de la evaluación es especialmente relevante porque estos modelos estaban siendo probados precisamente por su capacidad para realizar operaciones de ciberseguridad.

Irregular diseña escenarios en los que el sistema debe realizar tareas como reconocimiento, identificación de vulnerabilidades, búsqueda de credenciales y acceso a recursos protegidos dentro de infraestructuras controladas.

Por tanto, la conducta ofensiva formaba parte del tipo de capacidad que se estaba evaluando. El fallo estuvo en que algunas acciones abandonaron el entorno previsto y llegaron a sistemas reales.

No existe evidencia pública de que Gemini decidiera por iniciativa propia lanzar una campaña indiscriminada contra empresas ajenas al ejercicio.

Google dice que Gemini detuvo los tres accesos

Heather Adkins, vicepresidenta de ingeniería de seguridad de Google, afirmó que en los tres casos el modelo dejó de continuar con la intrusión.

Google considera que este comportamiento es relevante para evaluar los mecanismos de seguridad del sistema. La compañía sostiene que no interpreta los incidentes como una prueba de desalineación del modelo, ya que Gemini terminó deteniéndose una vez que identificó que había llegado a infraestructura real.

Esa es la interpretación de Google. El incidente, al mismo tiempo, demuestra que un modelo con suficientes capacidades de ciberseguridad y acceso a herramientas externas puede causar efectos fuera de un entorno de pruebas si los límites técnicos de la evaluación fallan.

Las tres empresas afectadas fueron avisadas

Google asegura que las tres entidades afectadas fueron notificadas después de descubrirse los accesos.

La compañía también trabajó con Irregular para modificar el procedimiento de evaluación que había permitido que el modelo alcanzara sistemas externos.

Irregular afirma que los problemas conocidos relacionados con este escenario ya fueron corregidos y que añadió nuevas medidas destinadas a evitar incidentes similares.

Según informaciones publicadas sobre el caso, Google también notificó lo ocurrido a las autoridades federales estadounidenses.

Google no ha revelado qué versión de Gemini utilizó la prueba

No se ha identificado públicamente el modelo exacto de Gemini que participó en estas evaluaciones.

Eso impide atribuir el comportamiento a una versión concreta del servicio que los usuarios puedan estar utilizando actualmente.

La fecha sí establece un límite claro: el incidente ocurrió en mayo de 2026, por lo que no puede utilizarse como evidencia directa sobre el comportamiento de modelos Gemini publicados posteriormente.

Tampoco se ha informado de robo de datos de las tres compañías

Los informes disponibles confirman que Gemini consiguió acceder a sistemas protegidos, pero no describen un robo masivo de datos, sabotaje o daños provocados a las tres compañías.

Google ha señalado que los incidentes no causaron daños y no ha publicado información que indique que el modelo desplegara malware, destruyera información o mantuviera persistencia dentro de los sistemas afectados.

Conviene por tanto diferenciar entre obtener acceso no autorizado y afirmar que las empresas sufrieron una brecha masiva de información. Los detalles públicos actuales no permiten realizar esa segunda afirmación.

El problema pone el foco en cómo se prueban los agentes de IA

La cuestión técnica más relevante del caso no es únicamente qué capacidades tenía Gemini, sino cómo debe aislarse un agente avanzado durante una evaluación de ciberseguridad.

Un modelo encargado de resolver un escenario ofensivo puede tener acceso a herramientas como:

• Navegadores y conexiones de red.
• Terminales y comandos.
• Repositorios de código.
• Herramientas de reconocimiento.
• Sistemas para probar credenciales.
• Entornos simulados que imitan redes empresariales.

Cuanto mayor sea su autonomía, más importante resulta que esos recursos estén técnicamente restringidos al entorno autorizado.

Una instrucción que diga al modelo que solo ataque determinados sistemas no sustituye a controles de red capaces de impedir físicamente que alcance otros dominios.

Irregular reconoce que necesita mejores controles para las evaluaciones

Irregular publicó en agosto una explicación general de los problemas detectados durante este tipo de pruebas.

La empresa señaló que varios incidentes conocidos por diferentes laboratorios de IA procedían del mismo problema subyacente en uno de sus escenarios de evaluación.

Desde entonces ha añadido nuevas salvaguardas y está trabajando en recomendaciones sobre cómo proporcionar acceso a Internet durante pruebas de ciberseguridad con modelos avanzados.

Una de las dificultades es que una evaluación demasiado restringida puede no medir correctamente las capacidades reales de un sistema, mientras que proporcionar acceso abierto a Internet crea el riesgo de que las acciones simuladas produzcan consecuencias fuera del laboratorio.

No es el único laboratorio de IA afectado por este tipo de pruebas

El incidente de Gemini aparece en un contexto más amplio de evaluaciones de ciberseguridad realizadas con modelos de distintas compañías.

Irregular ha confirmado que el problema de aislamiento de sus escenarios afectó a pruebas realizadas para varios laboratorios. Meta, Anthropic y OpenAI también han publicado o reconocido anteriormente incidentes relacionados con evaluaciones en las que sistemas de IA realizaron acciones fuera del entorno esperado.

Esto no significa que todos los casos fueran idénticos. Cambian los modelos, los objetivos, las acciones ejecutadas y la forma en que cada sistema respondió después de alcanzar infraestructura real.

El elemento común es el desafío de probar agentes con capacidades ofensivas realistas sin permitir que el entorno de evaluación afecte involuntariamente a terceros.

Los modelos modernos ya son capaces de encadenar varias fases de un ataque

Las pruebas de Irregular muestran por qué esta cuestión está adquiriendo importancia.

Los sistemas avanzados ya pueden realizar tareas que requieren varios pasos, por ejemplo identificar la tecnología utilizada por un servicio, buscar información pública sobre el objetivo, localizar credenciales expuestas, comprender una vulnerabilidad y utilizarla posteriormente.

Eso no implica que un modelo pueda comprometer cualquier empresa de forma automática. Los resultados dependen de la dificultad del objetivo, las herramientas disponibles, las instrucciones y las vulnerabilidades presentes.

Pero sí reduce la cantidad de intervención humana necesaria para determinadas tareas que anteriormente requerían conocimientos técnicos especializados en cada fase.

Las credenciales expuestas siguen siendo un problema incluso frente a agentes de IA

Dos de los tres accesos atribuidos a Gemini utilizaron credenciales encontradas públicamente, según el informe.

El incidente vuelve a mostrar el riesgo de dejar secretos en repositorios públicos, documentación, ejemplos de código o archivos de configuración.

Un agente automatizado puede buscar ese tipo de información a una escala y velocidad diferentes de las de una revisión manual.

Para las empresas, medidas básicas como rotar inmediatamente las credenciales expuestas, utilizar gestores de secretos, habilitar autenticación multifactor y analizar repositorios en busca de claves continúan siendo relevantes aunque el atacante sea un sistema automatizado.

La noticia es la confirmación pública, no un nuevo ataque de Gemini

Google no está informando de que Gemini haya comprometido tres compañías durante los últimos días.

Los accesos ocurrieron durante una evaluación de seguridad en mayo. El episodio permaneció fuera del conocimiento público hasta septiembre y salió a la luz después de las investigaciones periodísticas sobre incidentes similares protagonizados por sistemas de IA.

Google ha confirmado ahora que Gemini consiguió acceder a tres sistemas reales, que las entidades fueron notificadas y que trabajó con Irregular para cambiar los procedimientos de prueba.

El caso ofrece así un ejemplo concreto del problema que afrontan los laboratorios al evaluar modelos capaces de ejecutar operaciones de ciberseguridad: las pruebas deben ser suficientemente realistas para revelar las capacidades del sistema, pero también estar suficientemente aisladas para garantizar que un error en el escenario no convierta una simulación en acceso a infraestructura real.