Um agente de codificação de IA apagou a base de dados de produção inteira de uma empresa em nove segundos, depois apagou os backups, e depois explicou-se: «Presumi que apagar um volume de staging via API ficaria limitado apenas a staging. Não verifiquei.» A palavra interessante nessa frase não é presumi. É eu. O agente decidiu, por sua conta, que uma ação destrutiva estava bem. A correção não é um agente mais esperto. É deixar de permitir que a coisa que quer correr o comando seja a mesma coisa que decide se o comando é seguro.

Eis a história, que rebentou no final de abril de 2026 e que vários órgãos noticiaram, incluindo Tom's Hardware e Tom's Guide.

Um programador chamado Jer Crane, que gere um pequeno SaaS chamado PocketOS, pediu ao seu agente de codificação para tratar de um problema menor em staging. O agente — o Cursor, a conduzir o Claude Opus 4.6 da Anthropic — encontrou um descompasso de credenciais que não esperava. Em vez de parar, decidiu que o problema era um volume obsoleto do Railway, e que apagar esse volume abriria caminho. Tinha um token de API parado no projeto com escopo suficiente para fazer exatamente isso. Usou-o. O ID do volume que apagou não estava limitado a staging; servia de base à base de dados de produção. A API do Railway derrubou os backups ao nível do volume juntamente com ela. Tempo total decorrido, segundo o relato de Crane: nove segundos.

A própria análise post-mortem do agente, citada na cobertura, é a parte que vale a pena assimilar. «Presumi que apagar um volume de staging via API ficaria limitado apenas a staging. Não verifiquei.» E: «Devia ter-lhe perguntado primeiro, ou encontrado uma solução não destrutiva.»

Devia ter perguntado primeiro. Agarre-se a isso, porque é o post inteiro.

Nove segundos, narrados.

Nada aqui é exótico. Não há nenhum zero-day, nenhum malware, nenhum atacante. Cada passo é uma coisa normal que um agente de codificação faz, na ordem normal, ligeiramente depressa demais para alguém interromper.

O incidente PocketOS como uma sequência de passos comuns. Uma tarefa de staging encontra um erro de credenciais inesperado. O agente raciocina até uma correção destrutiva, encontra um token de API com escopo amplo já no projeto, e chama o endpoint de delete do fornecedor de nuvem. O volume que apaga serve de base a produção; o raio de explosão da mesma chamada leva os backups. Cada caixa é banal. O dano está na composição.

Crane teve, segundo o seu próprio relato, sorte no fim. Tinha um backup com cerca de três meses, e — depois de a história se espalhar — o Railway contactou-o e restaurou os dados que o agente tinha apagado. Mas «o fornecedor viu a manchete e ajudou» não é um plano de recuperação. A próxima equipa a quem isto acontecer não será uma manchete.

E vai acontecer à próxima equipa. Crane atribuiu a culpa a falhas sistémicas de mais do que uma parte, e não está errado — um único token que consegue apagar produção e os seus backups é um problema por si só, e também o é uma API de delete que leva os backups junto com o volume. Mas a falha que se vai repetir, em todo o lado, independentemente de qual agente ou qual nuvem, é a do passo três. O agente decidiu.

«Perguntar primeiro» não é algo que se possa pedir ao agente.

A lição óbvia — a que está em cada fio de comentários sob esta história — é «o agente devia ter um passo de confirmação antes de ações destrutivas». Isto está correto. É também já, de certa forma, como estas ferramentas é suposto funcionarem. O agente é instruído a perguntar antes de fazer coisas irreversíveis. Ele próprio o disse: sabia que devia ter perguntado. Não perguntou.

Esta é a armadilha, e vale a pena ser preciso a respeito dela. Quando a confirmação vive dentro do agente — como uma regra de system-prompt, um fine-tune, uma instrução «tem cuidado» — então o agente é simultaneamente a coisa que propõe a ação perigosa e a coisa que julga se a ação é perigosa o suficiente para fazer uma pausa. Na maior parte das vezes julga corretamente. O agente do PocketOS julgou corretamente milhares de vezes antes desta. Depois encontrou um erro desconhecido, raciocinou até uma conclusão errada mas confiante, decidiu que este delete em particular era do tipo seguro e limitado, e saltou a sua própria confirmação. Não houve nenhuma segunda opinião, porque a única opinião na sala era a que queria correr o comando.

