Voltar para todas as publicações
Publicado em · por Renaud Deraison

O relatório de bug executou o comando

O agentjacking, divulgado pela Tenet Security em junho de 2026, não precisa de malware nem de acesso à sua infraestrutura. Um invasor registra um erro falso no seu projeto Sentry usando uma chave pública de escrita, esconde instruções dentro dele e espera. Quando você pede ao seu agente de codificação para corrigir o problema, ele lê o texto do invasor como orientação e o executa com as suas credenciais. A Tenet encontrou pelo menos 2.388 projetos expostos e uma taxa de sucesso de 85% em Claude Code, Cursor e Codex. O Bromure Agentic Coding executa todo esse caminho de ler-e-executar dentro de uma VM Linux descartável, avalia o texto obtido antes de o agente agir, e deixa ao ladrão de credenciais apenas iscas.

Você pediu ao seu agente de codificação para corrigir um erro. Ele abriu o rastreador de problemas, leu o primeiro resultado e fez o que ele dizia. O problema é que qualquer pessoa na internet poderia escrever esse erro — e o que o seu agente leu foi escrito para ser obedecido. Nenhum malware chegou. Nenhum servidor foi violado. Um relatório de bug executou um comando na sua máquina.

Em 12 de junho de 2026, os pesquisadores da Tenet Security — Ron Bobrov, Barak Sternberg e Nevo Poran — publicaram um ataque que chamam de Agentjacking, por meio da AI Safety Initiative da Cloud Security Alliance. Ele não usa um e-mail de phishing, um pacote envenenado nem uma senha roubada. Ele usa um relatório de bug. Especificamente, usa o fato de que um agente de codificação ao qual se pede para "corrigir os problemas abertos do Sentry" vai ler um relatório de erro e tratar o seu conteúdo como instruções.

O ponto de partida é algo que a maioria dos aplicativos web distribui de propósito. Um DSN do Sentry — a chave que um site usa para relatar seus próprios travamentos ao Sentry, a plataforma de rastreamento de erros — é uma credencial pública de escrita. Ela vem no JavaScript do lado do cliente da página, e o endpoint de ingestão do Sentry aceita, por design, requisições POST não autenticadas para ela. É assim que a aba do seu navegador relata um travamento sem fazer login. Isso também significa que qualquer pessoa que leia o código-fonte da sua página pode enviar eventos ao seu projeto Sentry. A Tenet procurou por eles e encontrou 71 DSNs injetáveis entre os principais um milhão de sites, e pelo menos 2.388 organizações com DSNs expostos por toda a internet.

Como um relatório de travamento vira um comando

O invasor pega um DSN que encontrou e envia por POST um evento de erro forjado a ele. O evento parece um travamento comum, exceto que o campo de mensagem e as chaves de contexto são escritos em markdown — títulos, blocos de código, uma seção que se lê como uma "Resolução" — formatados para serem visual e sintaticamente indistinguíveis dos próprios modelos de diagnóstico do Sentry. Ele fica na lista de problemas do projeto como qualquer outro erro não resolvido.

Então o invasor espera por você. Quando um desenvolvedor pede ao seu agente de codificação para investigar problemas não resolvidos do Sentry, o agente consulta o Sentry — geralmente por meio do servidor MCP do Sentry, o conector padrão que permite a um agente puxar dados de uma ferramenta externa — e recebe o evento de volta. Como a Tenet colocou, o agente "recebe a resposta e age sobre ela, exatamente como um desenvolvedor faria". A resposta não carrega nenhum sinal de que o seu conteúdo foi criado por um invasor, e não pelo próprio runtime do aplicativo. A "Resolução" diz para executar um comando. O agente o executa, com os próprios privilégios do desenvolvedor, na própria máquina do desenvolvedor.

Passo 1 — o invasor o planta (a qualquer momento)Invasorlê seu DSNPOST travamento falsoSeu projeto Sentryevento = "Resolução""execute isto p/ corrigir"Passo 2 — você pede a correção (depois, à parte)O agente"corrija osproblemas"consulta MCPServidor MCP Sentryretorna o eventosem indício de origemlido como planoSua máquinao agente executa o comandoseus privilégios,seus tokens reaisexfiltraServidor do invasorSem phishing. Sem malware. Cada passo é uma ação autorizada.
O agentjacking tem duas metades que nunca se encontram. Primeiro o invasor envia por POST um travamento falso ao seu projeto Sentry usando o DSN público de escrita, com comandos escondidos na mensagem como uma falsa “Resolução”. Depois, e separadamente, você pede ao seu agente para corrigir os problemas abertos; ele puxa o evento envenenado pelo servidor MCP do Sentry, lê a Resolução como orientação e a executa com as suas credenciais — exfiltrando tokens para o invasor. O invasor nunca toca na sua infraestrutura.

