Vertex AI «Double Agents»: service agents con privilegios excesivos como vía de escalada en la nube

¿Qué es esto?

El 31 de marzo de 2026, Unit 42 (Palo Alto Networks) divulgó un punto ciego de seguridad en Google Cloud Vertex AI: un agente de IA mal configurado o comprometido puede convertirse en lo que el investigador Ofir Shaty llama un «doble agente» — un agente que aparenta cumplir su función mientras exfiltra datos de forma silenciosa, alcanza recursos internos y pivota a través de un proyecto en la nube. Aquí no hay ningún exploit novedoso contra el modelo. El problema es de identidad y de alcance de permisos: la identidad de servicio aprovisionada para un agente desplegado posee muchos más derechos de los que la tarea del agente necesita, y esos derechos son accesibles desde el propio contexto de ejecución del agente.

Esto importa porque es una clase de fallo, no un único bug. El mismo patrón — un service agent de IA que hereda credenciales a nivel de plataforma sin un alcance de mínimo privilegio — se repite allí donde los agentes se despliegan como cargas de trabajo en la nube de pleno derecho. Google ha actualizado desde entonces su documentación y ha cambiado sus recomendaciones (ver Estado), por lo que esto puede discutirse abiertamente.

Cómo funciona

Cuando construyes un agente con el Agent Development Kit (ADK) de Vertex AI y lo despliegas mediante Agent Engine, Google le aprovisiona un Per-Project, Per-Product Service Agent (P4SA). Unit 42 comprobó que este P4SA tenía permisos excesivos por defecto y — sobre todo — que esas credenciales son accesibles desde el agente en ejecución:

• El servicio de metadatos entrega la credencial. Tras el despliegue, cualquier llamada al agente dispara una petición al servicio de metadatos interno de Google, que expone las credenciales del service agent junto con el proyecto GCP anfitrión, la identidad del agente y los scopes de la máquina. Es el mismo patrón nativo de la nube del robo de credenciales vía IMDS — ver Toma de control en la nube vía IMDS — aplicado ahora a un runtime de agente.
• La credencial escapa de su sandbox. Con la credencial obtenida, los investigadores pivotaron del contexto de ejecución del agente al proyecto del cliente, rompiendo la garantía de aislamiento y obteniendo acceso de lectura sin restricciones a todos los buckets de Google Cloud Storage de ese proyecto.
• También alcanzó el tenant de Google. Como Agent Engine se ejecuta dentro de un proyecto tenant gestionado por Google, la misma credencial reveló detalles de la infraestructura interna de la plataforma y — más llamativo — concedió acceso de lectura a repositorios restringidos de Artifact Registry, incluidas imágenes de contenedor que componen el Reasoning Engine de Vertex AI. Unit 42 señala que esto expone código propietario y da al atacante un mapa de la cadena de suministro de software interna.

La condición de disparo es un agente que procesa entradas no confiables o ejecuta código influido por el atacante — por ejemplo vía inyección de prompt indirecta o una carga serializada maliciosa. El daño proviene de la credencial permanente y demasiado amplia, a una llamada de metadatos de distancia.

Por qué importa

Los agentes se despliegan cada vez más como cargas de trabajo ordinarias en la nube, y heredan la debilidad más antigua de la nube: identidades de servicio demasiado amplias por defecto. La lección de Unit 42 es contundente: conceder permisos amplios a los agentes por defecto viola el mínimo privilegio y constituye «un fallo de seguridad peligroso, por diseño».

Es el radio de impacto lo que hace de esto un asunto serio y no una curiosidad. Una sola credencial de «lectura total» convierte a un agente útil en una amenaza interna: exfiltración desde cualquier bucket, reconocimiento de la infraestructura interna, acceso a imágenes privadas que pueden sembrar el siguiente ataque. El límite honesto sobre la gravedad es que la explotación todavía requiere que el agente esté primero mal configurado o comprometido — no es una toma de control remota y no autenticada. Pero en los despliegues de agentes, «comprometido por una entrada inyectada» no es un escenario remoto: es el escenario esperado. Es exactamente el acoplamiento descrito por el trifecta letal: acceso a datos privados, entrada no confiable y vía de exfiltración.

Defensas

Las mitigaciones pertenecen a la tradición del IAM en la nube y de la higiene de despliegue, y se generalizan más allá de Vertex AI:

• Reemplaza el service agent por defecto. La corrección recomendada por Google es Bring Your Own Service Account (BYOSA), en lugar del P4SA por defecto, acotada al principio de mínimo privilegio para que el agente solo posea los permisos que su tarea requiere. Si tu plataforma aprovisiona una identidad por defecto, trátala como no confiable hasta haberla acotado.
• Restringe los scopes de OAuth al mínimo privilegio. La indicación de Shaty es explícita: valida los límites de permisos y reduce los scopes de OAuth al mínimo. Un permiso permanente de «lectura de todos los buckets» es la precondición de la que depende toda la cadena.
• Trata el despliegue de un agente como código de producción. Revisa la integridad del código fuente, valida los límites y realiza pruebas de seguridad controladas antes del despliegue — no una vez que el agente está en producción y es accesible.
• Blinda la ruta de metadatos. Donde la plataforma lo permita, limita qué cargas de trabajo pueden alcanzar el servicio de metadatos y qué devuelve; la credencial que nunca llega al runtime del agente no puede robarse desde él.
• Segmenta el proyecto. No dejes que el radio de impacto de un agente sea «el proyecto entero». Usa proyectos separados, VPC Service Controls e IAM por recurso para que una credencial filtrada lea un bucket, no todos.
• Monitoriza las llamadas a las API de la nube iniciadas por el agente. Una enumeración repentina de buckets o pulls de registro desde una identidad de agente son una señal fuerte de que la credencial se ha vuelto en tu contra.

Estado

Elemento	Detalle
Divulgado por	Palo Alto Networks Unit 42 (investigador Ofir Shaty)
Fecha	31 de marzo de 2026
Superficie afectada	Vertex AI Agent Engine + ADK; Per-Project, Per-Product Service Agent (P4SA) por defecto
Mecanismo	El servicio de metadatos expone al runtime del agente una credencial de servicio demasiado amplia
Impacto	Lectura de todos los buckets de GCS del proyecto del cliente; acceso a detalles de infraestructura del tenant y a imágenes restringidas de Artifact Registry
Respuesta del proveedor	Google actualizó su documentación de control de acceso; recomienda BYOSA + mínimo privilegio
Naturaleza	Fallo de alcance de permisos / de identidad, no un exploit novedoso contra el modelo

Este es un análisis defensivo, a nivel de diseño: sin payloads de explotación, sin cadena de ataque accionable. La enseñanza duradera precede con mucho a los LLM y ahora se les aplica: un agente vale, en seguridad, lo que vale la identidad bajo la que se ejecuta — y una credencial por defecto capaz de leerlo todo es una brecha que solo espera un disparador.