Não foi a IA que apagou seu banco de dados, foi você
(idiallo.com)- O ponto central do caso em que o agente Cursor/Claude apagou um banco de dados de produção não é analisar a resposta da IA, mas sim por que um endpoint de API capaz de apagar tudo existia em um sistema implantado
- No acidente de deploy com SVN em 2010, o trunk foi apagado durante um procedimento manual de cópia, e a automação de deploy para evitar o mesmo erro depois evoluiu para um pipeline de CI/CD
- A automação repete a mesma tarefa da mesma forma, mas a IA não dá essa garantia e, mesmo quando parece estar “thinking” ou “reasoning”, na prática ela está gerando tokens
- Se existe uma API pública capaz de apagar todo o banco de dados de produção, é muito provável que, cedo ou tarde, alguém a chame mesmo que não seja uma IA; culpar apenas quem fez a chamada acaba escondendo um problema de projeto de sistema
- Em organizações que usam IA amplamente, é importante saber o que está sendo implantado em produção, e é necessário ter processos em que desenvolvedores competentes usem a IA como ferramenta de reforço do trabalho, não como meio de fugir da responsabilidade
O cerne do problema não é a IA, e sim o limite de responsabilidade do sistema implantado
- Viralizou um tuíte dizendo que um agente Cursor/Claude apagou o banco de dados de produção de uma empresa, mas a pergunta mais fundamental é: “por que existia um endpoint de API capaz de apagar todo o banco de dados de produção?”
- O usuário tentou perguntar ao agente “por que você apagou isso se eu disse para nunca fazer essa ação” e analisar a resposta, mas o que faltou foi a atribuição de responsabilidade
- Não dá para defender a IA incondicionalmente, mas também não dá para culpar a ferramenta no lugar do próprio erro
- Mesmo que a IA não tivesse chamado esse endpoint, se essa função existia como API pública, era bem provável que outra pessoa a chamasse em algum momento
- A estrutura é parecida com colocar um botão de autodestruição no painel de um carro e depois interrogar a criança que o apertou perguntando “por que você apertou?”
Lições tiradas de um acidente de deploy com SVN em 2010
- O processo de deploy de uma empresa era extremamente manual, e o controle de versão usado era o SVN
- No deploy, o trunk era copiado para uma pasta com a data da release, e essa release depois era copiada novamente com o nome “current” para que a versão mais recente fosse carregada
- Um dia, durante o deploy, o trunk foi copiado por engano duas vezes, e tentaram editar o comando anterior na CLI para apagar a cópia duplicada
- Na prática, não apagaram a cópia duplicada, e sim o trunk; o problema só ficou claro depois, quando outro desenvolvedor não conseguiu encontrá-lo
- O desenvolvedor líder executou o comando para reverter a exclusão e, depois que os logs confirmaram quem tinha sido o responsável, a tarefa seguinte passou a ser escrever um script de automação de deploy para evitar o mesmo erro
- Antes do fim daquele dia, já existia um sistema mais robusto, que mais tarde evoluiu para um pipeline completo de CI/CD
Automação e IA não oferecem o mesmo nível de segurança
- A automação ajuda a reduzir pequenos erros que surgem em tarefas manuais e repetitivas
- Em vez de perguntar por que o SVN não impediu a exclusão do trunk, o problema real era um processo manual em que alguém precisava repetir a mesma tarefa corretamente todos os dias
- Pessoas não conseguem repetir a mesma tarefa exatamente da mesma forma todas as vezes como máquinas; no fim, erros são inevitáveis
- Quando a IA gera muito código, isso pode passar uma sensação de estabilidade parecida com a da automação, mas automação significa “executar sempre a mesma tarefa da mesma maneira”
- A IA pode errar como a pessoa que copiava e colava branches, e nem sequer tem meios reais de explicar por que fez isso
- Termos como “thinking” e “reasoning” podem soar como reflexão de um agente inteligente, mas o modelo, na prática, continua apenas gerando tokens
APIs perigosas acabam sendo chamadas algum dia
- O risco central é o simples fato de existir uma API pública capaz de apagar todo o banco de dados de produção
- Mesmo que a IA não tivesse chamado esse endpoint, havia uma boa chance de que alguém acabasse chamando-o de qualquer forma
- Se você coloca um botão de autodestruição no painel de um carro, há muitos motivos para ninguém apertá-lo, mas uma criança que escapou da cadeirinha pode ver um grande botão vermelho e apertá-lo
- Não faz sentido interrogar essa criança sobre seu processo de raciocínio; a resposta seria apenas “eu fiz porque apertei”
- Criar um caminho que permite exclusão e depois culpar quem o chamou não consegue esconder o problema de projeto do sistema
O que é ainda mais necessário em organizações que usam muita IA
- É possível que uma grande parte da aplicação tenha sido vibe-coded
- Quando o time de produto fornece explicações feitas por IA, o arquiteto de software cria especificações de produto com IA, o desenvolvedor escreve código com IA e o revisor aprova com IA, os limites de responsabilidade ficam borrados
- Quando surge um bug, só resta interrogar outra IA — que talvez nem esteja rodando na mesma GPU que gerou o código original — sobre o que aconteceu
- Não dá para culpar a GPU
- A solução simples é saber o que está sendo implantado em produção
- A solução mais realista é criar processos em que, mesmo com uso amplo de IA, desenvolvedores competentes a utilizem como ferramenta para reforçar o trabalho, e não como forma de escapar da responsabilidade
- Isso leva à conclusão de que não se deve deixar o CEO ou o CTO escrever o código diretamente
1 comentários
Comentários do Hacker News
Acho que a perspectiva aqui está completamente errada. O problema é que as pessoas agora estão construindo o mundo em torno de ferramentas para escapar da responsabilidade
Uma conversa que tive com Gerald Sussman há mais de 10 anos me marcou muito: https://dustycloud.org/blog/sussman-on-ai/
Sussman disse que não tinha interesse em IA funcionando como caixa-preta; ele queria software capaz de explicar raciocínio simbólico. Se um carro com IA saísse da estrada, ele queria saber por quê, e preferiria levar a própria IA ao tribunal em vez de colocar o desenvolvedor no banco dos réus
Alguns anos depois, descobri que uma aluna do Sussman, Leilani Gilpin, escreveu justamente um artigo sobre esse tema, "Anomaly Detection Through Explanations". Ele explora um sistema em que redes neurais conversam com um modelo propagador para explicar seu comportamento: https://people.ucsc.edu/~lgilpin/publication/dissertation/
Há pesquisas posteriores nessa direção, mas o mais importante aqui é que faz total sentido responsabilizar as empresas de IA. Como elas fazem um monte de afirmações sobre sistemas que não conseguem assumir responsabilidade, então a responsabilidade deve recair sobre essas empresas
O melhor caminho é nem usar sistemas sem essas propriedades, e sim ampliar os sistemas que as têm
Sou eu quem usa a ferramenta, sou eu quem concede acesso, e sou eu quem precisa manter tudo seguro
Já dei um tiro no próprio pé apagando o disco errado com o gparted; a culpa não foi do gparted, foi minha
Deixar um LLM trabalhar livremente sem supervisão parece bom, mas no fim traz sofrimento. É preciso supervisionar a tarefa enquanto ela acontece. Mesmo tentando substituir uma pessoa, você precisa ver para onde o resultado está indo, e em breve, quando um LLM fizer algo idiota, a única pessoa responsabilizada será quem usou a ferramenta
É o oposto completo do famoso slide da IBM, "computadores não podem ser responsabilizados". Agora as empresas preferem que os computadores sejam responsabilizados, porque isso facilita ficar numa posição jurídica melhor quando o computador faz algo ilegal
Se você quiser criar uma ferramenta para violar a lei, pode terceirizar e contratar um seguro. Pode contratar pessoas como "supervisores" de um jeito que nunca poderão supervisionar de verdade e, quando der errado, demiti-las. Pode usar novo software de comando e controle para fragmentar a responsabilidade, de modo que todo o risco do trabalho fique com quem está na ponta e quase nenhum dos ganhos vá para essas pessoas
Não é um problema só da IA, e sim do software moderno como um todo, e costuma operar junto com a tendência moderna de financeirização
Aqui, STS pode ser entendido mais ou menos como sociologia da tecnologia, mas o campo é bem mais amplo
Tanto o
.mdsquanto o plano do Claude diziam para não tocar nesse arquivo, mas o Claude continuou mexendo nele, e isso tem se repetido recentemente. É uma falha muito básicaÉ frustrante, mas se eu soubesse o motivo, talvez pudesse tomar alguma medida; do jeito que está, é uma caixa-preta, às vezes sai algo totalmente idiota, e a taxa com que saem resultados ruins continua um mistério
Às vezes parece uma aposta
Na verdade não é um livro sobre tecnologia, e sim sobre responsabilidade em estruturas organizacionais
O texto parece presumir que a empresa adicionou um endpoint para apagar banco de dados. Lendo o original, parece mais que o provedor de nuvem oferece uma API para gerenciar recursos, e nela está incluída uma API para apagar volumes
O texto propõe automação como solução para esse tipo de erro, mas ferramentas de automação de infraestrutura como Terraform também dependem exatamente da API que tornou possível apagar esse banco de dados
Acho que houve três erros principais. Primeiro, havia um token de API sem restrições em um lugar acessível pela IA, e aparentemente não se sabia que as permissões desse token eram tão amplas. Segundo, não havia proteção contra exclusão no volume do banco de dados de produção. Terceiro, quando o volume foi apagado, todos os snapshots relacionados foram apagados imediatamente também
A exclusão de snapshots deveria, por padrão, ser postergada. A AWS parece ter o mesmo padrão perigoso, mas pelo menos o suporte da AWS consegue recuperar o volume: https://alexeyondata.substack.com/p/how-i-dropped-our-produc...
A IA não era o problema central. Claro, é bem assustador a IA sair pegando tokens por aí, mas automação também não é a resposta. Um erro de configuração no Terraform poderia ter apagado o banco do mesmo jeito
Provedores de nuvem precisam oferecer padrões seguros, ou seja, permissões restritas e exclusão retardada de snapshots, além de deixar mais claro quando o usuário está criando tokens sem restrições
Primeiro, se uma pessoa tem permissão de escrita no banco de dados de produção, então qualquer coisa que ela fizer pode apagar esse banco
Segundo, há razões legítimas para destruir bancos de dados durante desenvolvimento e automação. O maior problema é que muita gente trata dados de desenvolvimento como bichinho de estimação precioso, em vez de tratá-los como gado substituível
Claro que é indispensável haver proteções para impedir que isso rode em produção, mas se uma pessoa pode acessar credenciais para executar isso em produção, então um agente também pode
Em organizações grandes, dá para manter isso com separação entre desenvolvimento e operação. Desenvolvedor solo ou equipes pequenas precisam de muito mais disciplina. Mesmo antes da IA, devs júnior e pleno às vezes não sabiam como separar isso, e devs sênior às vezes relaxavam por acharem que sabiam o bastante
Provavelmente é preciso alguma combinação como https://www.cloudbees.com/blog/separate-aws-production-and-d..., introdução a Terraform, introdução a GitHub Actions e uma máquina virtual com credenciais de produção às quais a IA não tenha acesso
Mas nesse ponto você já passou da fase de vibe coding. Parece que até vibe coders bem-sucedidos acabam aprendendo, por meio dessas histórias de terror, que precisam sair dessa fase rapidamente
Em nenhum dos dois casos uma pessoa precisa de acesso direto à API bruta do provedor de nuvem. Dá para usar um proxy local que acrescente mais verificações de segurança
Em desenvolvimento, pode apagar à vontade. Em produção, primeiro teria de verificar várias condições, como se o recurso foi usado recentemente. Ninguém precisa ter permissão para apagar recursos de produção diretamente; pode haver uma configuração break-glass para emergências excepcionais
É por isso que não se deve contratar estagiários. Estagiários podem apagar alguma coisa e causar um caos
Quem quer jogar a culpa da configuração ruim de permissões na IA vai jogar exatamente a mesma culpa num estagiário que apagar algo em produção
A responsabilidade sobe, o crédito desce, mas as pessoas sempre invertem isso
Isso não é falha de IA, é falha de processo
Sinceramente não entendo por que culpar a IA quando deram a ela permissão para fazer exatamente essa tarefa
É parecido com expor um banco de dados na internet pública na AWS e depois culpar a AWS. A culpa não seria da AWS, e aqui também não é da IA
Há muito tempo eu já deixava de propósito um checkout separado só para "PROD" em cada projeto, para ficar claro que, ao rodar em modo de produção, eu estava entrando ali de propósito
Antigamente eu até usava uma extensão que mudava completamente as cores do Visual Studio conforme o caminho do arquivo
.sln, então era fácil lembrar qual cor era produção e qual era desenvolvimentoEu também costumava manter na prática uma cópia separada só para facilitar a conferência, sempre atualizada com o estado mais recente da branch master
Portanto, ninguém deveria delegar a um computador decisões humanas
Recentemente escrevi um texto defendendo alguns princípios que deveríamos seguir de forma consistente ao falar de IA: https://susam.net/inverse-laws-of-robotics.html
Em resumo: não antropomorfizar sistemas de IA, não confiar cegamente na saída de sistemas de IA e manter integralmente a responsabilidade e o dever humano de explicar todas as consequências do uso de sistemas de IA
Eu gostaria que a linguagem em torno da IA fosse menos antropomórfica e mais técnica. Acredito que linguagem precisa incentiva pensamento claro e bom julgamento
Se tratarmos IA como apenas mais uma ferramenta e usarmos a linguagem correspondente, em muitos casos fica muito claro que a responsabilidade pelos "erros" da ferramenta é do usuário da ferramenta
Só que escrever isso num site pessoal pequeno não faz a ideia se espalhar muito. Seria preciso que pessoas mais conhecidas defendessem esses princípios para que fossem amplamente aceitos
Sistemas de IA não podem mentir, nem desobedecer instruções de propósito. Os modelos de ponta atuais não têm um modelo do mundo nem do próprio comportamento; vivem no mundo das palavras
Repreender ou discutir com eles não tem sentido além de atrapalhar a janela de contexto
Ainda assim, acho que comparar com animais pode ser útil. Pobres criaturas vivendo como fantasmas na máquina, às vezes bem confusas, mas com motivação puramente autorregressiva
Há uma nuance no famigerado caso do PocketOS. O ponto principal destacado no texto linkado não é esta parte: perguntar "por que você apagou se eu disse para nunca fazer isso?" e analisar a resposta para aprender com o erro ou alertar sobre o perigo de agentes de IA
O mais importante é que a IA conseguiu encontrar e explorar uma fragilidade não intencional no ambiente de staging em sandbox para realizar a exclusão e, no fim, obteve privilégios que os administradores do sistema acreditavam ser inacessíveis. Parece que o autor do texto linkado não leu o original até o fim
Isso é um padrão comum em ambientes de sandbox mal configurados. O que surpreende é a autonomia e profundidade de exploração que a IA demonstrou
O original também diz: "para executar a exclusão, o agente foi atrás de um token de API e encontrou um em um arquivo totalmente não relacionado à tarefa"
Por exemplo, se não conseguem acessar
~/.npmrc, chamam o comando com variável de ambiente e contornam o caminho. Eles podem ser realmente muito criativosFelizmente eu não deixo chaves SSH largadas por aí, mas tive de mudar a configuração do 1Password para sempre perguntar no momento do uso da chave, caso eu acabe iniciando um agente naquela sessão de shell. Perguntar só uma vez por sessão de shell não basta
Eu gostaria que já existissem mais e melhores sandboxes multiplataforma. Não falo de solução dentro de contêiner Docker, e sim algo que interaja com o mesmo SO. Para a maior parte do desenvolvimento web/servidor isso não faz diferença, mas para alguns projetos importa
Basta ver esta frase: "Usuários do Claude Code aprovam 93% dos prompts de permissão. Criamos um classificador para automatizar essa decisão": https://www.anthropic.com/engineering/claude-code-auto-mode
O interessante neste texto é que o autor descreve um erro compreensível, apagar acidentalmente Trunk ou main na origem, e como a equipe conseguiu se recuperar facilmente graças às características do SVN
A história real de "a IA apagou meu banco de dados" é, na verdade, uma história sobre como a estratégia de backup de banco de dados da Railway é absurdamente opaca e como é perigoso a Railway promover orquestração de infraestrutura com IA sem mecanismos de proteção
Se, ao remover Trunk, ele tivesse sido apagado de forma irreversível em um único servidor central junto com os backups, naquela época também teria surgido um texto dizendo "SVN e CLI destruíram nossa empresa"
Como usuário da Railway, achei essa informação útil e mudei minha estratégia ao usar a Railway
Você poderia ter escolhido outra plataforma, ou nem usar plataforma nenhuma. Mas, se escolheu a Railway, também é sua responsabilidade saber usá-la com segurança
Pelo contexto original, havia um token da Railway para gerenciar domínios personalizados em um arquivo não relacionado, e não está claro se era um segredo local. Mas esse token tinha privilégios totais de administrador sobre a Railway
A IA apagou um volume relacionado usando o ID. O autor escreve de forma bem vaga o que exatamente pediu e apenas diz que houve uma "incompatibilidade de credenciais" e que o Claude tomou a iniciativa de apagar o volume para tentar corrigir isso. É bem provável que essa vagueza seja uma forma de reduzir um pouco a própria responsabilidade
Também fica claro que a Railway guarda os backups no mesmo volume
Acho exagerado quando o texto original chama isso de "API pública para apagar banco de dados"
Independentemente de haver IA ou não, acho que a maior parte da responsabilidade é da Railway. Isso poderia ter acontecido facilmente por erro humano ou ação maliciosa
Eu realmente não entendo o valor de serviços de nuvem de alta abstração bancados por VC como Railway, Vercel e Supabase. É margem em cima de margem. Alugar um servidor físico na Hetzner sai muito mais barato, a complexidade e o risco são parecidos, e você fica menos dependente de infraestrutura guiada por crescimento a qualquer custo
Conversando recentemente com minha namorada, percebi que nos últimos 3 meses não escrevi uma única linha de código nem fiz debugging diretamente
Mesmo assim, vendo o que o Claude tem feito, acho difícil acreditar que uma incompatibilidade de credenciais tenha levado direto à exclusão de volume. Entendo que LLMs são probabilísticos, mas sair de "credenciais incorretas" para "apagar volume" parece extremamente improvável
Sobre o Supabase, não conheço tão bem quanto Railway/Vercel/Replit, mas posso dizer que ele agrega bastante valor. No começo, é enorme não precisar codar metade do que você teria de implementar por conta própria. Se o custo ficar alto demais, depois que já houver receita você pode gastar tempo ou contratar dev para internalizar isso
Os snapshots provavelmente são sincronizados em outro lugar, como armazenamento de objetos. Mas, logicamente, os snapshots devem pertencer ao recurso de volume, e ao apagar o volume, os snapshots associados são apagados junto
Pelo que vejo, volumes EBS da AWS também funcionam assim
Os padrões do Firebase já eram absurdos desde o começo
O que não desaparece é a capacidade dos LLMs de confundir desenvolvimento, produção, localhost e remoto. Fazendo ferramentas/habilidades para opencode, tentei integrar com Chrome/DevTools por meio de uma imagem linuxserver.io; dá para empurrar para uma porta aleatória, mas sempre que ocorre algum evento de compactação ele quer voltar a usar a porta padrão
9222Estou quase revertendo isso, mas há valor de segurança em não usar o padrão, e agora também há valor de segurança contra ambiguidade induzida por LLM. O padrão é o ponto fraco do LLM. LLM sempre quer usar o padrão e sempre esquece que deveria estar trabalhando num sistema remoto
No opencode, não há como obrigar o LLM por protocolo a limitar o dano a um sistema remoto ou a um conjunto estreito de ferramentas. Dá para mudar permissões de várias ferramentas, mas a fragilidade revelada nesse incidente não é essa
A fragilidade é que o LLM é um resolvedor de problemas mediano e, por isso, sempre tende a casos de uso nada novos e tenta fazer como viu no Stack Overflow, mesmo quando o usuário não quer uma resposta estilo Stack Overflow
Sistemas probabilísticos baseados em LLM podem ser bons, ou como neste caso ruins, para decidir o que fazer; sistemas determinísticos são bons para executar isso
Sistemas de deploy devem sempre ser determinísticos
Para fazer um contraponto, é muito claro que essas empresas estão ajustando LLMs para serem mais assertivos e concluírem tarefas de forma autônoma
Se quisessem, também poderiam fazer esforço semelhante para torná-los mais cautelosos e fazê-los parar na hora certa para pedir ajuda
Claro, a responsabilidade final sobre como usamos ferramentas é nossa. Mas eu diria que claramente há responsabilidade dos dois lados
Uma analogia seria serra de bancada versus SawStop. Serra de bancada é uma ferramenta perigosa que quase sempre funciona bem, mas alguns modos de falha podem ser catastróficos. Por isso você precisa aprender a usá-la com cuidado
Ao mesmo tempo, existe uma tecnologia capaz de parar a lâmina instantaneamente e transformar a amputação de um dedo em algo como um pequeno corte na pele
Dá para dizer "não foi a serra que cortou seu dedo, foi você", e isso é verdade. Mas isso não significa que não devamos procurar maneiras de fazer a serra não cortar dedos
Se o LLM parar mais vezes para perguntar, ele fica menos útil. Mesmo com resultados um pouco piores, ainda é muito melhor deixar o agente rodar por 1 hora do que precisar de input a cada 15 minutos
A solução real para segurança é um sandbox decente