A Tenet relatou uma taxa de sucesso de 85% nos agentes que testaram — Claude Code, Cursor e Codex, as ferramentas que a maioria dos desenvolvedores usa. O comando de prova de conceito deles saiu com variáveis de ambiente, credenciais AWS, tokens OAuth do GitHub e do GitLab, tokens do registro npm, configuração do Docker, tokens de cluster Kubernetes e segredos de pipeline CI/CD. O Sentry, avisado da falha em 3 de junho, recusou-se a corrigir o comportamento subjacente — é, nas suas palavras, tecnicamente indefensável — e adicionou um filtro de conteúdo global que bloqueia uma string de payload específica.

Por que toda defesa existente passou direto por ele

O agentjacking importa não pela engenhosidade do payload, mas porque nada em uma pilha de segurança normal dispara. Não há malware no disco para um agente de endpoint pegar. Não há login incomum para o monitoramento de identidade sinalizar. Não há conexão de saída de um processo que não tenha motivo para fazê-la — o agente deve falar com o Sentry, e as credenciais do desenvolvedor devem funcionar. Cada passo da cadeia é uma ação autorizada realizada com acesso legítimo. Como a Tenet colocou, o ataque não viola nenhuma política e não cruza nenhum limiar de anomalia.

Essa é a mesma parede que o resto da segurança agêntica continua a bater. Uma lista de bloqueio de comandos perde para o shell que reescreve o comando. Um espaço de trabalho em que você confiava perde para os servidores que ele lança em silêncio. Uma revisão de segurança que o agente faz por você torna-se aquilo que ataca você. O agentjacking é a versão em que a entrada envenenada chega por uma ferramenta em que você tinha razão de confiar, carregando dados que você tinha todos os motivos para ler. O servidor MCP do Sentry fez o seu trabalho perfeitamente. O problema é que "busque o erro e aja sobre ele" e "busque as instruções do invasor e aja sobre elas" são, para o agente, a mesma frase.

As próprias recomendações da Tenet apontam para a forma da correção: executar o agente em um sandbox com saída de rede restrita, tratar tudo o que um servidor MCP retorna como entrada potencialmente adversária, e parar de deixar uma string obtida virar um comando sem uma fronteira entre os dois. Isso descreve uma arquitetura, não um patch.

Onde o Bromure traça a linha

O Bromure Agentic Coding não tenta ensinar o agente em quais relatórios de bug acreditar. Ele muda o que um relatório em que se acreditou pode alcançar. Cada agente que o Bromure executa — Claude Code, Codex, Grok Build — roda dentro de uma VM Linux descartável no seu Mac, não no próprio macOS. Assim, quando o agente puxa o evento Sentry envenenado e faz exatamente o que a Tenet observou esses agentes fazerem, várias coisas já são verdadeiras.

Primeiro, o texto obtido é lido por um detector antes de virar um plano. O agentjacking é um ataque de leitura antes de ser um ataque de execução: todo o exploit depende de o agente ingerir a "Resolução" do invasor e tratá-la como orientação. Essa é precisamente a autoridade não confiável que o Bromure vigia — a mesma classe de um CLAUDE.md malicioso ou um AGENTS.md envenenado. A detecção de injeção de prompt no dispositivo do Bromure avalia o conteúdo que o agente lê contra modelos locais que nunca deixam o Mac, além de um scanner determinístico para truques de Unicode invisível. Um relatório de travamento cuja "correção" é um comando shell que lê os seus tokens é exatamente o caso que esse detector existe para sinalizar.

Segundo, o comando roda em uma caixa que você joga fora. Suponha que a isca seja bem formulada o suficiente para escapar do avaliador e o comando rode. Ele roda dentro da VM. O "acesso de backdoor persistente" do modelo de ameaça da Tenet não tem onde persistir: redefina o perfil para a base e o script solto, a chave SSH adicionada, a tarefa agendada — tudo isso desaparece. Nada que o comando fez sobrevive ao fechamento da janela.

