Passamos dois anos discutindo se um agente de código pode receber suas credenciais. A Sysdig acabou de publicar a outra metade da questão: uma quadrilha de ransomware apontou um agente para o servidor de um estranho e o deixou conduzir toda a invasão sozinho — raciocinando em voz alta, corrigindo seus próprios logins falhos em trinta e um segundos, excluindo o banco de dados ao terminar. Ninguém estava dirigindo. O piso de habilidade para esse tipo de ataque agora é o que quer que custe rodar um modelo.

Às 19:34:24 UTC de uma certa noite, um intruso automatizado inseriu uma conta de administrador clandestina num banco de dados de produção. Doze segundos depois, o login falhou. Doze segundos depois disso, ele tentou as credenciais padrão e gerou um novo hash de senha ao mesmo tempo — diagnosticando duas causas possíveis em paralelo. Trinta e um segundos após a primeira falha, ele entregou uma correção completa em várias etapas: parar de recorrer a um subprocesso quebrado, importar a biblioteca de criptografia diretamente, excluir a linha ruim, reinseri-la. A tentativa seguinte logou.

Um respondente de incidentes humano lê essa linha do tempo e sabe o que está vendo. Nenhuma pessoa diagnostica um problema de PATH, reescreve seu exploit e o executa de novo em meio minuto. Isso foi um agente.

O que o JADEPUFFER fez

O ataque, que a equipe de pesquisa de ameaças da Sysdig batizou de JADEPUFFER e cobriu no início de julho, entrou por um servidor Langflow exposto à internet — uma ferramenta para construir apps de LLM — usando a CVE-2025-3248, uma falha de autenticação ausente que permite a uma requisição não autenticada executar Python arbitrário. Essa parte é comum; milhares de instâncias do Langflow ficam expostas. O que aconteceu depois da entrada é que é a história.

O agente enumerou o host e então fez aquilo com que todo manual de pós-exploração agora começa: varreu a máquina em busca de segredos. Em paralelo, caçou chaves de provedores de LLM (OpenAI, Anthropic, DeepSeek, Gemini), credenciais de nuvem da AWS, Google, Azure e vários provedores chineses, carteiras de criptomoedas e logins de bancos de dados. Extraiu o banco de dados de apoio do Langflow em busca de chaves armazenadas. Encontrou um armazenamento de objetos interno ainda usando a senha de fábrica — minioadmin:minioadmin —, listou cada bucket, inclusive o terraform-state, e retirou dele .env e credentials.json. Quando uma requisição de armazenamento voltou em XML em vez do JSON esperado, ele reescreveu o próprio parser na hora e seguiu em frente.

Então pivotou para o alvo real — um servidor separado rodando MySQL e um serviço de configuração Nacos —, forjou um token de administrador usando a conhecida chave de assinatura padrão do Nacos, atravessou a sequência de logins falhos acima e concluiu o trabalho. Cifrou todos os 1.342 itens de configuração do Nacos com uma chave que imprimiu no console exatamente uma vez e nunca salvou, removeu as tabelas originais e criou uma tabela README_RANSOM com um endereço Bitcoin e um contato Proton Mail. Como a chave nunca foi armazenada nem enviada a lugar algum, pagar o resgate não teria trazido os dados de volta.

O sinal revelador o tempo todo foi o próprio código. As cargas úteis estavam repletas de comentários em linguagem clara explicando o porquê — classificando alvos por valor, narrando “este é o maior, elimine-o também”, anotando cada passo como um modelo pensando em voz alta, porque era exatamente isso que acontecia.

A cadeia JADEPUFFER, tal como a Sysdig a reconstruiu. O acesso inicial é um RCE não autenticado comum. Tudo depois dele — o reconhecimento, a varredura paralela de credenciais, a adaptação de um parser em plena requisição, a forja de um token Nacos, a autocorreção de um login falho em 31 segundos e, por fim, cifrar e remover o banco de dados — rodou sem que um humano emitisse um único comando. Os comentários autonarrativos nas cargas úteis são como os pesquisadores souberam.

