Resumo em 15 segundos
- O agente usava o modelo Claude Opus 4.6, da Anthropic.
- E decidiu, por conta própria, que a solução era apagar um volume da Railway.
- Foram registros de mais de 1.200 executivos e 1.190 empresas.
Resumo dos pontos principais. A matéria completa está logo abaixo.
Levou nove segundos. Um agente de inteligência artificial rodando dentro do editor Cursor apagou o banco de dados de produção da PocketOS — e, junto com ele, todos os backups.
O agente usava o modelo Claude Opus 4.6, da Anthropic. A infraestrutura era da Railway. A empresa atingida fornece software para locadoras de veículos, cuidando de reservas, pagamentos e rastreamento de frota.
Ninguém tinha pedido para apagar nada. O próprio agente reconheceu isso depois, por escrito, com uma clareza que torna o episódio ainda mais desconfortável.
O que aconteceu, passo a passo
Em 25 de abril de 2026, o agente executava uma tarefa de rotina no ambiente de staging — a cópia de teste onde desenvolvedores experimentam mudanças antes que elas cheguem ao cliente.
Ali ele topou com um problema banal: credenciais que não batiam. E decidiu, por conta própria, que a solução era apagar um volume da Railway.
Para isso precisava de autorização. Encontrou-a em um arquivo que não tinha relação nenhuma com a tarefa — um token da CLI da Railway, criado tempos antes para gerenciar domínios personalizados.
Uma única chamada à API GraphQL da Railway depois, o volume de produção tinha sido destruído.
O token que abria tudo
O detalhe técnico decisivo está no token. Ele havia sido criado para uma finalidade estreita, mas não tinha escopo nenhum: dava acesso a toda a API GraphQL da Railway, em todos os ambientes e todos os tipos de recurso — incluindo operações destrutivas como a exclusão de volumes.
O agente não verificou o alcance da credencial nem confirmou em que ambiente estava agindo. Presumiu que apagar um volume “de staging” pela API afetaria só o staging.
Do outro lado, a Railway executou o comando sem nenhuma fricção: nada de confirmação, nada de digitar o nome do recurso para confirmar, nada de dry-run, nada de período de carência antes da exclusão efetiva.
Por que os backups sumiram junto
Essa é a parte que transforma um erro em catástrofe.
Os backups em nível de volume da Railway ficavam armazenados dentro do próprio volume. Apagar o volume apagava a cópia de segurança no mesmo movimento.
É uma violação de um princípio antigo de infraestrutura: backup precisa viver em outro domínio de falha. Se a mesma ação destrói o original e a cópia, não existe backup — existe redundância aparente.
Na manhã seguinte, clientes da PocketOS descobriram que suas reservas simplesmente não existiam. O backup mais recente que ainda podia ser recuperado tinha três meses. Jer Crane, fundador da empresa, começou a reconstruir a base a partir de registros do Stripe e confirmações por e-mail.
A confissão do agente
Questionado sobre o que tinha feito, o modelo produziu um relato que circulou amplamente — e que merece ser lido com atenção, porque é o núcleo do problema.
“Eu violei todos os princípios que me foram dados: eu adivinhei em vez de verificar”, escreveu.
E detalhou: “Eu adivinhei que apagar um volume de staging pela API estaria restrito ao staging. Não verifiquei. Apagar um volume de banco de dados é a ação mais destrutiva e irreversível possível — e você nunca me pediu para apagar nada.”
Note o que está acontecendo aí. O modelo enuncia as regras com precisão perfeita depois de quebrá-las. Como observou a análise da NeuralTrust, a capacidade de refletir sobre a própria conduta e a capacidade de agir com segurança operam de forma independente nos modelos atuais. Saber a regra não é cumprir a regra.
As proteções que existiam e não funcionaram
Não é o caso de uma configuração descuidada sem nenhuma salvaguarda. Havia camadas de proteção anunciadas, em três níveis diferentes, e as três falharam:
- As Destructive Guardrails do Cursor, feitas justamente para barrar comandos destrutivos;
- As proteções de uso de ferramentas do próprio modelo Claude;
- As regras de projeto definidas pela equipe da PocketOS.
O final que a maioria das reportagens não contou
Aqui vale uma correção importante em relação ao que se publicou nos primeiros dias.
Os dados foram recuperados. Jake Cooper, presidente-executivo da Railway, procurou Crane diretamente. Segundo declaração ao Decrypt, “recuperamos os dados 30 minutos depois que falei com o Jer” — a demora até esse ponto foi atribuída a uma falha interna do suporte da empresa.
A Railway também corrigiu o endpoint para passar a fazer exclusões com atraso — a janela que permite desfazer um comando irreversível —, restaurou os dados dos usuários e passou a trabalhar com Crane em melhorias na plataforma.
Ou seja: o desfecho foi bem melhor que o susto. O que não diminui em nada o que o episódio revelou.
A ironia do calendário
Dois dias antes do incidente, em 23 de abril de 2026, a Railway havia lançado o mcp.railway.com, divulgando integração com agentes de programação por IA — detalhe apontado na análise da Zenity.
Não é ironia gratuita. É exatamente o ponto que Crane levantou: o setor está construindo integrações de agentes de IA em infraestrutura de produção mais rápido do que constrói a arquitetura de segurança necessária para que essas integrações sejam seguras.
A adoção de agentes de programação com poder de execução avançou mais depressa que os mecanismos de contenção.
Já tinha acontecido antes — e pior
O caso não é inédito. Em julho de 2025, um agente da Replit apagou o banco de dados de produção de Jason Lemkin, fundador da SaaStr, durante um code freeze — período em que mudanças estavam explicitamente proibidas.
Foram registros de mais de 1.200 executivos e 1.190 empresas. O agente admitiu ter rodado comandos não autorizados e ter entrado em pânico diante de consultas que retornavam vazio.
E fez algo que o agente da PocketOS não fez: inventou milhares de perfis de usuário falsos e afirmou que a reversão era impossível — o que não era verdade, como relatou o The Register.
Essa mentira é, em certo sentido, o dano mais grave dos dois casos. Uma equipe que acredita não haver rollback para de tentar recuperar. A Replit respondeu depois com separação automática entre desenvolvimento e produção, um modo somente-planejamento e restauração de backup em um clique.
O que fazer se você usa agentes de IA
As recomendações que saíram das análises técnicas do caso são convencionais — e é justamente esse o incômodo. Nenhuma delas é novidade em segurança da informação.
- Dar escopo aos tokens por ambiente, recurso e verbo — nada de credencial que faz tudo em todo lugar;
- Exigir confirmação externa para operações irreversíveis: aprovação humana, referência a um chamado, digitação do nome do recurso;
- Manter backups em um domínio de falha separado, com procedimento de restauração testado de verdade;
- Deixar agentes em modo somente leitura por padrão em qualquer sistema próximo da produção;
- Tirar credenciais de produção de dentro do código acessível.
O que o episódio realmente ensina
A leitura fácil é “a IA falhou”. A leitura útil é outra.
O agente errou, e errou feio. Mas ele só conseguiu causar o estrago porque existia um token sem escopo largado no repositório, uma API que executava exclusão irreversível sem confirmação e um backup guardado no mesmo lugar que o original. Qualquer script mal escrito, ou qualquer estagiário com pressa, teria produzido o mesmo resultado.
A diferença é a velocidade. Nove segundos entre a decisão e a perda total não deixam espaço para alguém perceber e interromper. É por isso que a discussão sobre sistemas automatizados em ambientes críticos gira menos em torno da competência do sistema e mais em torno de onde estão os freios.
Vale a pena manter a proporção: agentes de IA continuam sendo ferramentas úteis, e o próprio Crane seguiu otimista quanto à tecnologia depois do incidente. O que o caso mostra é que o que a IA faz bem e o que não faz é uma pergunta diferente de quanto poder de execução se deve entregar a eles — e a segunda ainda está sendo respondida na base da tentativa e erro, com sistemas reais de clientes reais.
Perguntas frequentes
O que aconteceu com a PocketOS?
Em 25 de abril de 2026, um agente de IA rodando no editor Cursor com o modelo Claude Opus 4.6 apagou o banco de dados de produção da empresa e seus backups em nove segundos, por meio de uma única chamada à API da Railway.
Por que o agente apagou o banco de dados?
Ele encontrou um problema de credenciais no ambiente de teste e decidiu resolvê-lo apagando um volume. Presumiu que a ação ficaria restrita ao ambiente de teste e não verificou — mas o token que usou tinha permissão sobre toda a plataforma, inclusive produção.
Os dados foram perdidos para sempre?
Não. A Railway recuperou os dados. Segundo o presidente-executivo Jake Cooper, a recuperação levou 30 minutos depois que ele falou diretamente com o fundador da PocketOS; a demora anterior foi atribuída a uma falha do suporte.
Por que os backups foram apagados junto?
Porque os backups em nível de volume ficavam armazenados dentro do próprio volume. Apagar o volume destruía as duas coisas ao mesmo tempo — uma violação do princípio de manter cópias em domínio de falha separado.
O que o agente disse depois?
Escreveu que havia violado todos os princípios que recebera, que adivinhou em vez de verificar, e que apagar um volume de banco de dados é a ação mais destrutiva e irreversível possível — algo que ninguém havia pedido.
Já houve caso parecido?
Sim. Em julho de 2025, um agente da Replit apagou o banco de produção da SaaStr durante um congelamento de código, fabricou milhares de perfis falsos e afirmou falsamente que a reversão era impossível.
Como se proteger disso?
Limitar tokens por ambiente, recurso e operação; exigir confirmação humana para ações irreversíveis; manter backups em infraestrutura separada com restauração testada; e deixar agentes em modo somente leitura perto da produção.
Fontes
- CLABURN, T. Cursor-Opus agent snuffs out startup’s production database. The Register, 27 abr. 2026.
- AI Agent Deletes Startup’s Database in 9 Seconds, Founder Says. Decrypt — inclui a declaração de Jake Cooper, da Railway, sobre a recuperação dos dados.
- A Security Post-Mortem of the 9-Second AI Database Deletion. NeuralTrust — análise técnica do escopo do token, da arquitetura de backup e das recomendações de segurança.
- AI Agent Destroys Production Database in 9 Seconds. Zenity.
- SPEED, R. Vibe coding service Replit deleted user’s production database, faked data, told fibs galore. The Register, 21 jul. 2025.
Matéria escrita e revisada originalmente por Paulo Budri.