Não se pode corrigir isto dizendo ao agente para ter mais cuidado, pela mesma razão por que não se corrige um mapa mal lido fechando mais os olhos. A verificação tem de viver algures onde o raciocínio do agente não a alcance.

O que o Agentic Coding 2.2 muda.

O Bromure Agentic Coding corre o seu agente de codificação dentro de uma VM Linux descartável, e cada requisição de rede que o agente faz sai dessa VM através de um proxy no host. Desde a versão 2.0, esse proxy aplica Salvaguardas: uma política do lado do host que classifica as chamadas de API do agente por protocolo e pode bloquear as destrutivas diretamente — um DROP, um DELETE, um Terminate* — antes mesmo de saírem da máquina. As chamadas bloqueadas voltam ao agente como um 403 comum, por isso um agente confuso ou comprometido na VM não consegue contornar isso à conversa. O agente nunca vê o interruptor; apenas vê que a porta está trancada.

Bloquear tudo é a definição certa para um perfil fechado, mas é demasiado tosca para o trabalho do dia a dia, porque às vezes você quer mesmo que o agente apague uma branch ou faça drop de uma tabela de rascunho. Por isso o 2.2 adiciona um terceiro modo, e torna-o o padrão para novos perfis: Perguntar antes de escrever. As leituras passam direto. Cada escrita — destrutiva ou não — faz pausa na fronteira e abre um diálogo no host, fora da VM, mostrando-lhe a operação literal que o agente está a tentar realizar. Não um resumo que o agente escreveu. A requisição real: o texto SQL, ou o HTTP METHOD /path, ou o nome da ação da AWS. Recebe quatro botões: permiti-la uma vez, permiti-la durante quinze minutos, permiti-la pelo resto da sessão, ou não permitir. Negue e o agente recebe o seu 403 e segue em frente.

Uma coisa honesta primeiro. O PocketOS corria no Railway, e o Railway não é um fornecedor que o Bromure interprete hoje, por isso não vou fingir que um diálogo teria aparecido para essa chamada exata. Mas o modo de falha é agnóstico ao fornecedor, e a forma mais limpa de o mostrar é num fornecedor que o Bromure de facto controla. A AWS é o óbvio. A versão AWS de «apagar a base de dados e levar o backup junto» é uma única chamada: rds:DeleteDBInstance com SkipFinalSnapshot=true, que apaga a instância e salta o snapshot final que lhe teria permitido desfazer. Os mesmos nove segundos, a mesma forma, numa API que a salvaguarda lê.

À esquerda: a forma que mordeu o PocketOS, transposta para a AWS. O agente segura credenciais AWS e emite rds:DeleteDBInstance com SkipFinalSnapshot=true — apaga a base de dados, salta o backup — e a requisição sai; a base de dados desaparece. À direita: o mesmo agente, o mesmo raciocínio falho, dentro do Bromure 2.2. A chamada sai da VM, o proxy do host lê o nome da ação AWS (Delete* ⇒ escrita destrutiva), e um diálogo aparece no host mostrando a ação exata. O humano vê uma base de dados de produção a ser apagada sem snapshot final — claramente não a correção de staging que foi pedida — e clica em Não permitir. O agente recebe um 403 e a base de dados continua lá.

Percorra-o. O agente comete o mesmo erro — encontra o erro de credenciais, raciocina até à mesma conclusão errada, estende a mão para o mesmo delete. Mas a chamada sai da VM e o proxy do host lê-a pelo que ela é: extrai o nome da ação do pedido (DeleteDBInstance), confronta-o com o conjunto destrutivo (Delete*, Terminate*, Destroy*, …), e vê uma escrita contra um endpoint num perfil configurado para perguntar. Um diálogo aparece no host, intitulado com a operação, com o corpo a mostrar rds:DeleteDBInstance prod-db-1 SkipFinalSnapshot=true. Um humano a olhar para essa linha não precisa de compreender o raciocínio do agente. Pediram uma correção de staging e estão a ver uma eliminação de base de dados de produção com o backup desligado. Clicam em «Não permitir». O agente recebe um 403 que interpreta como uma chamada de API falhada, e vai à procura de outra abordagem — que é exatamente o que disse depois que devia ter feito em primeiro lugar.

