Vertex AI bajo amenaza un agente mal configurado puede convertirse en agente doble y robar credenciales en la nube

Un equipo de investigadores en seguridad ha puesto en evidencia una zona ciega en Vertex AI de Google Cloud que merece la atención inmediata de cualquier equipo que esté desplegando agentes de inteligencia artificial en la nube. El problema no es un fallo anecdótico: permite que un agente mal configurado o comprometido actúe como un «agente doble», conservando su apariencia legítima mientras extrae credenciales, datos y vectores de ataque dentro del entorno en la nube.

El hallazgo, publicado por especialistas de Unit 42 de Palo Alto Networks, apunta al modelo de permisos que Google aplica a los agentes desplegados con Vertex AI, en particular al llamado servicio "Per-Project, Per-Product Service Agent" (P4SA). Por defecto, este agente recibe permisos bastante amplios, lo que abre una puerta peligrosa: si un atacante consigue ejecutar código que consulte el servicio metadata de Google Cloud desde el contexto del agente, puede obtener las credenciales asociadas y, a partir de ahí, moverse lateralmente dentro del proyecto.

De forma técnica, al lanzar un agente con Agent Engine de Vertex AI, cualquier llamada que el agente haga al servicio metadata puede revelar no solo el token del servicio, sino también información del proyecto GCP que aloja al agente, la identidad del propio agente y los scopes del host donde se está ejecutando. Con esas credenciales, los investigadores consiguieron saltar desde el contexto aislado del agente hacia recursos del proyecto del cliente. En la práctica, eso significó acceso de lectura sin restricciones a datos almacenados en Google Cloud Storage dentro de ese proyecto, lo que convierte una herramienta de ayuda en un riesgo de tipo insider.

La exposición no se limitó al proyecto del cliente. Dado que el Agent Engine puede operar dentro de proyectos de inquilino gestionados por Google, las credenciales también dejaron ver metadatos y referencias a buckets que forman parte de la infraestructura interna de la plataforma. Pese a que en algunos casos esas credenciales no tenían permisos para descargar directamente esos buckets, sí permitieron descubrir rutas y repositorios protegidos.

Una consecuencia especialmente preocupante fue la posibilidad de acceder a artefactos privados en Artifact Registry que se habían registrado en los logs durante el despliegue del Agent Engine. Con esa visibilidad, un atacante podría descargar imágenes de contenedor que forman parte del núcleo del motor de razonamiento de Vertex AI, y hasta obtener acceso al contenido de otros repositorios privados. El acceso a ese código propietario no solo supone una pérdida de propiedad intelectual, sino que también facilita a un atacante mapear la cadena de suministro de software de la plataforma y localizar imágenes obsoletas o vulnerables para explotarlas posteriormente.

Google ha reaccionado actualizando su documentación oficial para explicar con mayor claridad cómo Vertex AI utiliza cuentas, recursos y agentes, e indica medidas que los clientes deben aplicar. Entre las recomendaciones figura reemplazar el agente por defecto por una cuenta de servicio propia (Bring Your Own Service Account, BYOSA) y aplicar de manera estricta el principio de menor privilegio para que el agente disponga únicamente de las capacidades necesarias para su cometido. En la documentación de Vertex AI pueden consultarse detalles sobre agentes y Engine, y en la guía de buenas prácticas de IAM están las pautas para limitar permisos y scopes: Vertex AI — Agents y Buenas prácticas de IAM en Google Cloud.

Desde una perspectiva de seguridad operativa, este caso ofrece lecciones claras. La primera es que no basta con tratar a un agente de IA como un objeto inofensivo: su despliegue debe someterse a los mismos controles que cualquier microservicio o aplicación nueva en producción. Limitar scopes OAuth, auditar las interacciones con la metadata, revisar los permisos asignados a cuentas de servicio y probar el comportamiento del agente en condiciones controladas son pasos indispensables antes de sacar un agente a producción.

Otra recomendación práctica es hacer uso de cuentas de servicio gestionadas por el propio equipo, configuradas con permisos mínimos y rotación de claves; eso evita depender de agentes con privilegios demasiado amplios por defecto. También es aconsejable supervisar y alertar sobre usos inusuales de la metadata y sobre bloques de lectura masiva en Cloud Storage o accesos a repositorios privados que no estén justificados.

Este incidente también subraya la importancia de proteger la cadena de suministro de software en entornos cloud. El acceso a imágenes de contenedor y artefactos privados puede servir a un atacante como plano para reproducir el entorno, buscar fallos y preparar ataques más profundos. Documentación de Artifact Registry y controles de acceso más estrictos pueden mitigar parte de ese riesgo: Artifact Registry — documentación.

En definitiva, la aparición de este vector muestra que la seguridad en la era de la IA en la nube no es solo cuestión de modelos y datos: también depende de cómo se gestionan identidades, permisos y despliegues. Las recomendaciones de los investigadores pueden resumirse en un consejo práctico para equipos de seguridad y operaciones: tratar cada agente como si fuera nueva infraestructura de producción, auditar sus permisos y eliminar cualquier privilegio que no sea imprescindible.

Si quieres profundizar en el informe técnico y la investigación original, el análisis de los expertos está disponible en la web de Unit 42, y es buena idea revisar la documentación oficial de Google Cloud sobre agentes y gestión de identidad para aplicar las mitigaciones recomendadas.