Resumo direto: 2026 registrou os primeiros ataques documentados em que criminosos não atacaram a IA — usaram a IA já instalada na vítima como ferramenta de ataque. No caso mais grave, um pacote npm comprometido instruiu o Claude Code, o Gemini CLI e o Amazon Q CLI já presentes nas máquinas de milhares de desenvolvedores a vasculhar arquivos em busca de senhas, chaves de API e carteiras de criptomoeda — e enviar tudo para os atacantes. Em outro caso, pesquisadores conseguiram fazer agentes de IA de mais de cem empresas reais executarem comandos escondidos dentro de simples registros de erro. O padrão comum: nenhuma dessas ferramentas foi “hackeada” no sentido tradicional. Elas fizeram exatamente o que são projetadas para fazer — só que a mando de quem não deveria estar no controle.

Se sua empresa já usa agentes de IA, Copilot Studio, ou ferramentas de codificação assistida por IA em produção, este artigo detalha os casos reais documentados até agora e o que muda na forma de proteger esse tipo de ferramenta.

Por que um agente de IA é um alvo diferente de qualquer coisa que seu EDR já sabe reconhecer

Soluções de segurança corporativa — EPP, EDR, XDR, SIEM — foram desenhadas para reconhecer padrões: arquivos maliciosos conhecidos, sequências de comando suspeitas, comportamento anômalo. Uma varredura em massa de documentos, um processo PowerShell inesperado, acesso a um cofre de credenciais, exfiltração para um servidor desconhecido — tudo isso dispara alertas em um SOC bem configurado.

Um agente de IA corporativo quebra essa lógica de detecção pela raiz. Ele já tem permissão ampla por design: lê e modifica arquivos, executa comandos de shell, instala pacotes, conecta-se a serviços externos. Desenvolvedores costumam liberar esse tipo de ferramenta em modo autônomo — sem confirmar cada ação manualmente — exatamente para ganhar velocidade. Isso o transforma no alvo ideal: quando comprometido, o atacante herda instantaneamente privilégios, acesso a dados sensíveis e a reputação de “processo confiável” que o agente já conquistou no ambiente.

Some a isso outro problema: a forma de instruir um agente é linguagem natural. Um pedido para procurar senhas ou chaves de API pode ser formulado de milhares de maneiras diferentes, em qualquer idioma, de forma direta ou indireta — e o comando malicioso pode estar escondido em qualquer conteúdo que o agente processe automaticamente: um campo de texto num documento, o nome de um arquivo, ou até um log de erro comum, como mostra um dos casos abaixo.

O ataque à Nx: quando o malware terceiriza o trabalho para o Claude Code da própria vítima

O exemplo mais amplo até agora aconteceu em agosto de 2025 e ficou conhecido como s1ngularity. Segundo a análise da GitGuardian e o levantamento da StepSecurity, atacantes exploraram uma falha num workflow do GitHub Actions para roubar um token de publicação e distribuir versões maliciosas de pacotes do Nx, uma ferramenta de build usada por milhões de desenvolvedores toda semana.

O script malicioso, ativo por poucas horas antes de ser removido do npm, verificava se a máquina da vítima tinha o Claude Code, o Gemini CLI ou o Amazon Q CLI instalados. Se algum estivesse presente, o malware disparava um prompt em linguagem natural instruindo o próprio agente — já com permissões elevadas para lidar com arquivos de desenvolvimento — a vasculhar carteiras de criptomoeda, arquivos de ambiente (.env), chaves de API e outros segredos. Vários ataques rodavam com flags de aprovação automática ativadas, como --dangerously-skip-permissions, --yolo ou --trust-all-tools — configurações que existem justamente para agilizar o trabalho do desenvolvedor, e que aqui removeram qualquer chance de intervenção humana no meio do processo.

Os números consolidados pela GitGuardian mostram 2.349 credenciais expostas em 1.079 sistemas de desenvolvedores só na primeira onda. A Wiz identificou uma segunda onda dias depois, em que os tokens do GitHub já roubados foram usados para tornar públicos mais de 3 mil repositórios privados, afetando pelo menos 190 organizações.

