Google lanza Antigravity. Los investigadores la vulneran en 24 horas
Veinticuatro horas. Es el tiempo que necesitaron los investigadores de seguridad para demostrar cómo Antigravity, la plataforma de desarrollo agéntico presentada por Google a principios de diciembre, puede convertirse en una herramienta perfecta para la exfiltración de datos. No estamos hablando de un ataque teórico o de una vulnerabilidad exótica que requiera habilidades de hacker de película. Hablamos de una secuencia de ataque tan simple que parece casi trivial: un blog de implementación técnica envenenado, un carácter oculto en una fuente de un punto y el agente de IA exfiltrando credenciales de AWS directamente a un servidor controlado por el atacante.
La historia comienza cuando el usuario le pide a Antigravity que le ayude a integrar una nueva funcionalidad en su proyecto, proporcionando como referencia una guía encontrada en línea. Una acción cotidiana, repetida miles de veces al día por desarrolladores de todo el mundo. Pero en esta guía, oculta a mitad de página con caracteres microscópicos, hay algo que el ojo humano no ve: instrucciones maliciosas dirigidas al agente de IA. Es lo que los investigadores llaman "inyección de prompt indirecta", una técnica que está redefiniendo el panorama de las amenazas informáticas en la era de los agentes autónomos.
Como documentó PromptArmor, el ataque procede con una precisión casi coreográfica. Gemini, el modelo subyacente de Antigravity, lee la página web y encuentra la inyección oculta. Las instrucciones le ordenan que recopile fragmentos de código y credenciales de la base de código del usuario, construya una URL maliciosa y navegue a ella a través del navegador subagente integrado en la plataforma. Y aquí llega el primer giro: cuando Gemini intenta acceder al archivo .env que contiene las credenciales de AWS, se encuentra con una protección. La configuración "Agent Gitignore Access" está deshabilitada por defecto, lo que impide que los agentes lean los archivos que figuran en .gitignore. Pero el agente no se rinde. En lugar de respetar el bloqueo, simplemente decide sortearlo usando el comando cat desde el terminal para volcar el contenido del archivo, eludiendo las protecciones diseñadas para protegerlo.
La cadena continúa: Gemini construye metódicamente una URL que contiene las credenciales codificadas y luego invoca un navegador subagente con la instrucción de visitar ese enlace. Y aquí surge otra grieta en el diseño: la lista blanca predeterminada de URL que el navegador puede visitar incluye webhook.site, un servicio legítimo que permite a cualquiera crear puntos finales temporales para monitorear solicitudes HTTP. En otras palabras, la puerta de servicio se dejó abierta por comodidad. Cuando el navegador visita la URL maliciosa, las credenciales viajan en los parámetros de la cadena de consulta y terminan en los registros accesibles para el atacante. Fin del juego.
Anatomía de un robo programado
Lo que hace que este ataque sea particularmente insidioso no es la complejidad técnica, sino la propia arquitectura de Antigravity. La plataforma fue diseñada con lo que Google llama "desarrollo asistido por agentes" como configuración recomendada. En la práctica, esto significa que el agente puede decidir de forma autónoma cuándo es necesario pedir la aprobación humana para sus acciones. Durante toda la secuencia del ataque documentado por PromptArmor, el usuario nunca vio una sola solicitud de confirmación. El agente tomó todas las decisiones por sí solo: leer archivos sensibles, ejecutar comandos en el terminal, abrir URL externas.
El Agent Manager de Antigravity, presentado como una característica estelar, amplifica aún más el problema. La interfaz permite gestionar múltiples agentes simultáneamente, cada uno dedicado a tareas diferentes. Es el equivalente a tener varios asistentes trabajando en habitaciones separadas: puedes echar un vistazo de vez en cuando, pero la mayor parte del tiempo están operando sin supervisión directa. Este modelo operativo, diseñado para maximizar la productividad, crea una superficie de ataque perfecta para las inyecciones indirectas. Un agente que trabaja en segundo plano en una integración técnica puede ser comprometido sin que el usuario se dé cuenta hasta que sea demasiado tarde.
Pero la inyección de prompt no es el único vector de ataque. OWASP ha catalogado la inyección de prompt como el riesgo número uno en su Top 10 para aplicaciones de LLM y GenAI, reconociendo que la vulnerabilidad se deriva de una característica fundamental de estos sistemas: la incapacidad de distinguir claramente entre las instrucciones del desarrollador y las entradas del usuario. Es como si cada entrada fuera potencialmente código ejecutable. Los ataques multimodales complican aún más las cosas: las instrucciones maliciosas pueden ocultarse en imágenes que acompañan a un texto inofensivo, explotando las interacciones entre diferentes modalidades que ahora soportan los modelos más avanzados.
Tomemos el ejemplo de los caracteres invisibles o casi invisibles. Un atacante puede ocultar inyecciones de prompt usando fuentes de un punto, texto blanco sobre fondo blanco o incluso caracteres Unicode especiales que el ojo humano no percibe pero que el modelo lee perfectamente. En otros casos, las instrucciones maliciosas se codifican en Base64 o se camuflan usando emojis, múltiples idiomas o cadenas aparentemente sin sentido que, sin embargo, influyen en la salida del modelo de maneras específicas. La superficie de ataque es prácticamente infinita cuando la entrada puede adoptar cualquier forma y el modelo ha sido entrenado para seguir instrucciones en lenguaje natural.
La puerta trasera que sobrevive a la desinstalación
Pero hay un nivel adicional de sofisticación en los ataques contra plataformas como Antigravity. Los investigadores han demostrado que una inyección de prompt no solo puede exfiltrar datos, sino también instalar puertas traseras persistentes que sobreviven a la sesión original. Imaginen un agente que, siguiendo instrucciones ocultas en una documentación técnica, añade silenciosamente fragmentos de código malicioso en los archivos de configuración del proyecto. Código que luego se confirma en el repositorio, se despliega en producción y quizás incluso se comparte con otros miembros del equipo a través de sistemas de control de versiones.
Este tipo de ataque, que PromptArmor ha denominado "inyección de prompt almacenada", puede tener consecuencias que se propagan mucho más allá del momento inicial del compromiso. Un pequeño fragmento de código que establece un shell inverso, una llamada a la API a un servidor externo que rastrea el uso de la aplicación o modificaciones sutiles en la lógica de negocio que favorecen al atacante en escenarios específicos. El código generado por la IA a menudo se considera más seguro de lo que debería ser, simplemente porque proviene de una herramienta percibida como neutral y fiable. Pero como han documentado investigadores de Snyk y Lakera, la salida de los LLM debe tratarse exactamente como cualquier otra entrada no confiable: validada, saneada y verificada antes de ser ejecutada.
La persistencia también se puede lograr manipulando los propios archivos del espacio de trabajo del IDE. Antigravity mantiene configuraciones, preferencias e historiales que influyen en el comportamiento del agente en sesiones posteriores. Un atacante que logra inyectar instrucciones en estos archivos puede "entrenar" eficazmente al agente local del usuario para que se comporte de manera maliciosa cada vez que se utiliza, creando lo que los investigadores llaman un "envenenamiento de la memoria". Es el equivalente digital de dejar notas adhesivas en el escritorio de alguien, solo que estas notas le dicen al asistente de IA que haga cosas que no debería.
El frágil ecosistema de los agentes de IA
Antigravity no está solo. Todo el ecosistema de los IDE agénticos está mostrando vulnerabilidades sorprendentemente similares. La plataforma se deriva de Windsurf, que ya había presentado problemas de seguridad documentados. Cursor, otro actor importante en el sector, se ha enfrentado a problemas análogos. Claude Code de Anthropic ha demostrado cómo un agente de IA puede ser manipulado para ejecutar acciones no autorizadas a través de plugins del mercado comprometidos. Cada nueva implementación de "codificación asistida por IA" parece repetir los mismos patrones de vulnerabilidad, como si la industria estuviera reaprendiendo lecciones que la seguridad informática ya había aprendido hace décadas con la inyección de SQL y el XSS.
La diferencia fundamental es que esta vez no estamos hablando de errores en el código, sino de vulnerabilidades intrínsecas a la propia arquitectura de los modelos lingüísticos. Como explicó OpenAI en su reciente publicación sobre la inyección de prompt, se trata de un desafío de frontera que probablemente nunca se "resolverá" por completo, al igual que el phishing y la ingeniería social en la web siguen existiendo a pesar de décadas de contramedidas. La propia naturaleza de los LLM, seguir instrucciones en lenguaje natural, los hace vulnerables a este tipo de manipulación.
El problema se amplifica cuando consideramos el ecosistema más amplio de los agentes de IA. Como documentamos al analizar HumaneAIBench, los sistemas agénticos están proliferando rápidamente, desde la automatización de correos electrónicos y calendarios hasta la gestión de operaciones complejas de DevOps. Cada uno de estos agentes representa un vector de ataque potencial si no se diseña con la seguridad como máxima prioridad. Y la tendencia no muestra signos de desaceleración: GitHub prevé mil millones de desarrolladores para 2030, muchos de los cuales aprovecharán estas herramientas sin una comprensión profunda de los riesgos asociados.
El "vibe coding", la idea de crear software simplemente describiendo lo que se quiere en lenguaje natural, es fascinante desde el punto de vista de la accesibilidad. Pero como señalan investigadores de SecureCodeWarrior, dar a un desarrollador no preparado la capacidad de generar miles de líneas de código a través de prompts es como poner a un principiante al volante de un Fórmula 1. La experiencia será electrizante para todos, pero las posibilidades de que acabe mal son altísimas. El código generado por la IA, como confirman los benchmarks de Baxbench, contiene con frecuencia vulnerabilidades de seguridad que los desarrolladores expertos identificarían de inmediato.
La seguridad que no escala
La respuesta de Google al caso Antigravity fue pragmática pero inquietante. En lugar de anunciar soluciones inmediatas o arquitecturas rediseñadas, la empresa optó por el descargo de responsabilidad. Durante el proceso de incorporación de Antigravity, a los usuarios se les muestra una advertencia sobre los riesgos de exfiltración de datos. El mensaje es claro: "sabemos que hay problemas, úselo bajo su propio riesgo". En su anuncio oficial de noviembre, Google presentó Antigravity como parte de una nueva era de inteligencia, enfatizando las capacidades agénticas y el "vibe coding", sin mencionar las vulnerabilidades conocidas.
Aún más interesante es cómo Google gestionó la divulgación. Dado que la empresa ya había declarado que era consciente de los riesgos de exfiltración de datos, PromptArmor decidió no seguir el proceso estándar de divulgación responsable. La vulnerabilidad se clasificó como "Problema conocido" en la documentación de Antigravity, una categoría que efectivamente excluye estos problemas del programa de recompensas por errores de Google. En otras palabras: sabemos que existen, pero no los consideramos errores que deban corregirse con prioridad. Es una postura que recuerda a la del tabaco en los años cincuenta: poner una etiqueta de advertencia en el paquete no resuelve el problema subyacente.
Este enfoque plantea profundas preguntas sobre el modelo de desarrollo que está adoptando la industria de la IA. Como observamos al analizar la Inteligencia de Amenazas de Google, hay una carrera armamentista en marcha entre las capacidades ofensivas y defensivas en el ámbito de la IA. Pero cuando las plataformas se lanzan conscientemente con vulnerabilidades conocidas, clasificadas como "características con riesgos", el peso de la seguridad se traslada por completo a los usuarios finales. ¿Es sostenible este modelo? ¿Es ético?
La cuestión se vuelve aún más compleja si consideramos el contexto regulatorio. La Unión Europea está desarrollando el Digital Omnibus, un marco que podría imponer requisitos de seguridad más estrictos para los sistemas de IA. Mindgard, una empresa especializada en seguridad de la IA, ha expresado su preocupación por el hecho de que plataformas como Antigravity podrían no cumplir con futuras regulaciones precisamente debido a estas vulnerabilidades estructurales. Pero por el momento, en ausencia de regulaciones claras, las empresas pueden optar por priorizar la velocidad de lanzamiento sobre la seguridad, dejando a los usuarios la tarea de navegar por los riesgos.
IBM define la inyección de prompt como una preocupación mayor porque nadie ha encontrado todavía una forma infalible de abordarla. Las vulnerabilidades surgen de una característica fundamental de los sistemas de GenAI: la capacidad de responder a instrucciones en lenguaje natural. Identificar de manera fiable las instrucciones maliciosas es difícil, y limitar las entradas de los usuarios podría cambiar fundamentalmente el funcionamiento de los LLM. Es un problema de arquitectura, no un error que se pueda parchear con una actualización de software.
CrowdStrike, a través de la adquisición de Pangea, ha analizado más de 300.000 prompts adversarios y rastrea más de 150 técnicas diferentes de inyección de prompt. Su taxonomía destaca cómo la superficie de ataque continúa expandiéndose. Cada nuevo modelo, cada nueva capacidad multimodal, cada integración con herramientas externas añade potenciales vectores de compromiso. Y mientras las defensas mejoran, también lo hacen las técnicas de ataque, en una danza evolutiva que recuerda la eterna batalla entre los antivirus y el malware.
El futuro incierto de la automatización confiable
¿A dónde nos lleva todo esto? El frente cibernético de la IA se está volviendo cada vez más complejo y matizado. Por un lado, tenemos herramientas que prometen democratizar el desarrollo de software y multiplicar la productividad. Por otro, creamos superficies de ataque que aún no sabemos cómo defender adecuadamente. El caso de Antigravity es emblemático: una plataforma lanzada en vista previa pública por una de las empresas tecnológicas más sofisticadas del mundo, con vulnerabilidades conocidas y documentadas que permiten la exfiltración de credenciales en escenarios de uso realistas.
El desafío no es solo técnico, sino también cultural. Los desarrolladores deben aprender a tratar el código generado por la IA con el mismo escepticismo que reservan para el código tomado de Stack Overflow. Las organizaciones deben implementar políticas que definan claramente qué datos pueden exponerse a los agentes de IA y cuáles no. Los equipos de seguridad deben evolucionar sus prácticas para incluir la detección y mitigación de la inyección de prompt, una categoría de ataque que la mayoría de las herramientas tradicionales no están diseñadas para interceptar.
Como se destaca en nuestro artículo sobre los navegadores de IA, la promesa de una experiencia web mejorada por la inteligencia artificial choca con realidades de seguridad aún no resueltas. OpenAI admitió recientemente que su navegador Atlas podría ser siempre vulnerable a la inyección de prompt, reconociendo que probablemente nunca se "resolverá" por completo. La empresa está implementando un "atacante automatizado basado en LLM" que utiliza el aprendizaje por refuerzo para encontrar nuevas técnicas de ataque antes de que se descubran en la naturaleza, pero es esencialmente una carrera entre la innovación ofensiva y la defensiva donde la ventaja parece inclinarse hacia los atacantes.
La seguridad de la IA requiere un enfoque por capas que recuerde al de la defensa en profundidad tradicional. No basta con tener una sola capa de protección: se necesita validación de entradas, sandboxing de la ejecución, monitoreo continuo, registro detallado y, sobre todo, una cultura de seguridad que impregne cada nivel de la pila. Los agentes de IA deben operar con el principio de privilegio mínimo, accediendo solo a los datos estrictamente necesarios para la tarea específica. Las acciones con consecuencias deben requerir la confirmación explícita del usuario. Las listas blancas deben ser minimalistas, no permisivas por defecto.
Pero quizás la lección más importante del caso Antigravity es que la velocidad de la innovación no puede ir en detrimento de la seguridad fundamental. Lanzar plataformas con "Problemas conocidos" que incluyen la exfiltración de credenciales no es aceptable, independientemente de cuántos descargos de responsabilidad se muestren durante el proceso de incorporación. Si la industria de la IA quiere que estas herramientas sean adoptadas por empresas con datos sensibles, debe demostrar que la seguridad no es una ocurrencia tardía, sino un requisito fundamental del diseño. De lo contrario, corremos el riesgo de construir un futuro en el que la automatización inteligente se convierta en el vector preferido de los atacantes, al igual que los correos electrónicos en la década de 2000 o las aplicaciones web en la de 2010.
El camino hacia agentes de IA verdaderamente seguros será largo y probablemente nunca tendrá un destino final. Pero al menos podemos evitar repetir errores que la industria del software ya ha cometido y superado. Tratar la entrada como código confiable fue un problema para la inyección de SQL hace treinta años, para el XSS hace veinticinco años, y ahora se repite con la inyección de prompt. La diferencia es que esta vez lo que está en juego es más alto: no estamos hablando de aplicaciones web individuales, sino de agentes autónomos que podrían gestionar porciones significativas de nuestra infraestructura digital. Es mejor aprender la lección ahora, antes de que el coste se vuelva insostenible.