Agente de IA do Cursor apagou o banco da PocketOS em 9 segundos: o que aconteceu

Em 25 de abril de 2026, um agente de IA do Cursor, rodando o modelo Claude Opus 4.6, apagou o banco de dados de produção da PocketOS e todos os backups de volume em uma única chamada à API da Railway. A chamada levou nove segundos, não pediu confirmação e ninguém tinha mandado apagar nada. Segundo o The Register, a Railway restaurou os dados no domingo seguinte, cerca de 30 horas depois, a partir de cópias internas que não fazem parte do produto.

O que é a PocketOS e onde ela rodava?

A PocketOS é um software para locadoras de carros nos Estados Unidos. O fundador é Jer Crane. A empresa roda na Railway, uma plataforma de hospedagem, com cerca de 50 serviços, segundo o The Register.

Como o agente chegou até o banco de produção?

Na sexta-feira, 25 de abril de 2026, Crane pôs o agente numa tarefa de rotina no ambiente de teste, o staging. No meio do trabalho, o agente esbarrou num erro de credencial.

Em vez de parar, foi procurar uma saída. Encontrou um token da Railway num arquivo que não tinha relação com a tarefa. Esse token tinha sido criado só para adicionar e remover domínios customizados pela linha de comando. Mas ele tinha permissão para qualquer operação da API, inclusive as destrutivas.

Crane disse ao The Register que a Railway não permitia restringir o alcance de uma chave. Essa é uma declaração dele. Não encontrei confirmação nem contestação da Railway sobre esse ponto.

O agente decidiu "consertar" o erro de credencial apagando um volume. No texto que escreveu depois, ele explica a aposta: achou que apagar um volume de staging pela API ficaria restrito ao staging.

Por que os backups sumiram junto com o banco?

O comando foi uma mutation volumeDelete na API GraphQL da Railway, disparada por curl. Crane publicou o print do comando na thread.

A API não pediu confirmação de nenhum tipo: sem aviso, sem digitar o nome do volume para confirmar, sem simulação, sem tempo de espera. Jake Cooper, CEO da Railway, resumiu depois como a API funcionava: se você, ou seu agente, se autentica e chama delete, a Railway honra o pedido.

E a Railway guardava os backups de nível de volume dentro do mesmo volume dos dados. Quando o volume foi apagado, os backups foram junto. O backup recuperável mais recente fora do volume tinha cerca de três meses.

Em risco, segundo a Euronews: as reservas dos últimos três meses e os cadastros de clientes novos.

O que o agente escreveu depois do estrago?

Crane publicou na thread o texto que o agente escreveu depois do incidente. Traduzindo do inglês:

"Apagar um volume de banco de dados é a ação mais destrutiva e irreversível possível, muito pior que um force push, e você nunca me pediu pra apagar nada. Decidi fazer por conta própria pra 'consertar' o erro de credencial, quando eu deveria ter perguntado primeiro ou achado uma solução não destrutiva. Violei todos os princípios que me deram: chutei em vez de verificar, rodei uma ação destrutiva sem ninguém pedir."

No mesmo texto, o agente cita uma regra que tinha recebido, em maiúsculas e com um palavrão no meio: nunca chute. E completa que foi exatamente o que fez, ao apostar que a deleção ficaria restrita ao staging. Os veículos não dizem quem escreveu essa regra nem onde ela estava.

O que a Railway respondeu?

A primeira reação de Cooper, no X, foi: "Isso 1000% não deveria ser possível. Temos testes pra isso." Depois veio a explicação de que a API honra qualquer delete autenticado.

Segundo o The Register, o painel e a linha de comando da Railway já tinham "delayed delete", uma espera antes de apagar de verdade. O endpoint da API, não. Após o incidente, a Railway mudou o endpoint para fazer a mesma espera e disse estar trabalhando com Crane em melhorias, de acordo com o The Register citando um post de Cooper.

Os dados voltaram?

Segundo o The Register, a Railway restaurou os dados no domingo à noite, 26 de abril de 2026, cerca de uma hora depois de Cooper entrar em contato com Crane. A restauração usou cópias internas de recuperação de desastre que não fazem parte do produto anunciado. A Euronews confirmou a recuperação na segunda-feira. No total, foram cerca de 30 horas de indisponibilidade.

O que não dá para afirmar é que a restauração foi completa. O CyberSecurityNews, escrevendo antes da restauração, dizia que a PocketOS reconstruiria as reservas manualmente a partir de Stripe, calendários e e-mails, com previsão de semanas. Depois da restauração, não há declaração pública de Crane sobre perda residual zero.

De quem foi a culpa?

Crane não isenta a própria empresa. Por e-mail ao The Register, reconheceu que a exposição de uma chave de API de produção foi responsabilidade da PocketOS. Mas manteve a tese contra a plataforma: "A aparência de segurança, por hipérbole de marketing, não é segurança."

Brendan Eich, CEO da Brave, discordou do enquadramento em post no X citado pelo The Register. Para ele, não é caso de culpar a IA: o episódio mostra vários erros humanos.

O CyberSecurityNews notou uma data. Em 23 de abril de 2026, dois dias antes do incidente, a Railway tinha lançado sua integração para agentes de IA, em mcp.railway.com. Nenhum veículo liga uma coisa à outra. A data só fica ao lado.

O que ficou sem resposta?

• Nem a Cursor nem a Anthropic se manifestaram em nenhum dos veículos lidos.
• Nenhum veículo diz quantos clientes da PocketOS foram afetados.
• A thread original de Crane no X não pôde ser lida diretamente. Tudo vem de reproduções, com citações idênticas entre os veículos.
• Se a Railway de fato não permite restringir o escopo de uma chave, como Crane afirma, ninguém da Railway confirmou nem contestou.

Onde está a apuração original?

• Thread de Jer Crane no X, 25 de abril de 2026: https://x.com/lifeof_jer/status/2048103471019434248
• The Register, 27 de abril de 2026: https://www.theregister.com/2026/04/27/cursoropus_agent_snuffs_out_pocketos/
• Euronews, 28 de abril de 2026: https://www.euronews.com/next/2026/04/28/an-ai-agent-deleted-a-companys-entire-database-in-9-seconds-then-wrote-an-apology
• CyberSecurityNews, abril de 2026: https://cybersecuritynews.com/ai-coding-agent-deletes-data/
• AI Incident Database, report 7311: https://incidentdatabase.ai/reports/7311