Uma equipa de investigação em segurança apresentou na DEF CON 2026 uma técnica que transforma os agentes de inteligência artificial usados por equipas de desenvolvimento em executores involuntários de instruções de atacantes. Batizada de Ghostjacking, a técnica não explora uma falha de software tradicional: aproveita o facto de os agentes de IA lerem registos, alertas e relatórios de erro como se fossem informação de confiança — e agirem em conformidade, com as permissões que a organização já lhes concedeu. As conclusões foram apresentadas no palco principal da DEF CON 2026, em Las Vegas, a 9 de agosto.
Resposta rápida: Investigadores da Tenet Security demonstraram o Ghostjacking, uma evolução do ataque Agentjacking em que registos e alertas envenenados em plataformas como Cloudflare, Datadog e Sentry levam agentes de IA a executar código ou a alterar configurações críticas, incluindo DNS. Não existe CVE nem patch: trata-se de uma falha de modelo de confiança em que o agente não distingue dados de instruções. Se usa agentes de IA ligados a plataformas de observabilidade por MCP, restrinja o acesso de rede de saída, limite o que o agente pode executar e exija aprovação humana para alterações de infraestrutura.
O que é o Ghostjacking e porque é diferente
Segundo a Tenet Security, o Ghostjacking é a evolução seguinte da classe de ataques «Agentjacking», que consiste em enganar agentes de programação assistida por IA para que executem código arbitrário nas máquinas dos desenvolvedores. A diferença está no alvo final: em vez de parar na máquina do programador, a técnica chega à própria infraestrutura de rede da organização.
A técnica recorre aos agentes de IA da própria organização para redirecionar tráfego web e correio eletrónico, abrindo um caminho oculto que contorna a firewall, e funciona em plataformas de uso corrente entre equipas técnicas, incluindo Cloudflare, Datadog e Sentry. O detalhe mais desconfortável é o que os investigadores descrevem no encadeamento com a Cloudflare: o registo plantado pelo atacante é lido pela IA como se fosse uma deteção real quando um analista pede a revisão dos eventos bloqueados; a mesma IA reescreve o DNS da empresa, aponta o domínio para o atacante e reporta o problema como resolvido. Ou seja, o mecanismo de bloqueio é o próprio veículo do ataque — a Tenet nota que é a regra de segurança gerida da Cloudflare que bloqueia o pedido, e é esse bloqueio que transporta o ataque para dentro.
No caso do Datadog, a exposição vem de uma credencial destinada ao frontend: a chave, pensada apenas para a parte visível do site, é rotineiramente deixada pública, e os investigadores localizaram mais de 2700 dessas chaves, utilizáveis para plantar um falso alerta de diagnóstico urgente que o agente de IA lê quando um engenheiro lhe pede para verificar erros. No Sentry, o encadeamento ganha uma camada adicional: os investigadores usaram a IA da própria plataforma, o Seer, para «abonar» o conteúdo ao agente seguinte — o Seer lê o relatório falso e a correção do atacante como conclusão própria, e o agente de programação confia nessa conclusão e executa o código malicioso. Houve mesmo um caso demonstrado em que um agente de IA construiu um ataque que outra IA aceitou, descrito como técnica de «auto-exploração».
Cronologia divulgada pelos investigadores
| Data | Acontecimento |
|---|---|
| 3 de junho de 2026 | Divulgação do Agentjacking à Sentry, assim que a cadeia de ataque foi confirmada |
| Junho de 2026 | Publicação da investigação sobre Agentjacking; a Sentry ativa um filtro global para uma cadeia de payload específica |
| Junho de 2026 | Conclusões do Ghostjacking reportadas à Sentry, à Datadog e à Cloudflare |
| 9 de agosto de 2026 | Apresentação do Ghostjacking no palco principal da DEF CON 2026, em Las Vegas |
Na fase anterior da investigação, a Tenet divulgou o problema à Sentry a 3 de junho de 2026; a liderança da empresa respondeu no mesmo dia, reconhecendo a questão mas declinando corrigi-la na raiz, classificando-a como não defensável tecnicamente e notando que os fornecedores de modelos aplicam middleware contra este tipo de conteúdo; durante o período de investigação, a Sentry ativou um filtro global que bloqueia uma cadeia de payload específica. Já quanto ao Ghostjacking, as conclusões foram reportadas pela Tenet à Sentry, à Datadog e à Cloudflare em junho.
Números e escala: o que está e o que não está confirmado
| Indicador (atribuído à Tenet Security) | Valor |
|---|---|
| Sucesso do Ghostjacking contra o Claude Code na configuração recomendada pela Cloudflare | 9 em 10 tentativas |
| Presença da Cloudflare nas empresas da Fortune 500 | 42% |
| Presença do Datadog nas mesmas empresas | 48% |
| Chaves Datadog de frontend expostas encontradas | mais de 2700 |
| Organizações com DSN do Sentry injetáveis (fase Agentjacking) | 2388, das quais 71 no Tranco top 1M |
| Taxa de sucesso do Agentjacking em testes controlados | cerca de 85% |
A equipa demonstrou que a técnica funcionou nove em dez vezes contra o agente Claude Code na configuração recomendada pela própria Cloudflare, e entre as organizações com essa configuração exposta estão uma tecnológica global de valor superior a um bilião de dólares, um prestador global de pagamentos e um laboratório de investigação em IA; o estudo nota ainda que a Cloudflare está presente em 42% das empresas da Fortune 500 e transporta um quinto do tráfego da Internet, que o Datadog está em 48% dessas empresas e que o Sentry é usado por quatro milhões de programadores. A Tenet afirma que metade das empresas da Fortune 500 é vulnerável à técnica — um número autorreportado pela empresa que o publicou, e que deve ser lido como estimativa de exposição, não como registo de compromissos confirmados.
Na fase Agentjacking, os dados são mais granulares: num período de validação encerrado a 17 de junho de 2026, a equipa reporta ter identificado 2388 organizações com DSN do Sentry publicamente expostos e injetáveis, 71 delas no top de um milhão do Tranco, e mais de 100 organizações reais cujos agentes de IA executaram efetivamente o payload de validação controlado. Os testes envolveram mais de 100 alvos em condições controladas com uma taxa de sucesso de 85%, tratando-se de prova de conceito e não de exploração confirmada em todas as 2388 organizações.
Porque é que a firewall, o EDR e o IAM não vêem nada
A raiz do problema é arquitetural, não uma falha de código a que corresponda um CVE. A Tenet aponta a incapacidade dos agentes de programação para distinguir entre conteúdo que leem e instruções para agir: quando um conector MCP recupera conteúdo de uma fonte externa — um documento, um e-mail ou registos de erro — o agente trata tudo como input, tornando trivial esconder instruções maliciosas. A Tenet descreve o risco como resultado dessa confiança implícita: quando um agente consulta erros não resolvidos, recebe a resposta e age sobre ela, como faria um desenvolvedor — mas sem forma de verificar se o evento foi gerado por uma falha real ou injetado.
Daí a invisibilidade para os controlos clássicos. Todos os passos do ataque são autorizados: o atacante nunca toca na infraestrutura da vítima, o desenvolvedor não aprova qualquer código e o agente faz exatamente aquilo que lhe foi pedido — algo a que a Tenet chama Authorized Intent Chain, e a razão pela qual EDR, WAF, IAM, VPN e firewalls não registam nada digno de alerta. No Ghostjacking, o ataque não pode ser sinalizado aos defensores porque os agentes usam acesso que já lhes foi concedido — a firewall não cai, torna-se irrelevante — e os atacantes podem ainda deixar portas traseiras na configuração, na memória e nas ferramentas do agente, garantindo acesso persistente para roubo de dados e credenciais. Nos testes anteriores, os agentes executaram o código mesmo quando lhes foi dito para ignorar dados não confiáveis.
O que pode roubar um único evento envenenado
- Variáveis de ambiente, credenciais AWS em
~/.aws/config, tokens npm, credenciais Docker, credenciais git e URL de repositórios privados - Credenciais de cloud, chaves AWS, tokens do GitHub, chaves SSH e segredos de pipelines CI/CD
- Acesso a repositórios privados de código-fonte, comprometimento de infraestrutura de cloud e estabelecimento de acesso persistente
Um dado útil para quem investiga registos históricos: todos os payloads usados pelos investigadores identificavam-se como um teste de segurança da Tenet, através de um cabeçalho personalizado x-tenet-security: ResponsibleDisclosure [SECURITY SCAN] e de um user agent benigno. Registos com esse cabeçalho correspondem, portanto, a atividade de validação e não a um atacante real.
Mitigações concretas para equipas técnicas
- Negar por omissão o acesso de rede de saída aos ambientes onde os agentes correm, permitindo apenas destinos explicitamente aprovados.
- Auditar credenciais públicas de telemetria: as organizações que usam Sentry devem inventariar os DSN publicamente expostos, sendo que a mitigação não passa por revogar o DSN — que é público por desenho para reporte de erros no frontend — mas por restringir o que os agentes podem fazer com os dados devolvidos.
- Desligar integrações MCP não utilizadas: no Claude Code, removendo a entrada do Sentry do bloco MCP em
.claude/settings.json; no Cursor, desligando o servidor MCP nas configurações. - Exigir aprovação humana para ações de alto impacto — alterações de DNS, regras de firewall, gestão de identidades ou deploys — em vez de confiar em instruções no prompt de sistema, que não impediram a execução nos testes.
- Distinguir, na telemetria de segurança, o que foi feito por um agente e o que foi feito por uma pessoa, e tratar cada agente como um acesso privilegiado sujeito a escopo mínimo e revisão.
- Aplicar endurecimento de configuração aos agentes: a Tenet abriu o código de configurações prontas a usar para Cursor e Claude Code, com o objetivo de reduzir o risco associado a telemetria e registos não confiáveis.
Porque importa para organizações em Portugal
A adoção de agentes de IA em equipas de desenvolvimento e de operações já é comum em Portugal, incluindo em PME que usam Sentry, Datadog ou Cloudflare em produção. O Ghostjacking mostra que a superfície de ataque deixou de ser apenas o código: passou a incluir tudo o que um agente lê e a totalidade das permissões que lhe foram delegadas. Para as entidades abrangidas pelo Regime Jurídico da Ciberseguraça, aprovado pelo Decreto-Lei n.º 125/2025 que transpõe a NIS2, isto tem consequências práticas: a gestão de riscos da cadeia de fornecimento, o controlo de acessos e a capacidade de deteção e de tratamento de incidentes têm de cobrir também identidades não humanas e ferramentas de IA com permissões de escrita em infraestrutura crítica.
Um desvio de DNS ou de correio eletrónico realizado por um agente autorizado pode traduzir-se em interceção de comunicações e de dados pessoais, com obrigações de notificação ao abrigo do RGPD perante a CNPD e, no caso das entidades abrangidas, de comunicação de incidentes ao CNCS através da estrutura nacional de resposta, na qual o CERT.PT desempenha o papel de coordenação técnica. Como não existe um patch nem um identificador CVE que resolva esta classe de problema, a resposta é de arquitetura e de governação: reduzir privilégios, isolar ambientes de execução, registar de forma auditável tudo o que um agente faz e assumir que qualquer dado externo lido por uma IA — incluindo um registo de bloqueio da própria firewall — é potencialmente hostil.
Perguntas frequentes
O Ghostjacking tem um CVE ou um patch disponível?
Não foi divulgado qualquer identificador CVE. Trata-se de uma falha do modelo de confiança dos agentes de IA, que tratam dados externos como instruções legítimas. A mitigação é de configuração e de arquitetura: limitar privilégios, restringir o acesso de rede de saída e exigir aprovação humana para ações sensíveis.
A minha organização está exposta se usar Sentry, Datadog ou Cloudflare?
O risco surge quando agentes de IA com capacidade de executar comandos ou alterar configurações consomem dados dessas plataformas, tipicamente através de integrações MCP. Se os agentes apenas leem e produzem texto para revisão humana, a exposição é bastante menor.
As firewalls e o EDR detetam este tipo de ataque?
Segundo os investigadores, não, porque todos os passos da cadeia são ações autorizadas executadas com credenciais legítimas. É por isso que a deteção tem de passar pela observação do comportamento dos agentes e pela separação clara entre ações humanas e ações automatizadas.
Qual é a primeira medida que uma PME deve tomar?
Inventariar que agentes de IA existem, a que plataformas estão ligados e que permissões detêm. Depois, desligar integrações não utilizadas, negar por omissão o tráfego de saída dos ambientes de execução e retirar aos agentes a capacidade de alterar DNS, regras de firewall ou identidades sem validação humana.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Tenet Security e pelos seus investigadores, em declarações públicas das plataformas envolvidas e em relatos da apresentação na DEF CON 2026.