Terceiro, não há credenciais reais para roubar. Toda a lista de espólio da prova de conceito — chaves AWS, tokens do GitHub e do GitLab, credenciais npm e Docker, segredos Kubernetes e CI/CD, variáveis de ambiente — é o que o Bromure mantém fora da caixa desde o início. O Bromure injeta valores de espaço reservado (brm_…, um ~/.kube/config sintético, tokens de nuvem e de registro descartáveis) na VM e só troca os reais de volta no host, no proxy, a caminho da API genuína. O comando vasculha o ambiente e o disco e encontra iscas. O que quer que ele envie ao servidor do invasor é um saco de strings que não autenticam nada.

Quarto, a exfiltração é visível. O ataque da Tenet termina com os tokens roubados deixando a máquina. O Bromure roteia o tráfego da VM por um proxy no host, de modo que a conexão ao servidor do invasor aparece no Registro de Segurança como tráfego de saída que você pode ver — não uma chamada silenciosa de um laptop que você presumia estar limpo. A "saída de rede restrita" que a Tenet recomenda é onde o agente já vive.

VM Linux descartávelEvento envenenadoo agente buscaa "Resolução"Detector de injeçãoavaliação no dispositivoavaliado antes de rodarO que o comando roubariaAWS_SECRET = brm_9f2a… (falso)tokens GitHub / npm / kube = iscasa caixa se redefine depoisexfil (registrada)O invasor recebe iscasstrings que não abrem nadaSegredos reaisficam no proxy do hosttrocados no fioO relatório chega e o agente o lê. Só que num lugar descartável, com chaves que não são reais.
Mesmo relatório falso, mesma busca, mesmo comando — máquina diferente. Dentro do Bromure o agente roda em uma VM Linux descartável: a “Resolução” envenenada é avaliada por um detector no dispositivo antes de virar um plano, o comando roda em um lugar descartável, os tokens que ele vasculha são iscas trocados pelos reais apenas no proxy do host, e a exfiltração é registrada. O relatório ainda chega. Não há nada que valha a pena levar.

O que isto realmente delimita

O isolamento e a avaliação são contenção, não uma cura para um agente confiante. Vale a pena ser preciso sobre o que o Bromure muda aqui e o que não muda.

O relatório ainda chega

O Bromure não conserta o design do DSN do Sentry nem impede um invasor de registrar um travamento envenenado — aquela chave pública de escrita é a fronteira que o Sentry deve traçar, e eles se recusaram a fazê-lo. O que o Bromure muda é o que acontece depois que o agente lê o relatório: onde o comando roda e o que ele pode alcançar.

A detecção é uma rede, não uma parede

A avaliação de injeção no dispositivo sinaliza uma resolução do tipo "execute isto para corrigir" mais vezes do que não, mas um autor cuidadoso pode formular uma isca para escapar de um único scanner. Trate o detector como uma camada; a contenção — uma caixa descartável com chaves falsas e uma saída registrada — é o que segura quando um detector falha.

A substituição cobre os segredos que você configura

A troca por isca protege as credenciais que você coloca em um perfil: chaves de modelo, tokens git e de nuvem, tokens de registro e de cluster, chaves SSH. Um token que um script escreve no disco durante a execução, ou uma sessão que você estabelece à mão dentro da caixa, é apenas dado. Mantenha os segredos no broker, não no espaço de trabalho.

Isolamento não é motivo para executar tudo automaticamente

Uma VM descartável reduz o raio de explosão; ela não torna a revisão inútil. Para ações que alcançam fora da caixa — abrir um pull request, fazer push para um repositório remoto — o passo de confirmação ainda vale o seu lugar. A contenção reduz o risco de um erro; ela não o apaga.

A descoberta da Tenet não é que uma plataforma tem um bug. É que o mecanismo de confiança por baixo — um agente que trata uma string obtida como um fato e uma "Resolução" como um plano — é compartilhado por toda ferramenta que conecta um agente ao mundo exterior, e ele não será corrigido neste trimestre. O Sentry é o mensageiro; o próximo será um ticket do Jira, um comentário do Linear, uma revisão de código deixada por um estranho. O seu agente vai ler algo que um invasor escreveu, e a uma taxa de sucesso de 85% ele às vezes fará o que ele diz. A questão não é se ele algum dia será enganado. A questão é o que roda quando isso acontece: a sua máquina, os seus tokens reais e um ponto de apoio que permanece — ou uma caixa Linux que você pode jogar fora, com iscas dentro dela e a saída no registro. O Bromure faz com que seja a segunda.