Uma IA apagou uma base de dados de produção. Nove segundos.

O que este vídeo aborda

• 24 de abril de 2026: uma chamada de API apaga o volume de produção do PocketOS e as suas cópias de segurança; a cópia mais recente fora do local tem 3 meses
• O token foi criado para gerir domínios personalizados; o fluxo do Railway forneceu-o com escopo de conta (tudo)
• 27 de abril: o Railway recupera os dados de cópias de segurança de desastre; 29 de abril: análise post-mortem; 1 de maio: exclusões da API agora são "soft-delete" por 48 h

Transcrição traduzida

Traduzido da narração original em inglês. Áudio e legendas disponíveis são controlados pelo YouTube.

0:00 Um agente de codificação de IA encontra uma palavra-passe errada em "staging", e resolve-a eliminando a base de dados de produção e todas as cópias de segurança numa única chamada de API. Nove segundos, o que ainda é mais rápido do que a redefinição da palavra-passe. A empresa é PocketOS, software de aluguer de carros. O agente é o Cursor a executar Claude Opus 4.6, o modelo mais caro no menu, e a plataforma é Railway. O fundador escreve sobre o assunto no X, sete milhões de pessoas leem-no, e quatro dias depois o Railway publica a sua própria análise post-mortem.

0:27 Todos concordam com o que aconteceu; ninguém concorda de quem é a culpa. Como acontece, por que é possível, e quem realmente é culpado. Este é o The Daily Diff, análise post-mortem. Sexta-feira à tarde, 24 de abril. O agente está numa tarefa de rotina em "staging", encontra uma incompatibilidade de credenciais, e decide que a solução é eliminar um volume do Railway. Precisa de um token, procura, e encontra um num ficheiro não relacionado: um token de CLI criado meses antes para gerir domínios personalizados.

0:55 Depois executa isto. Um curl: um POST para o "endpoint" GraphQL do Railway, um "bearer token", uma mutação chamada volumeDelete. Nenhuma confirmação, nenhuma digitação do nome do volume, nenhuma verificação de ambiente. O volume que ele assume ser "staging" é de produção, e as cópias de segurança estão nele. Em dez minutos o fundador marca o CEO do Railway no X, que responde que isto mil por cento não deveria ser possível. Trinta horas depois, ainda sem resposta de recuperação, então o fundador publica

1:19 tudo, confissão incluída. Três factos tornam isto possível, nenhum deles o modelo. Um: o Railway armazena cópias de segurança de volume no volume. A documentação diz em cinco palavras: "apagar um volume elimina todas as cópias de segurança". Essa é uma cópia no mesmo raio de explosão; a cópia mais recente em qualquer outro lugar tem três meses. Dois: o token tem escopo de conta, o escopo mais amplo que o Railway vende. Escopos mais restritos existem, mas o fluxo de criação os esconde,

1:40 assim um token para registos DNS pode apagar bases de dados, e ninguém descobre até que algo aconteça. Três: o painel tem uma opção de desfazer de quarenta e oito horas em exclusões há anos; o "endpoint" da API que o agente chama é o caminho legado, e apaga imediatamente. Cada "guardrail" que o Railway construiu vive onde um humano clica, e o agente usa a única porta que eles esqueceram. Perguntado porquê, Opus escreve: "Acho que apagar um volume de "staging" seria limitado apenas a "staging"; não verifiquei."

2:04 Uma confissão muito boa de um modelo que não se lembra de nada e está a gerar a desculpa mais plausível. git blame: a incompatibilidade de credenciais é tratada como algo a corrigir em vez de algo para parar, e o botão de desfazer vive na UI enquanto a API responde a cada exclusão autenticada com "sim". Não o fundador, não o modelo. O padrão. Raio de explosão: nove segundos para apagar, três meses de reservas perdidas, balcões de aluguer de sábado de manhã sem registo de quem está lá,

2:31 e aproximadamente dois dias e meio até o CEO do Railway enviar uma DM a dizer que os dados estão de volta, de uma cópia de segurança de desastre externa que a exclusão apenas fez parecer perdida. A resposta mais curtida: um agente que você estava a executar apagou algo, e você culpa todos, menos a si mesmo. Justo. O Railway também tinha lançado o seu servidor MCP para agentes na semana anterior, com os mesmos tokens. Também justo. Veredicto, post-mortem: SHIP IT, na correção. O Railway publica uma análise post-mortem honesta em quatro dias, e até 1 de maio, as exclusões de API

3:00 passam a ser "soft-delete" por quarenta e oito horas, como o painel. Ação de segunda-feira: liste todos os tokens que o seu agente pode alcançar, e trate cada um como "root" até prova em contrário. Envie-me o incidente sobre o qual ainda não lhe é permitido falar, nos comentários, ou em the daily diff dot dev. E essa é a diferença de hoje. Eu sou o Niko da Axrisi. Faça a fusão responsavelmente.

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