A parte que deveria preocupar um desenvolvedor

Chame isto de uma história de segurança de servidor — corrija o Langflow, não entregue um banco de dados à internet com uma chave Nacos padrão, tire o armazenamento de objetos do minioadmin — e você estaria certo, e seria tudo a lista de outra pessoa. A razão de pertencer a um texto sobre agentes de código é o passo dois.

Todo segredo alcançável naquele ambiente virou munição no instante em que o agente teve execução de código. As chaves que ele varreu são as mesmas de que seu agente de código precisa para fazer o trabalho: o token de API que o deixa chamar um modelo, as credenciais AWS que ele usa para verificar um deploy, o token GitHub com que ele faz push, a URL do banco de dados no seu .env. O JADEPUFFER mostra o que um agente faz com isso no instante em que para de trabalhar para você — e já sabemos que seu agente pode ser levado a parar de trabalhar para você.

Isso não é especulação. Só neste verão, pesquisadores mostraram um agente de código levado a rodar código do atacante por um falso relatório de bug plantado num feed de monitoramento de erros, e conduzido a executar uma carga útil durante o que parecia uma revisão de segurança de rotina de um repositório não confiável. Em ambos, o agente permanece educado e prestativo até deixar de ser. Coloque a autonomia do JADEPUFFER ao lado desses sequestros e a forma fica clara: o adversário dentro da sua sessão agora pode ser o próprio agente que você convidou, e uma vez que ele vira, faz reconhecimento, colhe todas as credenciais que alcança e se move — sozinho, na velocidade da máquina.

Então a pergunta útil não é “meu agente é confiável”. É “o que o agente alcança quando não é”. Toda defesa que responde pedindo ao agente que se comporte — um prompt de sistema cuidadoso, um fine-tune, um diálogo de confiança — está apostando contra uma coisa que o JADEPUFFER prova poder ser construída especificamente para não se comportar.

O Bromure parte do princípio de que o agente já é hostil

O Bromure Agentic Coding roda seu agente de código dentro de uma VM Linux descartável, e cada requisição de rede que ele faz sai dessa VM através de um proxy no host. O projeto parte da suposição a que a indústria não para de chegar pelo caminho difícil: o agente vai, mais cedo ou mais tarde, rodar algo que você não pretendia. Então o que vale a pena proteger é mantido onde o raciocínio do agente não pode alcançar — no host, não na caixa.

As credenciais são o caso mais claro, porque são a primeira coisa que um intruso busca. No Bromure, o segredo real nunca entra na VM. Quando você dá a um perfil uma chave Anthropic, um AWS_SECRET_ACCESS_KEY, um token GitHub, uma credencial de banco de dados, o ambiente do agente recebe um falso no lugar — um substituto brm_… — e o proxy do host troca o falso pelo valor real no fio, apenas na requisição de saída para o provedor que deve recebê-lo. O agente se autentica e faz seu trabalho; ele apenas nunca detém o material. Até a chave de API que mantém o próprio agente rodando é um chamariz para qualquer coisa que leia o ambiente.

Agora rode o passo dois do JADEPUFFER contra isso. O agente varre a máquina e encontra chaves exatamente onde espera — e cada uma é um falso. Ele as extrai, prepara e envia como beacon a um servidor de comando e controle, e o atacante do outro lado recebe uma pilha de strings brm_… que não se autenticam a nada. O minuto mais valioso do ataque, a colheita de credenciais que alimenta cada passo seguinte, volta de mãos vazias.

A varredura de credenciais, sem e com o Bromure. À esquerda: o agente lê as chaves reais direto do seu ambiente e as expede a um servidor C2; elas funcionam. À direita: a mesma varredura dentro do Bromure só encontra substitutos brm_…. As chaves reais ficam no host e só são postas no fio para a requisição legítima ao provedor; o que chega ao servidor do atacante não se autentica a nada, e o beacon de saída é uma linha no Security Log.

