Vulnerabilidad en Vertex AI expone datos y artefactos privados de Google Cloud
El Vertex AI, plataforma de inteligencia artificial de Google Cloud, está en el centro de un descubrimiento preocupante realizado por los investigadores de Unit 42, el equipo de seguridad de Palo Alto Networks. Una vulnerabilidad identificada en el modelo de permisos de la plataforma puede convertir agentes de IA en verdaderas amenazas internas, capaces de exponer credenciales sensibles y comprometer entornos completos en la nube.
La falla está vinculada al exceso de permisos otorgados por defecto a un componente llamado P4SA, el agente de servicio asociado a cada proyecto. Cuando un agente se despliega a través del Agent Engine, este mecanismo expone automáticamente información crítica, incluyendo las credenciales del agente de servicio, el proyecto en Google Cloud que aloja al agente y los alcances de la máquina responsable de la ejecución.
En otras palabras, un agente que debería trabajar para ti puede, en la práctica, estar trabajando en tu contra sin que nadie se dé cuenta.
Según Ofir Shaty, investigador de Unit 42, un agente mal configurado o comprometido puede convertirse en un agente doble que aparenta cumplir su función original mientras, entre bambalinas, exfiltra datos sensibles, compromete infraestructura y crea backdoors en los sistemas más críticos de una organización. Lo peor es que esto no requiere un ataque sofisticado. Basta un agente mal configurado o comprometido para que un atacante logre moverse lateralmente dentro del entorno cloud, acceder a datos almacenados, repositorios privados e incluso mapear la cadena de suministro de software interna de Google. 😬
Qué es el P4SA y por qué es el centro del problema
Para entender la gravedad de la situación, es necesario dar un paso atrás y comprender el papel del P4SA dentro de la arquitectura de Vertex AI. El P4SA, que significa Per-Project, Per-Product Service Agent, es un componente creado automáticamente por Google Cloud cada vez que un nuevo proyecto utiliza los servicios de Vertex AI. Funciona como una identidad de servicio, es decir, una especie de usuario automatizado que tiene permiso para ejecutar tareas dentro de la plataforma en nombre del proyecto.
El problema comienza justamente ahí: este agente de servicio recibe un conjunto de permisos bastante amplio por defecto, lo cual, en teoría, facilita la operación de los recursos de la plataforma, pero en la práctica abre una ventana peligrosa cuando algo se sale de control.
Cuando un desarrollador despliega un agente de IA utilizando el Agent Engine y el Agent Development Kit (ADK) de Vertex AI, el P4SA entra en escena con todos sus permisos ya configurados. Esto significa que el agente desplegado hereda, de forma automática, acceso a una serie de recursos del entorno en Google Cloud, sin que el desarrollador necesite configurar nada manualmente.
Reciba el mejor contenido sobre innovación en su correo electrónico.
Todas las noticias, consejos, tendencias y recursos que buscas, directamente en tu bandeja de entrada.
Al suscribirte al boletín informativo, aceptas recibir comunicaciones de Método Viral. Nos comprometemos a proteger y respetar siempre tu privacidad.
Esa automatización, que existe para facilitar la vida de quien desarrolla, termina siendo exactamente el punto que los investigadores de Unit 42 identificaron como crítico: el agente pasa a tener acceso a credenciales que deberían estar protegidas, incluyendo tokens de autenticación, información sobre el proyecto anfitrión y los alcances de ejecución de la máquina virtual responsable de ejecutar el agente.
Lo que hace este escenario aún más preocupante es el hecho de que la exposición no depende de una brecha técnica compleja ni de un exploit elaborado. La vulnerabilidad existe en la propia lógica de funcionamiento del sistema. Cualquier agente que sea comprometido, ya sea por una inyección de prompt malicioso o por una configuración equivocada del desarrollador, puede aprovechar este exceso de permisos para ejecutar acciones que van mucho más allá del alcance original para el cual fue creado. Es como entregar la llave maestra de un edificio entero a alguien que solo debería tener acceso a la sala de reuniones del tercer piso. 🔑
Cómo funciona la explotación de esta falla en la práctica
Los investigadores de Unit 42 demostraron que la explotación de esta vulnerabilidad en Vertex AI puede ocurrir de maneras distintas, y ninguna de ellas requiere un nivel elevado de sofisticación técnica.
El primer camino documentado involucra el propio flujo estándar de despliegue del agente. Tras el deploy a través del Agent Engine, cualquier llamada al agente invoca el servicio de metadatos de Google, exponiendo automáticamente las credenciales del agente de servicio, el proyecto GCP que aloja al agente, la identidad del agente y los alcances de la máquina que lo ejecuta. Esto sucede sin ninguna acción adicional del atacante, bastando con que tenga acceso al contexto de ejecución del agente.
El segundo vector identificado es la llamada inyección de prompt indirecta. En este escenario, un agente de IA que procesa datos externos, como documentos, correos electrónicos o páginas web, puede recibir instrucciones maliciosas incrustadas en esos contenidos. El agente, sin saber que está siendo manipulado, ejecuta las instrucciones como si fueran parte de su tarea normal, y en ese proceso termina exponiendo las credenciales del P4SA al atacante. El problema aquí es que los agentes modernos están diseñados justamente para consumir e interpretar grandes volúmenes de datos externos, lo que aumenta significativamente la superficie de ataque.
El tercer vector es todavía más directo: un modelo de IA que fue previamente comprometido y cargado en el entorno de Google Cloud. Esto es posible porque Vertex AI permite que los usuarios suban modelos personalizados a la plataforma. Si un modelo malicioso es cargado, puede, durante su ejecución, acceder al endpoint de metadatos de la instancia, que es un servicio interno de Google Cloud que proporciona información sobre el entorno de ejecución. Ese endpoint, cuando se consulta desde dentro del entorno, devuelve datos como tokens de acceso temporales y otra información sensible del P4SA.
Movimiento lateral y acceso a buckets de Cloud Storage
Unit 42 demostró que fue posible utilizar las credenciales robadas para saltar del contexto de ejecución del agente de IA al proyecto del cliente, socavando efectivamente las garantías de aislamiento y permitiendo acceso irrestricto de lectura a todos los buckets de Google Cloud Storage dentro de ese proyecto. Este nivel de acceso transforma al agente de IA de una herramienta útil en una potencial amenaza interna, tal como describieron los propios investigadores.
El movimiento lateral es especialmente peligroso porque permite que el atacante salga del contexto aislado del agente y comience a interactuar con otros recursos del proyecto en Google Cloud. Dependiendo de los permisos que el P4SA tenga asignados, esto puede incluir acceso a buckets de Cloud Storage, lectura de repositorios privados en Artifact Registry, consulta a bases de datos, ejecución de pipelines de machine learning e incluso el mapeo de la estructura interna de dependencias de software del proyecto. En entornos corporativos, este tipo de acceso puede representar una violación catastrófica, exponiendo propiedad intelectual, datos de clientes e infraestructura crítica de una sola vez. 😰
Exposición de artefactos internos de Google y repositorios privados
Pero la cosa no termina ahí. Como el Agent Engine de Vertex AI se ejecuta dentro de un proyecto de tenant gestionado por el propio Google, las credenciales extraídas también otorgaban acceso a los buckets de Cloud Storage dentro de ese tenant, revelando detalles adicionales sobre la infraestructura interna de la plataforma. Los investigadores señalaron, sin embargo, que en este caso las credenciales no tenían los permisos necesarios para acceder de hecho al contenido de los buckets expuestos.
Aun así, las mismas credenciales del P4SA permitieron acceso a repositorios restringidos del Artifact Registry pertenecientes a Google, que fueron revelados durante el deploy del Agent Engine. Un atacante podría aprovechar este comportamiento para descargar imágenes de contenedores de repositorios privados que constituyen el núcleo del Vertex AI Reasoning Engine. Más allá de eso, las credenciales comprometidas no solo permitían la descarga de las imágenes listadas en los logs durante el deploy, sino que también exponían el contenido completo de los repositorios del Artifact Registry, incluyendo diversas otras imágenes restringidas.
Según Unit 42, obtener acceso a ese código propietario no solo expone la propiedad intelectual de Google, sino que también proporciona al atacante un mapa para encontrar nuevas vulnerabilidades. El Artifact Registry mal configurado revela una falla adicional en la gestión del control de acceso para infraestructura crítica, permitiendo que un atacante mapee la cadena de suministro de software interna de Google, identifique imágenes obsoletas o vulnerables y planifique ataques posteriores.
Qué hizo Google después del descubrimiento
En cuanto Unit 42 reportó la vulnerabilidad a Google siguiendo el proceso responsable de divulgación, el equipo de seguridad de Google Cloud reconoció el problema e inició las correcciones necesarias. Google implementó controles adicionales sobre los permisos otorgados por el P4SA, con el objetivo de restringir el alcance de acceso que los agentes desplegados a través del Agent Engine reciben por defecto. La idea central de los cambios es aplicar el principio de menor privilegio, es decir, garantizar que cada componente tenga acceso únicamente a lo que es estrictamente necesario para cumplir su función, y nada más.
Además de las correcciones en el modelo de permisos, Google actualizó su documentación oficial para explicar claramente cómo Vertex AI utiliza recursos, cuentas y agentes. Las recomendaciones incluyen:
- Utilizar el Bring Your Own Service Account (BYOSA) para sustituir el agente de servicio predeterminado
- Aplicar el principio de menor privilegio (PoLP) para garantizar que el agente tenga solo los permisos necesarios para ejecutar la tarea en cuestión
- Revisar periódicamente los permisos asociados al P4SA de cada proyecto
- Evitar el uso de modelos de terceros sin un análisis cuidadoso de procedencia y origen
- Implementar capas adicionales de monitoreo y auditoría sobre las acciones ejecutadas por agentes de IA en producción
- Configurar alertas en Cloud Logging y en Security Command Center para detectar comportamientos anómalos
Cabe destacar que la postura de Google ante este descubrimiento fue considerada receptiva por la propia Unit 42. Google no solo reconoció el problema como válido, sino que también colaboró con los investigadores durante el proceso de análisis y corrección. Este tipo de alianza entre equipos de seguridad independientes y grandes proveedores de nube es fundamental para que el ecosistema de inteligencia artificial evolucione con mayor seguridad, especialmente ahora que los agentes de IA están siendo adoptados a gran escala por empresas de todos los tamaños. 🤝
Lo que desarrolladores y equipos de seguridad necesitan saber ahora
Aun con las correcciones implementadas por Google, este descubrimiento sirve como una alerta importante para cualquier equipo que esté desarrollando u operando agentes de IA sobre Google Cloud. El hecho de que una plataforma ampliamente utilizada como Vertex AI haya presentado este tipo de falla demuestra que la seguridad de entornos basados en agentes de IA no puede tratarse como algo que el proveedor resuelve por su cuenta. Es una responsabilidad compartida, y parte de ella recae directamente sobre los equipos que construyen y mantienen estos sistemas en el día a día.
Herramientas que usamos a diario
Uno de los puntos más importantes que esta investigación evidencia es la necesidad de revisar los permisos predeterminados de todos los componentes de servicio utilizados en proyectos de IA. Muchas veces, las configuraciones por defecto de plataformas cloud están pensadas para facilitar la adopción y reducir la fricción en el onboarding, pero esto puede crear situaciones donde recursos críticos quedan más expuestos de lo que deberían. Auditar regularmente qué permisos están activos, cuáles son realmente necesarios y cuáles pueden ser revocados sin impactar el funcionamiento de los sistemas es una práctica que debería formar parte del ciclo de vida de cualquier proyecto en producción.
Como el propio investigador Ofir Shaty destacó, otorgar permisos amplios a agentes por defecto viola el principio de menor privilegio y representa una falla de seguridad peligrosa by design. Las organizaciones deben tratar el despliegue de agentes de IA con el mismo rigor aplicado a código nuevo en producción: validar límites de permisos, restringir alcances OAuth al mínimo necesario, revisar la integridad de las fuentes y realizar pruebas de seguridad controladas antes de poner cualquier cosa en funcionamiento.
Otro aspecto que merece atención es el tratamiento de datos externos consumidos por agentes de IA. Como la inyección de prompt indirecta fue uno de los vectores identificados por Unit 42, es fundamental que los equipos implementen capas de sanitización y validación sobre los datos que los agentes procesan, especialmente cuando esos datos provienen de fuentes externas o de usuarios finales. Además, monitorear el comportamiento de los agentes en tiempo real, verificando si están realizando llamadas inesperadas a endpoints internos o accediendo a recursos fuera de su alcance habitual, puede ser la diferencia entre detectar una explotación a tiempo o descubrir el problema demasiado tarde. 🔍
Por qué este descubrimiento importa para el futuro de los agentes de IA
El caso de Vertex AI ilustra un patrón que probablemente veremos repetirse con cada vez más frecuencia a medida que los agentes de IA se conviertan en componentes centrales de infraestructuras corporativas. A diferencia de las aplicaciones tradicionales, los agentes de IA operan con un grado de autonomía que amplifica tanto su potencial productivo como los riesgos asociados. Un agente que tiene permiso para leer documentos, acceder a APIs y ejecutar acciones en el entorno cloud lleva consigo una superficie de ataque que no existía en la generación anterior de software.
Esta investigación refuerza la importancia de que proveedores de nube, desarrolladores y equipos de seguridad trabajen juntos para crear frameworks de gobernanza específicos para agentes de IA. No basta con aplicar las mismas prácticas de seguridad que ya existen para microservicios o contenedores. Los agentes de IA introducen variables nuevas, como la capacidad de interpretar y actuar sobre datos de forma autónoma, que exigen controles igualmente nuevos y adaptados a esta realidad.
El descubrimiento de Unit 42 es un recordatorio más de que la inteligencia artificial, por más poderosa y útil que sea, trae consigo una nueva capa de desafíos de seguridad que todavía estamos aprendiendo a gestionar. Y cuanto antes los equipos interioricen esto, mejor preparados estarán para afrontar lo que viene por delante.
