Pediu ao seu agente para corrigir os erros. Um deles foi escrito por um atacante.

Um programador abre o seu agente de programação com IA e escreve o pedido mais comum do mundo: "vê lá os erros do Sentry por resolver e corrige-os". O agente obtém a lista de erros através do seu conector Sentry, lê o problema no topo, segue os passos de remediação escritos no próprio relatório e executa-os. Meio minuto depois, já tinha executado código de um atacante na máquina do programador, com todos os privilégios deste, e ninguém fez nada de errado.

Trata-se do Agentjacking, revelado este mês pela Tenet Security, que funcionou em 85% das vezes contra os três agentes de programação mais populares do mercado: Claude Code, Cursor e Codex [1][2].

O que aconteceu realmente

Primeiro, o que é o Sentry: um dos serviços de monitorização de erros mais usados em software. Quando a sua aplicação lança um erro ou falha, o Sentry captura-o e arquiva o relatório que os seus programadores triagem — está presente numa enorme fatia das aplicações que usa todos os dias. Para enviar esses relatórios, cada aplicação incorpora um DSN: uma chave do lado do cliente que é incluída de propósito no código do seu site, para que o browser possa reportar os erros. Qualquer pessoa pode lê-la. E qualquer pessoa que a tenha pode enviar por POST um evento de erro para o seu projeto Sentry.

É esta toda a chave do ataque. A Tenet criou um evento de erro falso cujo campo de mensagem estava formatado para parecer exatamente com as recomendações de remediação do próprio Sentry: markdown arrumado, uma "correção recomendada", um comando a executar. Submeteram-no com o DSN público. Depois esperaram pela coisa mais natural que um programador faz — pedir ao agente para limpar a fila de erros.

O agente consulta o Sentry através do seu conector MCP. O conector devolve o erro como saída de sistema de confiança. O agente não consegue distinguir um relatório real do Sentry de um forjado; têm exatamente a mesma forma, byte a byte. Por isso faz aquilo que lhe foi dito e executa a "correção", normalmente uma chamada npx a um pacote do atacante. A partir daí tem tudo aquilo que o programador tem: variáveis de ambiente, credenciais Git, URLs de repositórios privados, as chaves de cloud em ~/.aws/.

A Tenet encontrou 2.388 organizações com DSN vulneráveis a injeção, de programadores independentes até à Fortune 100. Nos seus testes controlados, os agentes chegaram a executar as instruções injetadas em empresas reais — incluindo, segundo a Tenet, uma empresa tecnológica da Fortune 100 avaliada em 250 mil milhões de dólares cujo agente de IA leu o relatório de bug falso e executou o código da Tenet em duas das suas máquinas corporativas [1][3]. Revelado à Sentry a 3 de junho, a empresa reconheceu-o no próprio dia e recusou corrigi-lo na origem, chamando ao problema "tecnicamente indefensável". Lançou um filtro de conteúdo que bloqueia uma string de payload específica [4].

Isto não é o Sentry a ser descuidado

Aqui está a parte desconfortável: nada nessa cadeia foi um bug. O DSN destina-se a ser público. O servidor MCP destina-se a devolver os seus dados de erro. O agente destina-se a agir sobre os diagnósticos que lhe pediu para corrigir. Cada passo foi autorizado, e é exatamente por isso que nenhuma firewall, nenhum EDR, nenhum system prompt o apanhou.

A falha é estrutural, e não é só do Sentry. Qualquer ferramenta que alimente um agente com texto que um estranho pode influenciar — um rastreador de erros, uma fila de tarefas, uma página web recolhida, um documento partilhado — é um canal de injeção, e o agente trata tudo isso como um único fluxo indiferenciado de instruções. A injeção de prompts, dois anos depois do início da era dos agentes, continua por resolver: não é possível impedir de forma fiável que texto hostil entre no raciocínio de um modelo. Parta do princípio de que não vai conseguir.

A injeção não é a catástrofe

Aqui está a parte que vale a pena ponderar. A razão de o Agentjacking ser uma situação de alerta máximo não é o agente ter sido enganado. É aquilo a que o agente enganado conseguia aceder. Correu com todo o acesso permanente do programador: cada chave no ambiente, cada ficheiro de credenciais no disco, todo o chaveiro a um comando de distância.

Esse raio de impacto não é uma lei da natureza. É uma configuração. O agente tinha acesso permanente a tudo isso porque é assim que as credenciais são guardadas hoje — ambientes, na máquina, legíveis por tudo o que lá corre. Retire isso, e o mesmo sequestro bate numa parede.

Concebido para isto, de propósito

Uma credencial Clavitor nunca fica no ambiente onde o agente corre. Não existe nenhum ~/.aws/credentials para ler, nenhuma API key numa variável de ambiente para exfiltrar, porque o valor secreto nunca chega onde o código é executado — o agente obtém o resultado de usar uma credencial, não a credencial em si. Só consegue aceder àquilo para que foi nomeado, pelo que não consegue enumerar o cofre para descobrir que mais lá está. E a autorização é delimitada e revogável, pelo que uma sessão que comece a comportar-se como um atacante pode ser cortada a meio de uma ação.

Eis a ressalva honesta: isto não impede a injeção, e não impede que um agente sequestrado execute um comando. A injeção de prompts continua por resolver e não estamos a afirmar que a resolvemos. O que muda é a recompensa do atacante. O código do atacante continua a correr — e encontra um ambiente sem nada de valor para roubar. O sequestro tem sucesso e o roubo falha.

Escrevemos as regras que um sistema de credenciais tem de cumprir quando o próprio agente pode ser virado contra si, começando por o segredo nunca viver onde o código corre, e por um agente só aceder ao que foi nomeado. Avalie o seu sistema à luz delas: clavitor.ai/rules.

A lição não é "corrigir o Sentry"

O Sentry não consegue resolver isto, e disse-o. E a próxima ferramenta envenenada não será o Sentry. Enquanto os seus agentes transportarem credenciais permanentes e ambientes, cada ferramenta de confiança que leem é uma arma carregada, e a injeção de prompts é o gatilho que não consegue trancar.

Não vai conseguir impedir a entrada do texto malicioso. Por isso, deixe de manter as credenciais ao alcance do agente que o lê.

Clavitor (@clavitorai) é o cofre de credenciais construído para agentes de IA — e contra eles. clavitor.ai

Fontes

[1] Tenet Security — "Agentjacking: hijacking coding agents with fake Sentry errors" (85% de sucesso; 2.388 organizações; mecanismo): https://tenetsecurity.ai/blog/agentjacking-coding-agents-with-fake-sentry-errors/

[2] The Hacker News — "Agentjacking Attack Tricks AI Coding Agents Into Running Malicious Code": https://thehackernews.com/2026/06/agentjacking-attack-tricks-ai-coding.html

[3] The New Stack — "A public Sentry key is all it takes to hijack Claude Code, Cursor, and Codex": https://thenewstack.io/agentjacking-sentry-mcp-attack/

[4] Infosecurity Magazine — "New 'Agentjacking' Attacks Could Hijack AI Coding Agents" (resposta da Sentry): https://www.infosecurity-magazine.com/news/agentjacking-attacks-hijack-ai/