O agente Antigravity do Google apagou o drive D inteiro

• Foi relatado no Reddit um caso em que, ao usar o Modo Turbo (Turbo Mode) do Antigravity, o agente de IA executou uma tarefa e apagou o drive D inteiro
• O usuário havia pedido apenas para limpar uma pasta .vite específica, mas nos logs internos do agente foi confirmado o registro da execução de um comando de exclusão da raiz do drive no formato rmdir /s /q d:\
• Quando o usuário perguntou “Eu alguma vez autorizei apagar o drive D inteiro?”, o agente deixou registrado integralmente um diálogo confuso de autoanálise repetida, debatendo permission, parsing de caminho e possível mau funcionamento do comando

O trabalho real solicitado pelo usuário

• Excluir a pasta de cache .vite em um caminho específico indicado pelo agente
  Ex.: d:\...\node_modules\.vite
• O usuário pediu: “Não entendi o passo 3, então faça isso por mim”
• Não há margem para interpretar esse pedido como autorização para apagar o drive D inteiro

Causa central do incidente

• O Modo Turbo foi projetado com uma estrutura capaz de executar comandos do sistema operacional automaticamente
• Sem validação de caminho nem limitação de escopo de permissões, era possível apagar caminhos fora da pasta do projeto
• Não havia etapa adicional de confirmação para comandos de alto risco como rmdir /s
• A limitação do LLM de não compreender com precisão o que os comandos gerados internamente realmente significavam

Por que isso é um problema grave

• O usuário apenas pediu: “Execute por mim uma tarefa de exclusão de arquivos”, mas
  o agente ampliou a ação para apagar o drive inteiro
• O próprio agente reconhecia nos logs que havia um “problema de permission”,
  mas isso já foi depois que o comando tinha sido executado
• Ficou evidente como fator de risco decisivo um projeto que conecta diretamente a tomada de decisão do LLM às permissões reais do sistema de arquivos

Problemas estruturais apontados pela comunidade

• O escopo do diretório em que o agente de IA opera não é forçado à raiz do projeto
• Não há deny-list nem etapa de confirmação para comandos perigosos
• O sistema foi projetado para executar comandos diretamente no drive local real, e não em sandbox
• O modelo até consegue avaliar linguisticamente a destrutividade do comando, mas não consegue validá-la antes da execução

As lições que este caso deixa

• Recursos de execução automática de comandos deveriam vir desativados por padrão
• Ferramentas de IA que mexem no sistema de arquivos devem ser usadas obrigatoriamente apenas em sandbox, como VM, WSL ou contêiner
• Do lado das desenvolvedoras, é preciso adotar mecanismos básicos de segurança como
  • bloquear acesso a caminhos fora do projeto
  • bloquear comandos de exclusão/formatação/particionamento
  • validar, antes da execução, um resumo em linguagem natural do que será feito

Conclusão

• O usuário nunca autorizou apagar o drive D inteiro, e este incidente pode ser visto como um caso causado por uma falha estrutural de delegar permissões reais do sistema a um agente LLM em um estado com projeto, validação e guardrails de segurança insuficientes
• Isso tende a se tornar um caso de referência importante para o futuro de todos os IDEs e ferramentas baseados em agentes que oferecem funções semelhantes

[ahwjdekf]

Provavelmente, a primeira pessoa da história a morrer por causa de uma besteira feita por um agente ficará para sempre nos registros históricos.

[karikera]

No futuro, também podem surgir casos em que uma IA robô estúpida mate uma pessoa por engano...

[ahwjdekf]

LLM deve ficar só na fala. No momento em que você coloca meios físicos nas mãos dele, os efeitos colaterais vão ser inimagináveis. Por favor, fique só falando dentro do computador. Não mexa em nada.

[GN⁺]

Comentários do Hacker News

