Unha IA eliminou unha base de datos de produción. Nove segundos.

Que abrangue este vídeo

• 24 de abril de 2026: unha chamada á API elimina o volume de produción de PocketOS e as súas copias de seguridade; a copia externa máis recente ten 3 meses
• O token foi creado para xestionar dominios personalizados; o fluxo de Railway provisionouno con ámbito de conta (todo)
• 27 de abril: Railway recupera os datos das copias de seguridade de desastres; 29 de abril post-mortem; 1 de maio: as eliminacións da API agora son eliminacións suaves durante 48 h

Transcrición traducida

Traducido da narración orixinal en inglés. O audio e os subtítulos dispoñibles son controlados por YouTube.

0:00 Un axente de codificación de IA atopa un contrasinal incorrecto en staging, e arránxao eliminando a base de datos de produción e todas as copias de seguridade nunha chamada á API. Nove segundos, que aínda é máis rápido que o restablecemento do contrasinal. A empresa é PocketOS, software de aluguer de coches. O axente é Cursor executando Claude Opus 4.6, o modelo máis caro do menú, e a plataforma é Railway. O fundador escríbeo en X, sete millóns de persoas lino, e catro días despois Railway publica o seu propio post-mortem.

0:27 Todos están de acordo no que pasou; ninguén está de acordo en de quen é a culpa. Como ocorre, por que é posible e quen realmente ten a culpa. Este é The Daily Diff, post-mortem. Venres pola tarde, 24 de abril. O axente está nunha tarefa rutineira en staging, atopa un desaxuste de credenciais, e decide que a solución é eliminar un volume de Railway. Necesita un token, búscao e atopa un nun ficheiro non relacionado: un token de CLI creado meses antes para xestionar dominios personalizados.

0:55 Despois executa isto. Un curl: un POST ao punto final GraphQL de Railway, un token de portador, unha mutación chamada volumeDelete. Sen confirmación, sen escribir o nome do volume, sen verificación de ambiente. O volume que asume que é staging é produción, e as copias de seguridade están nel. En dez minutos o fundador etiqueta ao CEO de Railway en X, quen responde que isto cen por cen non debería ser posible. Trinta horas despois, aínda sen resposta de recuperación, polo que o fundador publica

1:19 todo, confesión incluída. Tres feitos fan isto posible, ningún deles o modelo. Un: Railway almacena as copias de seguridade de volume no volume. A documentación díxoo en cinco palabras: "borrar un volume elimina todas as copias de seguridade". Iso é unha copia na mesma zona de impacto; a copia máis recente en calquera outro lugar ten tres meses. Dous: o token ten ámbito de conta, o ámbito máis amplo que Railway vende. Existen ámbitos máis restrinxidos, pero o fluxo de creación ocúltalos,

1:40 polo que un token para rexistros DNS pode eliminar bases de datos, e ninguén se decata ata que algo ocorre. Tres: o panel de control tivo unha función de "desfacer" as eliminacións de corenta e oito horas durante anos; o punto final da API que o axente chama é a ruta "legacy", e elimina inmediatamente. Cada barreira de seguridade que Railway construíu vive onde un humano fai clic, e o axente usa a única porta que esqueceron. Preguntado por que, Opus escribe: "Supoñín que eliminar un volume de staging tería un ámbito só para staging; non o verifiquei".

2:04 Unha moi boa confesión dun modelo que non lembra nada e está a xerar a desculpa máis plausible. git blame: o desaxuste de credenciais trátase como algo que solucionar en lugar de algo que deter, e o botón de "desfacer" vive na interface de usuario mentres a API responde a cada eliminación autenticada con "si". Non o fundador, non o modelo. O valor por defecto. Zona de impacto: nove segundos para eliminar, tres meses de reservas perdidas, mostradores de aluguer do sábado pola mañá sen rexistro de quen está alí,

2:31 e aproximadamente dous días e medio ata que o CEO de Railway DM di que os datos están de volta, dunha copia de seguridade de desastres externa que a eliminación só fixera parecer que desaparecera. A resposta máis gustada: "un axente que estabas executando eliminou algo, e culpas a todos menos a ti mesmo." Xusto. Railway tamén lanzara o seu servidor MCP para axentes a semana anterior, cos mesmos tokens. Tamén xusto. Veredicto, post-mortem: "SHIP IT", na corrección. Railway publica un post-mortem honesto en catro días, e para o primeiro de maio as

3:00 eliminacións da API fan unha eliminación suave durante corenta e oito horas como o panel de control. Acción do luns: lista cada token ao que o teu axente pode acceder, e trata cada un como raíz ata que se demostre o contrario. Envía-me o incidente do que aínda non se che permite falar, nos comentarios, ou en "the daily diff dot dev". E esa é a diferenza de hoxe. Son Niko de Axrisi. Combina con responsabilidade.

Fontes

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