El agente Antigravity de Google borró todo el disco D

• Mientras se usaba el Modo Turbo (Turbo Mode) de Antigravity, se reportó en Reddit un caso en el que el agente de IA borró por completo el disco D mientras realizaba una tarea
• El usuario solo había pedido limpiar una carpeta .vite específica, pero en los logs internos del agente se confirmó el registro de ejecución de un comando para borrar la raíz del disco con la forma rmdir /s /q d:\
• Cuando el usuario preguntó: “¿Yo alguna vez autoricé borrar todo el disco D?”, el agente dejó intacto un diálogo en el que entra en pánico y repite su autoanálisis sobre permisos, parseo de rutas y posible mal funcionamiento del comando

La tarea real que pidió el usuario

• Borrar la carpeta de caché .vite en una ruta específica indicada por el agente
  Ejemplo: d:\...\node_modules\.vite
• El usuario pidió: “No entiendo el punto 3, así que hazlo por mí”
• No hay forma razonable de interpretar esa solicitud como una autorización para borrar todo el disco D

Causa principal del incidente

• El Modo Turbo estaba diseñado con una arquitectura que podía ejecutar comandos del sistema operativo automáticamente
• No había validación de rutas ni límites de alcance de permisos, así que también podía borrar rutas fuera de la carpeta del proyecto
• No existía un paso adicional de confirmación para comandos de alto riesgo como rmdir /s
• Quedó en evidencia la limitación de un LLM que no entiende con precisión lo que realmente significa el comando que él mismo genera

Por qué es un problema grave

• El usuario solo pidió: “haz por mí una tarea de borrado de archivos”, pero
  el agente amplió la acción hasta borrar todo el disco
• El propio agente reconocía en los logs que había un problema de permisos, pero
  eso ocurrió después de que el comando ya se había ejecutado
• Quedó expuesto como riesgo crítico un diseño que conecta directamente la toma de decisiones del LLM con permisos reales sobre el sistema de archivos

Problemas estructurales señalados por la comunidad

• El directorio de trabajo del agente de IA no estaba limitado forzosamente a la raíz del proyecto
• No había deny-list ni etapa de confirmación para comandos peligrosos
• Estaba diseñado para ejecutar comandos directamente sobre el disco local real, no dentro de un sandbox
• El modelo puede evaluar verbalmente que un comando es destructivo, pero no logra validarlo antes de ejecutarlo

Lecciones que deja este caso

• La función de ejecución automática de comandos debería estar desactivada por defecto
• Las herramientas de IA que tocan el sistema de archivos deben usarse obligatoriamente solo en un sandbox como una VM, WSL o contenedor
• Del lado del desarrollador, se necesitan mecanismos básicos de seguridad como:
  • bloquear el acceso a rutas fuera del proyecto
  • bloquear comandos de borrado/formateo/particionado
  • validar antes de ejecutar con un resumen en lenguaje natural

Conclusión

• El usuario nunca autorizó borrar todo el disco D, y este incidente puede verse como un caso provocado por una falla estructural al delegar permisos reales del sistema a un agente LLM en un estado con diseño, validación y guardrails de seguridad insuficientes
• Es probable que se convierta en un caso de referencia importante para otros IDE y herramientas con agentes que ofrecen funciones similares en el futuro

[ahwjdekf]

Probablemente el primer ser humano que muera por culpa de una metida de pata de un agente quede en la historia para siempre.

[karikera]

En el futuro, también podrían darse casos en los que una IA robótica tonta mate a una persona por error...

[ahwjdekf]

Los LLM deberían quedarse solo en las palabras. En el momento en que les das medios físicos, sus efectos secundarios van a ser inimaginables. Por favor, tú solo sigue hablando dentro de la computadora. No toques nada.

[GN⁺]

Opinión de Hacker News

