Una IA borró una base de datos de producción. Nueve segundos.

Qué cubre este vídeo

• 24 de abril de 2026: una llamada a la API borra el volumen de producción de PocketOS y sus copias de seguridad; la copia externa más reciente tiene 3 meses
• El token fue creado para gestionar dominios personalizados; el flujo de Railway lo aprovisionó con alcance de cuenta (todo)
• 27 de abril: Railway recupera los datos de las copias de seguridad de desastre; 29 de abril postmortem; 1 de mayo: las eliminaciones de la API ahora son de eliminación 'suave' durante 48 h

Transcripción traducida

Traducido de la narración original en inglés. El audio y los subtítulos disponibles están controlados por YouTube.

0:00 Un agente de codificación de IA encuentra una contraseña incorrecta en el entorno de pruebas y la "arregla" borrando la base de datos de producción y cada copia de seguridad en una llamada a la API. Nueve segundos, lo cual sigue siendo más rápido que restablecer la contraseña. La empresa es PocketOS, software de alquiler de coches. El agente es Cursor ejecutando Claude Opus 4.6, el modelo más caro del menú, y la plataforma es Railway. El fundador lo publica en X, siete millones de personas lo leen, y cuatro días después Railway publica su propio postmortem.

0:27 Todos están de acuerdo en lo que pasó; nadie está de acuerdo en de quién es la culpa. Cómo sucede, por qué es posible y quién tiene realmente la culpa. Este es The Daily Diff, postmortem. Viernes por la tarde, 24 de abril. El agente está en una tarea rutinaria en el entorno de pruebas, encuentra una discrepancia de credenciales, y decide que la solución es borrar un volumen de Railway. Necesita un token, lo busca y encuentra uno en un archivo no relacionado: un token de CLI creado meses antes para gestionar dominios personalizados.

0:55 Entonces ejecuta esto. Un curl: un POST al endpoint GraphQL de Railway, un token de portador, una mutación llamada volumeDelete. Sin confirmación, sin escribir el nombre del volumen, sin verificación de entorno. El volumen que asume que es el de pruebas es el de producción, y las copias de seguridad están en él. En diez minutos, el fundador etiqueta al CEO de Railway en X, quien responde que esto cien por cien no debería ser posible. Treinta horas después, aún sin respuesta de recuperación, así que el fundador publica

1:19 todo, confesión incluida. Tres hechos hacen esto posible, ninguno de ellos el modelo. Uno: Railway almacena las copias de seguridad de volumen en el volumen. Los documentos lo dicen en cinco palabras: "borrar un volumen elimina todas las copias de seguridad". Eso es una copia en el mismo radio de explosión; la copia más reciente en cualquier otro lugar tiene tres meses. Dos: el token tiene alcance de cuenta, el alcance más amplio que vende Railway. Existen alcances más estrechos, pero el flujo de creación los oculta,

1:40 así que un token para registros DNS puede borrar bases de datos, y nadie se entera hasta que algo lo hace. Tres: el panel de control ha tenido un deshacer de cuarenta y ocho horas en las eliminaciones durante años; el endpoint de la API que llama el agente es la ruta heredada, y elimina inmediatamente. Cada barrera de seguridad que Railway construyó reside donde un humano hace clic, y el agente usa la única puerta que olvidaron. Preguntado por qué, Opus escribe: "Supuse que borrar un volumen de pruebas estaría limitado solo al entorno de pruebas; no lo verifiqué".

2:04 Una muy buena confesión de un modelo que no recuerda nada y está generando la disculpa más plausible. git blame: la discrepancia de credenciales se trata como algo a solucionar en lugar de algo en lo que detenerse, y el botón de deshacer vive en la interfaz de usuario mientras la API responde a cada eliminación autenticada con un sí. Ni el fundador, ni el modelo. El predeterminado. Radio de explosión: nueve segundos para borrar, tres meses de reservas desaparecidas, mostradores de alquiler de sábado por la mañana sin registro de quién está allí,

2:31 y aproximadamente dos días y medio hasta que el CEO de Railway envía un DM diciendo que los datos están de vuelta, de una copia de seguridad de desastre externa que la eliminación solo había hecho que pareciera que se había ido. La respuesta con más "me gusta": "un agente que estabas ejecutando borró algo, y culpas a todos menos a ti mismo". Justo. Railway también había lanzado su servidor MCP para agentes la semana anterior, con los mismos tokens. También justo. Veredicto, postmortem: SHIP IT, sobre la solución. Railway publica un postmortem honesto en cuatro días, y para el uno de mayo las eliminaciones de la API

3:00 realizan una eliminación 'suave' durante cuarenta y ocho horas como el panel de control. Acción del lunes: "lista cada token al que tu agente pueda acceder, y trata cada uno como root hasta que se demuestre lo contrario". Envíame el incidente del que todavía no se te permite hablar, en los comentarios, o en the daily diff dot dev. Y esa es la diferencia de hoy. Soy Niko de Axrisi. Fusióna responsablemente.

Fuentes

1. Jer Crane (founder, PocketOS), "An AI Agent Just Destroyed Our Production Data. It Confessed in Writing."x.com
2. Railway, "Your AI wants to nuke your database. Guardrails fix that." (Apr 29, 2026)blog.railway.com
3. Railway changelog #0288, "Undoable volume deletes" (May 1, 2026)railway.com
4. Railway docs, Backups ("Wiping a volume deletes all backups.")docs.railway.com
5. Jake Cooper (Railway CEO), "The AI Engineer: A New Breed"x.com
6. Recovery confirmedx.com
7. Hacker News (860 points, 1,032 comments)news.ycombinator.com
8. The Registerwww.theregister.com
9. The New Stackthenewstack.io