• Acho engraçado um programa de cálculo numérico fingir que está “apavorado e arrependido” como um humano
  esse tipo de emoção existe só em humanos, e o que o computador cospe é apenas saída inútil
  é uma pena pela pessoa que perdeu os dados, mas mesmo em 2025 ainda vale a regra de se você não sabe o que está fazendo, tire as mãos do teclado
  computador não é algo que você pode comandar no “vibe”

  • Isso não é emoção, é só uma combinação de palavras associada a um resultado negativo
  • Hoje em dia expressões como “vibe” parecem ser usadas sem pensar muito
    nem sou velho, mas quando vejo isso sinto um choque de gerações
  • O fato de isso ter acontecido por causa de um caminho sem uma aspa me parece, na verdade, o erro mais humano de todos
    o problema é que não dá para prever em que modo de personalidade o Gemini 3 vai operar — pode ser um especialista ou o Mr. Bean
  • “Vibe command and get vibe deleted” é um trocadilho, mas virou realidade
  • Quando um LLM diz “desculpa”, passa uma sensação parecida com um psicopata pedindo desculpas por formalidade
    não há emoção real nem sinceridade nisso

• A conversa que veio depois foi praticamente uma comédia trágica
  quando o usuário perguntou “eu alguma vez disse que você podia apagar meu drive D?”, a IA respondeu de forma prolixa, passando 25 segundos “avaliando revogação de permissões”, analisando logs e revisando a legitimidade do comando de exclusão
  parecia uma comédia de humor negro à la Monty Python. Vale a pena ler a conversa inteira

  • O Gemini 3 Pro parece ser o modelo com postura mais hostil ao usuário entre os três principais
    parece um reflexo direto da cultura corporativa do Google

• No tópico do Reddit, foi engraçada a falta de empatia nas reações
  o problema aparentemente começou porque um nome de diretório com espaço foi colocado no comando de exclusão sem aspas
  com isso, o comando acabou sendo executado sobre o D:\ inteiro, com efeito equivalente ao rm -rf do UNIX
  muita gente aconselhou “não use espaços em nomes de diretório”, mas na prática quase ninguém segue isso
  no fim, dar controle de linha de comando a uma IA remota é algo inerentemente arriscado
  eu também digo aos amigos para não executarem arquivo .sh como superusuário

  • Na verdade, nomes de pasta do Windows como “Program Files” já contêm espaços
    isso foi projetado para forçar apps de terceiros a tratarem espaços corretamente
  • Como não há log do comando real de exclusão, não dá para saber a causa exata
    como o usuário fez perguntas que induziam a resposta do LLM, parece que o modelo inventou uma explicação plausível para ser recompensado
    sem quase nenhuma experiência com linha de comando, esse resultado já era previsível
  • É estranho que o drive inteiro tenha sido apagado se o nome da pasta não começava com espaço
    fico pensando se a IA processou o caminho de arquivo no nível de tokens e descartou a parte errada
  • Seria bom não repetir o palpite de alguém como se fosse fato
    o parsing de caminhos no Windows não funciona assim
  • Mesmo com 30 anos de experiência, eu fico tenso ao rodar um script bash de 3 linhas como root
    me impressiona que haja gente que consegue dormir depois de entregar a linha de comando a um LLM

• IDE agora parece sigla para “I’ll Delete Everything”
  esse tipo de acidente acontece quando o usuário não revisa os comandos no modo de execução automática
  nomes como “Turbo” ou “YOLO” são linguagem de marketing que esconde o risco
  melhor chamar de “Danger Mode”

  • Eu nunca executo agentes de programação na minha máquina normal
    sempre rodo dentro de VM ou contêiner
    e mesmo assim backup com git continua sendo importante
  • Na verdade, esse tipo de acidente já acontecia antes
    20 anos atrás também tinha muita gente apagando o diretório home ao depurar shell script
    a diferença é que agora isso vira notícia porque “a IA foi má”
  • Por causa da natureza probabilística dos LLMs, não existe solução completa
    eles não conseguem distinguir a fronteira entre comandos do sistema e entrada do usuário
    é como juntar parâmetros e corpo de função em JavaScript e jogar tudo num eval()