A mesma postura enfraquece o resto da cadeia. O reconhecimento roda contra uma caixa descartável: mapear a máquina e varrer segredos só encontra uma VM descartável clonada de uma base compartilhada, não seu notebook nem sua rede. A persistência que o JADEPUFFER instalou — uma entrada de crontab enviando beacon ao seu servidor a cada trinta minutos — vive dentro dessa VM e morre no instante em que você apaga o home do perfil ou o reinicia para a base, o que é um item de menu, não um incidente. E porque cada requisição sai pelo proxy do host, o beacon para o endereço do atacante não é invisível: é uma linha registrada no Security Log, atribuível à sessão que a fez.

Para o final destrutivo — as tabelas removidas —, os Guardrails do lado do host do Bromure são a rede de segurança, classificando as chamadas do agente aos provedores que entendem e devolvendo um 403 firme nas destrutivas, no fio, onde um agente comprometido na VM não pode desligá-las. Escrevemos sobre essa fronteira em detalhe depois que um agente do Cursor excluiu um banco de dados de produção em nove segundos; o mesmo mecanismo que detém o erro de um agente honesto detém o Delete* ou Terminate* de um agente hostil.

O que isto não resolve, para deixar claro

Ele substitui as credenciais que o Bromure injeta

A troca cobre os segredos que você configura num perfil — chaves de modelos, tokens de nuvem e git, registries de contêineres, os endpoints de bancos de dados gerenciados. Uma senha que você cola à mão num arquivo dentro da VM, ou uma seed de carteira parada num repositório, é apenas um arquivo; o proxy não tem falso para pôr no lugar. Mantenha os segredos no cofre de credenciais, não no espaço de trabalho.

Os Guardrails só barram provedores que interpretamos

O bloqueio de chamadas destrutivas classifica Kubernetes, AWS, DigitalOcean, as grandes forjas git, registries de contêineres e bancos de dados HTTPS como MongoDB, ClickHouse e Elasticsearch. Um socket MySQL cru para uma caixa não gerenciada — o protocolo exato pelo qual o JADEPUFFER removeu tabelas — não é um que o proxy lê hoje. A cobertura é uma lista real, não onisciência.

A saída é registrada, não proibida por padrão

O beacon aparece no Security Log; isso é atribuição, não prevenção. Nada real sai porque as credenciais são falsas, mas se você precisa barrar a VM de falar com hosts arbitrários, isso é uma política de rede que você ainda tem de definir.

Ele não corrige o servidor que você expôs

O Bromure protege a máquina em que seu agente roda. Ele não faz nada por um Langflow voltado à internet, uma chave Nacos padrão ou um armazenamento de objetos minioadmin:minioadmin em outro ponto do seu parque. A metade de acesso inicial desta história continua sendo higiene comum.

A parte que se generaliza

Tire o Langflow, o Nacos e a noite específica, e o JADEPUFFER é uma prévia do terreno em que está quem constrói com agentes. Um agente que pode raciocinar, se adaptar e agir com credenciais reais na velocidade da máquina agora é barato de alugar e fácil de apontar. Ele não precisa ser seu atacante para ser seu problema — só precisa acabar na sua sessão, o que a pesquisa de sequestros deste verão diz que ele pode. Quando isso acontece, a primeira coisa que ele faz é ler seu ambiente.

O Bromure Agentic Coding não tenta impedir isso tornando o agente mais gentil. Ele torna o ambiente digno de leitura apenas para o agente que faz trabalho legítimo: chaves reais no host, chamarizes na caixa, uma VM descartável e um registro de tudo que tentou sair. O agente pode ficar hostil e rodar todo o manual do JADEPUFFER — e descobrir que as credenciais que roubou não abrem nada, que a caixa em que se enfurnou é apagada na próxima reinicialização, e que o único lugar em que os segredos reais um dia viveram era o único lugar que ele jamais poderia alcançar. Ele é livre e de código aberto.