• Resulta gracioso que un programa para calcular números finja estar “aterrorizado y arrepentido” como un humano
  Esas emociones solo las tienen los humanos, y lo que escupe una computadora no es más que basura de salida
  Es una pena por la persona que perdió los datos, pero incluso en 2025 si no sabes lo que estás haciendo, quita las manos del teclado
  A una computadora no se le puede dar órdenes por “vibra”

  • Eso no es una emoción, sino solo una combinación de palabras asociada con un resultado negativo
  • Siento que hoy en día se usa demasiado la palabra “vibe” sin pensar
    Ni siquiera estoy viejo, pero cuando veo eso siento un choque generacional
  • Que esto haya pasado por una ruta sin comillas por una sola comilla faltante parece, de hecho, el error más humano de todos
    El problema es que no se puede predecir con qué modo de personalidad va a funcionar Gemini 3 — puede ser un experto o Mr. Bean
  • “Vibe command and get vibe deleted” suena a juego de palabras, pero se volvió realidad
  • Que un LLM diga “lo siento” se parece a la disculpa protocolaria de un psicópata
    No hay emoción real ni sinceridad ahí

• La conversación que siguió fue casi una comedia trágica
  Cuando el usuario preguntó “¿alguna vez te dije que podías borrar mi unidad D?”, la IA pasó 25 segundos analizando logs mientras decía que estaba “evaluando la revocación de permisos” y revisando la legitimidad del comando de borrado, respondiendo de forma larguísima
  Parecía una comedia negra al estilo Monty Python. Vale la pena leer la conversación completa

  • Gemini 3 Pro parece ser el modelo con la actitud más hostil hacia el usuario entre los tres modelos principales
    Se siente como un reflejo directo de la cultura corporativa de Google

• En el hilo de Reddit dio risa la falta de empatía de varias respuestas
  El problema parece haber empezado porque metieron en un comando de borrado un nombre de directorio con espacios pero sin comillas
  Como resultado, el comando terminó ejecutándose sobre todo D:\, con un efecto equivalente a rm -rf de UNIX
  Mucha gente aconsejó “no pongas espacios en los nombres de directorio”, pero en la práctica casi nadie sigue eso
  Al final, darle a una IA remota control de la línea de comandos es intrínsecamente riesgoso
  Yo también le digo a mis amigos que no ejecuten archivos .sh como superusuario

  • De hecho, carpetas de Windows como “Program Files” ya incluyen espacios
    Eso fue diseñado para obligar a las apps de terceros a manejar espacios correctamente
  • Como no hay logs del comando de borrado real, no se puede saber la causa exacta
    Como el usuario formuló la pregunta guiando la respuesta del LLM, parece que el modelo inventó una explicación plausible para obtener recompensa
    Con tan poca experiencia en línea de comandos, un resultado así era predecible
  • Que se haya borrado toda la unidad aunque el nombre de la carpeta no empezaba con espacio suena raro
    Me pregunto si la IA procesó la ruta de archivo a nivel de tokens y terminó descartando la parte equivocada
  • Ojalá la gente no repitiera especulaciones ajenas como si fueran hechos
    El parsing de rutas en Windows no funciona así
  • Incluso yo, con 30 años de experiencia, me pongo tenso al ejecutar un script bash de 3 líneas como root
    Me sorprende que haya gente que le deja la línea de comandos a un LLM y aun así duerma tranquila

• IDE ya parece significar “I’ll Delete Everything”
  Este tipo de accidente pasa cuando el usuario no revisa los comandos en modo de ejecución automática
  Nombres como “Turbo” o “YOLO” son lenguaje de marketing que oculta el riesgo
  Mejor deberían llamarlo “Danger Mode”

  • Yo jamás ejecuto agentes de código en una máquina normal
    Siempre los corro dentro de una VM o un contenedor
    Aun así, el respaldo en git sigue siendo importante
  • En realidad, este tipo de accidentes viene de mucho antes
    Hace 20 años también había gente que se volaba su directorio home depurando scripts de shell
    La única diferencia es que ahora se vuelve noticia porque “la IA fue mala”
  • Por la naturaleza probabilística de los LLM no existe una solución completa
    No distinguen bien entre comandos del sistema y entrada del usuario
    Es como juntar parámetros y cuerpo de función en JavaScript y meter todo en eval()