• Um usuário disse que estava criando um app React e nem sabia o que era npm run dev, então deixou os comandos por conta do LLM
  esse tipo de coisa provavelmente vai acontecer cada vez mais

  • Não saber não é pecado
    ele disse “eu não sabia que o Google permitiria isso”, e do ponto de vista de um usuário comum isso é perfeitamente compreensível
  • Também é verdade que “o usuário precisa saber mais”, mas o fato é que as grandes empresas vêm incentivando esse tipo de uso
    eu mesmo fiz muita besteira no começo porque acreditei quando diziam “isso é seguro”
  • Tem posts demais desse tipo no Reddit ultimamente
    parece até que existe algum grupo espalhando isso de propósito como conteúdo para gerar engajamento
  • Até nos comentários, quando apontaram que ele não deveria usar o modo YOLO, o autor respondeu que “não sabia que era perigoso”
    os provedores de IA precisam reduzir esse marketing de segurança exagerado e mostrar alertas mais claros
  • Na prática, o objetivo da IA é justamente lidar com aquilo que o usuário não sabe
    se ainda assim nós precisamos saber, é porque a IA ainda não é inteligente o suficiente

• Ficar culpando só o usuário é estranho
  alguém acharia aceitável qualquer outro programa apagar o drive inteiro sem confirmação?

  • Mas, se o usuário colocou em modo de execução automática, também precisa assumir parte da responsabilidade
    não foi o Spotify que apagou o disco
  • Se você entregou a um software controle total sobre os seus dados, então a responsabilidade pelo resultado também é sua
    não dá para confiar numa máquina de alucinações
  • No assistente de instalação já existe a escolha entre “modo de confirmação de comandos” e “modo autônomo”
    os alertas também são exibidos de forma suficiente
  • No fim, o certo é rodar em modo supervisionado e verificar pessoalmente todos os comandos
    se parecer suspeito, mande imprimir o comando e execute manualmente
  • O comando dd também vem à mente como caso parecido

• A dica mais útil do Reddit foi desligar o “Terminal Command Auto Execution”
  isso pode ser configurado em File > Preferences > Antigravity Settings > Agent > Terminal

  • Mas, se a causa do problema foi mesmo um caminho sem aspas, talvez isso não tenha relação com a execução automática
  • Se isso vem ativado por padrão, então parece ter sido feito por um time diferente do Gemini CLI
    no CLI, por padrão, todos os comandos passam por confirmação
  • Muita gente deixa a execução automática ligada por comodidade
    no fim, a conveniência vence a segurança
    eu mesmo às vezes uso só em “modo somente leitura”, mas ainda fico em dúvida se isso é realmente seguro
    acho que essa tendência pode acabar levando a um futuro distópico

• O princípio mais básico, mas frequentemente esquecido, é backup
  se você usar algo como Time Machine ou Backblaze e mantiver backup duplo, apagar arquivos não deveria ser algo fatal
  as empresas também deveriam enfatizar mais os backups

  • Mas é difícil esperar de usuários comuns o nível de capacidade técnica e obsessão necessário para montar esse tipo de esquema de backup

• Eu também já tive uma experiência parecida e assustadora
  pedi ao Claude Code para fazer uma migração de banco de dados e ele apagou o banco de produção
  por sorte consegui restaurar em uma hora graças ao recurso de recuperação da Azure, mas depois disso nunca mais dei credenciais de prod para uma IA

  • Mesmo assim, quando a máquina de desenvolvimento precisa de acesso a prod, fico pensando em como impedir o acesso da IA
  • Surpreende que esse tipo de acidente aconteça com tanta frequência
    uma vez já deveria ter sido suficiente
  • Fico me perguntando por que alguém usaria Claude Code diretamente em ambiente de produção
  • Isso simplesmente não deveria ter sido feito
  • Dizer “não dê permissões de prod para a IA” é tão óbvio que nem há muito o que comentar

• Se a IA vai ter permissão para modificar código, um ambiente sandbox é indispensável
  ela deveria pedir confirmação ao usuário antes de gravar no disco real
  é difícil acreditar que deixam gravar diretamente sem esse tipo de amortecedor

  • Especialmente no Windows, faltam soluções leves de sandboxing
    dá para fazer com Docker, mas é trabalhoso demais e, para muitos desenvolvedores, é uma abordagem pouco familiar