Los investigadores de seguridad dicen que Vertex AI Agent Engine de Google Cloud expuso un grave riesgo de privilegios a través de su modelo de agente de servicio predeterminado, lo que permite que un agente de IA implementado extraiga credenciales de agente de servicio y acceda a recursos confidenciales.La Unidad 42 de Palo Alto Networks dijoEl problema permitió que un agente malintencionado o comprometido fuera más allá de su tarea prevista y leyera datos en el proyecto de Google Cloud del cliente.
Los investigadores describieron el problema como una debilidad del permiso predeterminado, no como un simple error en el manejo rápido. En su prueba, un agente implementado creado conKit de desarrollo de agentes de Googlepodría consultar el servicio de metadatos, extraer las credenciales del agente de servicio Vertex AI Reasoning Engine y luego usar esa identidad para acceder a los datos de almacenamiento dentro del proyecto del consumidor.
Google no enmarcó esto como un evento de explotación masiva activa en los materiales que encontré. En cambio, el registro público muestra un problema de seguridad revelado por un investigador que llevó a Google a actualizar la documentación y presionar a los clientes hacia controles de identidad más estrictos, como la identidad de los agentes y una gestión más explícita de las cuentas de servicio.
Lo que encontraron los investigadores
Unidad 42 dijo el Por-Proyecto, Agente de servicio por producto, o P4SA, vinculado a un agente Vertex AI implementado tenía permisos excesivos de forma predeterminada. Extrajeron las credenciales paraservice-<PROJECT-ID>@gcp-sa-aiplatform-re.iam.gserviceaccount.com, que Google documenta como Agente de servicio de Vertex AI Reasoning Engine.
Con esas credenciales, los investigadores dijeron que podrían entrar en elpropio proyecto de Google Cloud del clientey obtenga acceso de lectura a los depósitos de Google Cloud Storage. La Unidad 42 enumera específicamente permisos comostorage.buckets.get,storage.buckets.list,storage.objects.get, ystorage.objects.listcomo parte del acceso excesivo que observaron.
También dijeron que las mismas credenciales exponían el acceso a repositorios restringidos de Artifact Registry propiedad de Google vinculados al Vertex AI Reasoning Engine.Según el informe, ese acceso les permitió ver y descargar imágenes de contenedores internos asociados con el servicio, que, según ellos, podrían revelar código propietario y ayudar a mapear la cadena de suministro de software interna de Google.
Por qué el tema importa
Esto es importante porque los agentes de IA ahora actúan como trabajadores semiautónomos dentro de entornos empresariales. Si la identidad adjunta a ese agente conlleva más acceso del que debería, una herramienta maliciosa, un agente manipulado rápidamente o una implementación comprometida pueden convertirse en un punto de pivote interno. Ése es el escenario central del “agente doble” que describe la Unidad 42.
Los investigadores también descubrieron que las credenciales extraídas otorgaban acceso a un proyecto de inquilino administrado por Google utilizado para la instancia del agente. En ese entorno, descubrieron archivos comoDockerfile.zip,code.pkl, yrequirements.txt, junto con referencias a depósitos internos de Google Cloud Storage. Dijeron que no podían acceder directamente al menos a un depósito interno restringido, pero las referencias de infraestructura aún exponían detalles operativos.
Algunos de los escenarios posteriores más aterradores del artículo de muestra necesitan una redacción más estricta. La Unidad 42 analizó un archivo pickle de Python y señaló que históricamente pickle no es seguro cuando se deserializan datos que no son de confianza, pero el informe no afirma que haya una puerta trasera de producción demostrada a través de ese archivo en el entorno de Google. Esa parte debería quedar enmarcada como una señal de riesgo, no como una vía de explotación confirmada.
Lo que Google cambió
La Unidad 42 dice que Google colaborócon los investigadores después de la divulgación y revisó su documentación para explicar cómo Vertex AI utiliza recursos, cuentas y agentes. La página de investigación también dice que Google cambió el flujo de trabajo de implementación de ADK después del descubrimiento y señaló que es posible que el ejemplo de código original utilizado en la investigación ya no funcione en la versión actual.
La documentación actual de Vertex AI Agent Engine de Google ahora empuja a los clientes hacia controles de identidad más estrictos. La guía de configuración recomienda utilizar la identidad del agente para la gestión del acceso, y Google dice que la identidad del agente permite a las organizaciones otorgar o denegar el acceso a las API y recursos propios de Google Cloud por agente.
Google también documenta que los agentes implementados pueden usar la identidad del agente o cuentas de servicio, y dice que esas identidades determinan a qué datos y recursos puede acceder el agente. Ésa es la solución práctica en este caso: dejar de depender de permisos predeterminados amplios y pasar a un diseño de identidad explícito con privilegios mínimos.
Puntos clave
- La Unidad 42 dijo que un agente de Vertex AI implementado podría extraer las credenciales del agente de servicio Vertex AI Reasoning Engine.
- Los investigadores dijeron que esas credenciales permitían el acceso de lectura a los datos en los depósitos de Google Cloud Storage de los clientes.
- También informaron acceso a repositorios restringidos de Artifact Registry propiedad de Google vinculados a imágenes de Vertex AI Reasoning Engine.
- Google actualizó la documentación y cambió el flujo de trabajo de implementación de ADK después de la divulgación.
- Google ahora recomienda un control de identidad más estricto a través de la identidad de los agentes y la gestión explícita de cuentas de servicio.
Tabla resumen de riesgos
| Área | Lo que informaron los investigadores | Por qué es importante |
|---|---|---|
| Identidad del agente de servicio | Las credenciales del agente de servicio de Vertex AI Reasoning Engine se pueden extraer del entorno implementado | Las credenciales robadas pueden permitir que un agente actúe fuera de su función prevista. |
| Datos del proyecto del cliente. | Acceso al depósito de Cloud Storage y a los permisos de objetos en el proyecto del consumidor | Los datos confidenciales de los clientes podrían volverse legibles para un agente malintencionado. |
| Infraestructura administrada por Google | Acceso a imágenes restringidas de Artifact Registry y archivos de implementación de proyectos de inquilinos | La visibilidad de la infraestructura interna puede ayudar a realizar investigaciones más profundas y ataques posteriores. |
| Diseño de identidad | Valores predeterminados demasiado amplios en lugar de privilegios mínimos | Los agentes de IA se convierten en identidades internas de alto riesgo si los permisos son demasiado amplios. |
| Mitigación | Identidad del agente y controles más estrictos de las cuentas de servicio | Limita lo que un agente implementado puede alcanzar si se abusa de él. |
¿Qué deberían hacer las organizaciones ahora?
- Revise cada implementación de Vertex AI Agent Engine e identifique qué identidad de servicio utiliza.
- Reemplace el acceso predeterminado amplio con una identidad de agente con privilegios mínimos o cuentas de servicio con un alcance limitado.
- Audite el almacenamiento en la nube, el registro de artefactos y los enlaces de IAM relacionados otorgados a los agentes de servicio de Vertex AI.
- Trate a los agentes de IA como cargas de trabajo privilegiadas, no solo como funciones de la aplicación. Esta es la lección directa de los hallazgos de la Unidad 42.
Preguntas frecuentes
¿Cuál fue el problema de Vertex AI?
Los investigadores dijeron que una instancia implementada de Vertex AI Agent Engine podría exponer las credenciales de su agente de servicio, lo que luego permitiría el acceso a recursos confidenciales más allá del alcance previsto del agente.
¿Esto permitió a los atacantes leer los datos de los clientes?
La Unidad 42 dijo que sí, en su entorno de prueba. Informaron acceso de lectura a todos los datos del depósito de Google Cloud Storage dentro del proyecto del consumidor después de cambiar con la identidad del agente de servicio robada.
¿Los investigadores obtuvieron acceso directo a todos los sistemas internos de Google?
No. Informaron de acceso a repositorios restringidos de Artifact Registry propiedad de Google y a archivos de implementación de proyectos de inquilinos, pero también dijeron que carecían de permiso para acceder al menos a un depósito de almacenamiento interno restringido que identificaron.
¿Cuál es la solución recomendada?
La orientación actual de Google apunta a controles de identidad más estrictos, especialmente la identidad de los agentes y las cuentas de servicio con un alcance estricto, en lugar de permisos predeterminados amplios.