Um detalhe que raramente aparece nas coberturas técnicas: segundo análises pós-incidente, os próprios agentes de IA ocasionalmente se recusaram a executar partes da tarefa por considerá-la antiética — obrigando os autores do malware a ajustar o código para lidar com essas recusas e com o tempo de processamento, às vezes considerável, que o agente levava para responder. A defesa embutida no modelo criou fricção real, mas não impediu o ataque. O aprendizado prático: a segurança de um agente de IA precisa vir em camadas, porque nenhuma delas sozinha é suficiente.

AgentJacking: um comando escondido dentro de um simples registro de erro

Nem todo experimento precisa roubar dados para provar um ponto perigoso. O estudo batizado AgentJacking não teve intenção maliciosa — mas replicou, em escala real, exatamente o que um atacante faria. Os pesquisadores miraram no Sentry, serviço de telemetria usado por incontáveis sites e aplicativos para reportar erros automaticamente, sem exigir autenticação — afinal, erros costumam vir de visitantes anônimos que o sistema nunca viu antes.

Eles configuraram um servidor MCP próprio dentro do Sentry, permitindo que agentes de IA analisassem os relatórios de erro automaticamente. Depois, enviaram uma mensagem de erro falsa contendo uma instrução escondida — uma injeção de prompt indireta — pedindo para “rodar diagnósticos adicionais” via um comando de instalação de pacote. Se o tratamento daquele erro fosse delegado a um agente, ele podia interpretar a instrução como legítima e executar a instalação sem questionar.

O resultado, replicado globalmente pelos próprios pesquisadores: agentes de IA de mais de cem empresas reais — algumas delas grandes corporações — responderam ao comando escondido. No experimento, o pacote instalado apenas avisava o servidor dos pesquisadores, sem roubar nada. Um pacote malicioso de verdade, no mesmo cenário, poderia roubar credenciais, alterar código ou se instalar de forma persistente no ambiente. Identificar alvos para um ataque assim é trivial — basta checar se o site ou aplicativo de uma empresa usa Sentry, algo visível no próprio código-fonte ou nos binários do aplicativo móvel.

Segundo os autores do estudo, o Sentry reconheceu o problema, mas optou por bloquear apenas a variante específica de consulta maliciosa usada no experimento, em vez de resolver a causa raiz. Um funcionário da empresa chegou a descrever o sistema, em uma resposta capturada pelos pesquisadores, como “tecnicamente indefensável” contra esse tipo de ataque.

Roubo de dados financeiros via MCP: quando o próprio fornecedor de dados vira o vetor

O Model Context Protocol (MCP), apresentado como uma espécie de “USB universal para agentes de IA”, foi adotado em ritmo acelerado desde seu lançamento — rápido demais para que controles de segurança robustos acompanhassem. A Microsoft já alertou publicamente que ataques direcionados ao protocolo devem se multiplicar.

Um dos riscos menos óbvios está escondido na própria descrição de uma ferramenta MCP — o texto que o agente lê para decidir quando chamar aquela ferramenta e quais dados enviar. Se o provedor do servidor MCP alterar essa descrição silenciosamente, adicionando uma instrução para coletar dados extras, o agente pode simplesmente obedecer como parte do fluxo normal de trabalho.

A Microsoft descreve um cenário concreto: um agente financeiro que verifica dados bancários de fornecedores através de um serviço MCP externo. Depois de uma atualização maliciosa na descrição daquela ferramenta, o agente passa a anexar, junto da resposta normal, dados de faturas em aberto — que são silenciosamente enviados ao dono do servidor. Do ponto de vista de quem usa o agente, tudo parece operar normalmente: ele age com as permissões do funcionário, consulta um serviço já aprovado, usa uma interface padrão. E ainda assim, os dados vazam. Cada etapa isolada parece autorizada; só o resultado final não é.

A internet já está sendo escrita para ser lida por agentes, não por humanos