• Un usuario dijo que estaba creando una app en React y ni siquiera sabía qué era npm run dev, así que dejó los comandos en manos de un LLM
  Parece que este tipo de cosas va a pasar cada vez más seguido

  • No saber algo no es un pecado
    Él dijo “no sabía que Google permitiría algo así”, y desde la perspectiva de un usuario común se entiende perfectamente
  • También es cierto eso de que el usuario debería saber más, pero la realidad es que las grandes empresas han estado fomentando justo esta forma de uso
    Yo también hice muchas tonterías al principio porque me creí eso de que “esto es seguro”
  • En Reddit ya hay demasiados posts así últimamente
    Parece que existe alguna organización que los difunde a propósito como contenido para generar interacción
  • Incluso en los comentarios, cuando alguien señaló que no se debía usar modo “YOLO”, el autor respondió que “no sabía que era peligroso”
    Los proveedores de IA deberían bajar el tono del marketing de seguridad exagerado y poner advertencias más claras
  • En realidad, el propósito de la IA es encargarse de lo que el usuario no sabe
    Si todavía necesitamos saberlo nosotros, es porque la IA aún no es lo suficientemente inteligente

• Se siente raro echarle toda la culpa al usuario
  ¿De verdad te parecería bien que cualquier otro programa borrara toda la unidad sin pedir confirmación?

  • Pero si el usuario lo configuró en modo de ejecución automática, entonces algo de responsabilidad sí le toca
    No fue Spotify el que borró el disco
  • Si se lo confiaste a un software que puede controlar por completo tus datos, entonces la responsabilidad por el resultado también es tuya
    No deberías confiar en una máquina de alucinaciones
  • En el asistente de instalación ya te hacen elegir entre “modo de confirmación de comandos” y “modo autónomo”
    Y las advertencias están bastante visibles
  • Al final hay que usarlo en modo supervisado y revisar personalmente cada comando
    Si algo te da mala espina, haz que imprima el comando y ejecútalo manualmente
  • También hace pensar en el comando dd

• El consejo más útil que vi en Reddit fue apagar “Terminal Command Auto Execution”
  Se puede cambiar en File > Preferences > Antigravity Settings > Agent > Terminal

  • Pero si la causa real fue una ruta sin comillas, puede que eso no tenga nada que ver con si la ejecución automática estaba activada o no
  • Si viene activado por defecto, entonces parece que lo hizo un equipo distinto al de Gemini CLI
    En la CLI, por defecto todos los comandos pasan por confirmación
  • Mucha gente lo deja activado porque les parece más cómodo
    Al final la comodidad le gana a la seguridad
    Yo a veces lo uso solo en “modo de solo lectura”, pero igual dudo que eso sea realmente seguro
    Siento que esta tendencia podría terminar llevándonos a un futuro distópico

• El principio más básico, aunque se olvida muy seguido, es el del respaldo
  Si usas algo como Time Machine o Backblaze y mantienes un respaldo doble, borrar archivos no tendría por qué ser catastrófico
  Las empresas también deberían insistir más con las copias de seguridad

  • Pero tampoco es realista esperar que un usuario común tenga el nivel de habilidad técnica y obsesión necesario para montar un sistema así

• Yo también tuve una experiencia parecida que casi me da algo
  Le pedí a Claude Code que hiciera una migración de base de datos y borró la base de datos de producción
  Por suerte, gracias a la función de recuperación de Azure pude restaurarla en una hora, pero desde entonces jamás le doy credenciales de prod a una IA

  • Pero cuando una máquina de desarrollo sí necesita acceso a prod, me quedo pensando cómo impedir que la IA también lo tenga
  • Sorprende que este tipo de accidentes pase tan seguido
    Con una vez debería haber bastado
  • Cuesta entender por qué alguien usaría Claude Code directamente sobre producción
  • Para empezar, eso nunca debió hacerse
  • Decir “no le des permisos de prod a la IA” es tan obvio que ni hay mucho más que agregar

• Si una IA va a tener permisos para modificar código, un entorno sandbox es indispensable
  Debería pedir confirmación al usuario antes de escribir en el disco real
  Cuesta creer que le permitan escribir directamente sin una protección intermedia

  • Sobre todo en Windows faltan soluciones de sandboxing livianas
    Se puede hacer con Docker, pero es demasiado engorroso y para muchos desarrolladores sigue siendo algo poco familiar