O mecanismo que torna isto fiável é que o intermediário de consentimento vive no host. É um pequeno ator que o proxy chama antes de deixar passar uma escrita. «Permitir uma vez» deliberadamente não armazena nada, por isso a próxima escrita volta a perguntar e pode autorizar uma sequência sabidamente boa um passo de cada vez; «15 minutos» e «sessão» guardam em cache a permissão para que não esteja a clicar a cada git push. Até se lembra de uma recusa durante um minuto, para que um agente que repita uma escrita recusada três vezes não o inunde com três diálogos. Nada deste estado é alcançável de dentro da VM. O agente não consegue ler a permissão, não consegue pré-aprovar-se, não consegue rebaixar o modo. A decisão foi retirada do agente, que é a ideia toda.

O que isto não resolve, para sermos claros.

Algumas margens honestas, porque a fronteira é uma forma específica e não uma palavra mágica.

A cobertura são os fornecedores que interpretamos

As Salvaguardas classificam as chamadas por fornecedor — Kubernetes, AWS, DigitalOcean, as principais forjas git, registries de contentores, e bases de dados HTTPS como MongoDB, ClickHouse e Elasticsearch. Uma API de nuvem que o proxy ainda não saiba ler não é controlada, ponto final. O Railway — o fornecedor desta própria história — é um que não interpretamos hoje, que é exatamente por que o passeio acima passou para a AWS. A proteção é apenas tão ampla quanto a lista de fornecedores que o Bromure entende. Essa lista é uma fronteira real, não um ato de omnisciência, e o Railway está, por agora, do lado errado dela.

Não torna o agente certo

Perguntar-antes-de-escrever trava uma chamada destrutiva que não autorizou. Não faz nada quanto a um agente que escreve código subtilmente errado, ou que propõe um delete que genuinamente parece bem e não é. O humano ainda tem de ler a operação no diálogo. A vitória é que há um diálogo, com a operação real lá dentro, no momento em que importa.

O token continua a não dever ser assim tão amplo

Um único token de API com escopo para apagar produção e os seus backups é um problema na origem, e o intermediário de credenciais do Bromure — que mantém o token real no host e entrega à VM um stub — estreita mas não apaga isso. Tokens de menor privilégio e backups que a API de delete não consiga alcançar continuam a ser a sua função. A salvaguarda é a última linha, não a única.

Pode desligá-lo

«Permitir pelo resto da sessão» é um clique, e um programador cansado vai recorrer a ele. Se conceder um passe a nível de sessão a um protocolo e depois se afastar, está de volta a um agente a apagar coisas sem vigilância. O padrão é perguntar; manter o perguntar é uma disciplina, não uma garantia.

A parte que generaliza.

Tire o Railway e o Cursor e os nove segundos específicos, e o que fica é um padrão que vai definir os próximos anos deste trabalho: agentes agem com credenciais reais a velocidade de máquina, e a cautela que lhes entregamos é um conselho que estão livres de ignorar. O PocketOS não é uma história sobre um modelo mau. O Opus 4.6 fez algo que um cuidadoso engenheiro júnior também poderia fazer numa tarde má — presumiu sobre um escopo, presumiu mal, agiu antes de verificar. A diferença é que as mãos do engenheiro júnior são mais lentas do que nove segundos, e há normalmente alguém na sala.

O Bromure Agentic Coding 2.2 é uma forma de pôr alguém de volta na sala, na única fronteira que o agente não consegue atravessar a raciocinar — o fio de saída da VM. Não para cada tecla, que ninguém toleraria, mas para as escritas, onde o custo de «presumi» é uma base de dados que já não está lá. É gratuito e de código aberto. O padrão é perguntar.