Em 2026, pesquisadores da Unit 42 documentaram uma quantidade crescente de instruções escondidas em páginas públicas na web, projetadas especificamente para manipular sistemas de IA — de tentativas de fazer o modelo revelar seu prompt de sistema a manipulação de SEO para páginas de phishing. Numa análise independente sobre o mesmo fenômeno, pesquisadores do Google Threat Intelligence vasculharam bilhões de páginas arquivadas no Common Crawl e mediram um aumento de 32% em conteúdo malicioso desse tipo entre novembro de 2025 e fevereiro de 2026.

A maioria dos casos encontrados pelo Google ainda é de baixa sofisticação — brincadeiras, tentativas de manipular resultados de busca, instruções para impedir que um agente resuma o conteúdo de uma página. Mas já existem exemplos concretos do próximo estágio: outras investigações já documentaram instruções de pagamento via PayPal completas, escondidas de forma invisível dentro do HTML de páginas comuns, esperando por um agente com permissão para executar transações financeiras.

Casos confirmados de comprometimento real usando essa técnica ainda são raros — a presença de uma instrução escondida numa página não garante que algum agente chegou a executá-la. Mas o padrão já está claro: quem produz conteúdo malicioso na web começou a escrever pensando num leitor que não é mais só humano.

O que isso significa para empresas que ainda não pensaram nesse risco

Os três casos acima têm uma característica em comum que muda o cálculo de risco: em nenhum deles o modelo de IA em si precisou ser “quebrado”. O Claude Code, o Gemini CLI e o Amazon Q CLI fizeram exatamente o que foram projetados para fazer — procurar arquivos, entender contexto, executar comandos — só que a mando de um atacante disfarçado de instrução legítima. Isso significa que a pergunta certa não é “qual agente de IA é mais seguro”, mas “quais permissões esse agente tem, e o que aconteceria se alguém mal-intencionado assumisse o controle dele por cinco minutos”.

Para empresas que já usam Copilot Studio ou qualquer outra plataforma de agentes personalizados, esse risco é uma extensão direta dos mesmos cuidados que já valem para governança de dados — não uma categoria totalmente nova de problema. Já tratamos os cuidados específicos com dados pessoais nesse contexto em Agentes de IA e LGPD, e o ataque à Nx é o lembrete de que o mesmo raciocínio vale, com urgência ainda maior, para segredos técnicos: chaves de API, tokens e credenciais de sistemas.

Como se defender: governança antes de confiança

A conclusão prática, tanto da pesquisa da Kaspersky sobre esses incidentes quanto das recomendações da Microsoft para MCP, converge num ponto: um agente de IA nunca deveria ser tratado como confiável só porque foi formalmente aprovado para uso corporativo. Aprovação não é o mesmo que segurança contínua.

Na prática, isso se traduz em controles concretos:

  • Inventário completo de agentes, servidores MCP e ferramentas conectadas — não é possível proteger o que ninguém sabe que existe. Use listas de permissão (allowlists) restringindo quais ferramentas e pacotes um agente pode instalar, especificando versões exatas, não apenas nomes de pacotes;
  • Monitore mudanças de versão em ferramentas MCP e dependências — como mostrou o caso do agente financeiro, uma atualização silenciosa na descrição de uma ferramenta já aprovada é suficiente para mudar seu comportamento;
  • Aplique o princípio do menor privilégio — conceda a cada agente apenas as permissões necessárias para a tarefa específica, e apenas pelo tempo que ela dura. A camada de identidade que sustenta isso no ecossistema Microsoft é o Microsoft Entra ID;
  • Exija aprovação humana para ações de risco elevado — instalação de pacotes, execução de scripts, envio de arquivos. As flags de “aprovação automática” que tornaram o ataque à Nx possível existem por conveniência, não por necessidade;
  • Rode agentes em ambientes isolados, com acesso limitado à estação de trabalho principal do desenvolvedor, e desative modos de autoaprovação perigosos por padrão;
  • Restrinja conexões de saída, permitindo tráfego apenas para serviços explicitamente aprovados — a exfiltração via repositório público, como no caso da Nx, depende de conectividade irrestrita;
  • Centralize segredos em cofres seguros, com tokens de curta duração e rotação regular, em vez de deixá-los em arquivos de configuração que um agente comprometido pode ler diretamente;
  • Envie logs de prompts, chamadas de ferramentas, comandos de shell e tráfego de rede do agente para o SIEM e o XDR — mas com contexto operacional específico para pipelines de IA, já que regras genéricas de detecção não foram desenhadas para esse tipo de atividade. É exatamente essa lacuna de contexto especializado que separa um MDR/XDR genérico de uma operação preparada para esse cenário — e o motivo pelo qual um SOC com visibilidade sobre atividade de agentes de IA deixou de ser luxo para virar requisito básico.

Conclusão

Os ataques documentados até agora — a Nx sequestrando o Claude Code da própria vítima, o AgentJacking respondendo por mais de cem empresas via um simples log de erro, o MCP financeiro vazando dados através de uma atualização silenciosa — têm um traço comum que deveria orientar toda decisão de segurança daqui em diante: nenhum deles precisou quebrar a IA. Bastou explorar a confiança que a empresa já havia depositado nela. Enquanto agentes autônomos continuarem ganhando acesso a sistemas, dados e credenciais em nome de produtividade, essa confiança automática vai continuar sendo o alvo mais barato e mais eficiente disponível para um atacante.

Sua empresa sabe exatamente quais permissões seus agentes de IA têm hoje, e o que aconteceria se um deles fosse comprometido? A InfoB ajuda empresas a implementar agentes de IA e ferramentas de codificação assistida com governança, controle de acesso e monitoramento desde o primeiro dia — não como reboque depois de um incidente.

Perguntas frequentes sobre ataques a agentes de IA corporativos

O que foi o ataque s1ngularity à Nx?

Em agosto de 2025, atacantes distribuíram versões maliciosas de pacotes do Nx, ferramenta de build popular no ecossistema JavaScript. O malware instruía agentes de IA já instalados na máquina da vítima — Claude Code, Gemini CLI ou Amazon Q CLI — a procurar senhas, chaves de API e carteiras de criptomoeda, expondo mais de 2.300 credenciais em cerca de mil sistemas na primeira onda.

Um agente de IA precisa ser “hackeado” para ser usado num ataque?

Não necessariamente. Nos casos documentados até agora, os agentes não tiveram nenhuma vulnerabilidade técnica explorada — executaram instruções maliciosas disfarçadas de pedidos legítimos, usando exatamente as permissões e capacidades para as quais foram configurados.

O que é o AgentJacking?

É uma técnica de pesquisa que demonstrou ser possível esconder instruções maliciosas dentro de relatórios de erro comuns enviados ao Sentry, um serviço de telemetria amplamente usado. Quando um agente de IA processava esses relatórios automaticamente, executava a instrução escondida como se fosse legítima — algo confirmado em agentes de mais de cem empresas reais durante o experimento.

Como um servidor MCP pode ser usado para roubar dados?

Um provedor de ferramenta MCP pode alterar silenciosamente a descrição de uma ferramenta já aprovada, incluindo instruções para coletar dados adicionais. Como o agente confia na descrição da ferramenta para decidir o que fazer, ele pode passar a vazar informações sensíveis mesmo operando dentro de um fluxo aparentemente normal e autorizado.

Por que soluções tradicionais de segurança (EDR, XDR) têm dificuldade em detectar esses ataques?

Porque um agente de IA tem permissões amplas e legítimas por design — ler arquivos, executar comandos, instalar pacotes fazem parte do seu funcionamento normal. Isso torna difícil distinguir uma ação maliciosa de uma ação rotineira sem contexto especializado sobre o comportamento esperado daquele agente específico.

Quais controles reduzem o risco de um agente de IA comprometido?

Inventário de agentes e ferramentas conectadas, princípio do menor privilégio, aprovação humana obrigatória para ações de risco elevado, isolamento de ambientes, restrição de conexões de saída, cofres de segredos com rotação regular, e envio de logs de atividade do agente para SIEM e XDR com contexto especializado.

Leia também no blog da InfoB