Relatório de IA de 2026 da Mandiant: a conta de US$ 50.000 de um agente descontrolado e intrusões assistidas por IA

relatório da MandiantAI Risk and Resilience 2026, publicado no Google Cloud em setembro de 2026 e noticiado na mesma semana por Help Net Security, The Hacker News e SecurityBrief, descreve três engajamentos nos quais a IA foi o mecanismo, e não o alvo: uma sessão sequestrada de assistente de programação de IA que espalhou o Shai-Hulud worm por cerca de 100 repositórios internos em um provedor de software como serviço não identificado; uma credencial de CI/CD comprometida que um invasor transformou em um hub ofensivo assistido por IA dentro de uma empresa de saúde, exfiltrando milhares de credenciais; e um agente de contabilidade que acumulou cerca de $50,000 em cobranças de nuvem em menos de uma hora depois que um valor nulo corrompido quebrou uma de suas ferramentas, bloqueando um banco de dados de faturamento e interrompendo transações em tempo real. Nenhum atacante esteve envolvido no terceiro caso. O registro no qual este artigo se baseia, e as entradas arquivadas em torno dele, estão em o arquivo de incidentes de IA, que traz as fontes, a severidade, a classificação de confiança e o sinalizador de disputa de cada entrada.

Que tipo de documento é este

O relatório tem o título “Risco e resiliência da IA em 2026: um relatório especial da Mandiant” na página de recursos de segurança do Google Cloud, e trata-se de uma publicação de fornecedor, e não de uma divulgação de violação de dados. Seus estudos de caso vêm de projetos de resposta a incidentes da Mandiant e de avaliações de sua equipe de Segurança Ofensiva, e as organizações são identificadas apenas por setor: um fornecedor de software como serviço, uma organização global de saúde e uma prestadora global de serviços financeiros empresariais. Nenhuma vítima é nomeada, nenhuma intrusão tem data e nenhuma declaração de vítima acompanha nenhum dos três casos.

Isso condiciona a forma como os números devem ser lidos. Todos os números neles têm origem nos próprios investigadores da Mandiant. A nota Frontier Ready da Cloud Security Alliance, de 16 de setembro, classifica a cobrança de aproximadamente US$ 50.000 e o volume de 15.000 chamadas como "autorreportados (métrica do provedor)" e afirma que eles "não foram verificados de forma independente" — uma descrição justa de todo o relatório, que não publica telemetria de terceiros para conferência. O arquivo classifica esta entrada como um registro informativo, um relatório e não um incidente com danos registrados, e atribui a ela grau de confiança A sem sinalizá-la como contestada; esse grau diz respeito ao quão bem o relatório está documentado, e não a se uma parte externa confirmou seu conteúdo.

O próprio enquadramento do relatório é que os adversários passaram, em 2026, de pedir pesquisas a chatbots para permitir que sistemas agênticos realizassem partes de uma intrusão. A Mandiant afirma que o Google Threat Intelligence Group observou atores implantando ferramentas autônomas, incluindo Hexstrike e Strix, para reconhecimento e coleta de credenciais, além de construir relays de proxy e pipelines automatizados de registro para contornar salvaguardas e limites de cobrança em plataformas comerciais de IA. O relatório cita a weaponização, em fevereiro, das habilidades de agente do OpenClaw que o VirusTotal documentou, comprometimentos da cadeia de suprimentos em março que a Mandiant atribui ao ator que rastreia como UNC6780 e que outros rastreiam como TeamPCP, e uma divulgação de maio que a GTIG descreveu como o primeiro caso publicamente confirmado de um cibercriminoso usando um exploit de dia zero desenvolvido por IA, um que contornou a autenticação de dois fatores em uma ferramenta popular de administração de código aberto.

Caso um: o assistente recomendou o pacote

No primeiro caso, um atacante comprometeu um provedor de software como serviço e, em seguida, assumiu o controle de uma sessão ativa de assistente de programação com IA na estação de trabalho de um desenvolvedor. A Mandiant descreve o assistente como “operando como um intérprete confiável dentro do ambiente”: ele recomendou a instalação de um pacote de software externo que o atacante já havia envenenado, e o desenvolvedor aceitou a recomendação. O relatório afirma que o assistente “funcionou inadvertidamente como um cavalo de Troia”.

Durante a sessão ao vivo, o atacante instalou um infostealer por meio de um pacote PyPI envenenado e coletou os tokens OAuth do GitHub do desenvolvedor. O worm Shai-Hulud, autorreplicante, então se espalhou por aproximadamente 100 repositórios de código internos, automatizando o roubo de segredos de repositório e a exfiltração programática de código-fonte proprietário de produtos. O atacante também envenenou um pacote dentro do namespace oficial da organização, e um segundo funcionário baixou a versão comprometida — uma infecção secundária que, segundo a Mandiant, não exigiu nenhuma ação adicional do invasor.

O que o relatório não diz é quando qualquer uma dessas coisas aconteceu, nem como o atacante obteve controle da sessão do assistente em primeiro lugar. O The Hacker News, ao noticiar o estudo de caso em 16 de setembro, observa ambas as omissões. A nota de pesquisa da Cloud Security Alliance de 18 de setembro sobre o caso chama o vetor de acesso inicial de "a questão em aberto mais significativa do estudo de caso" e observa que os controles recomendados pela Mandiant abordam até onde uma infecção pode chegar, não como a sessão foi sequestrada.

Os controles da Mandiant para este caso são três, e são específicos quanto à falha: impor hooks de verificação em IDE e CLI que verificam cada dependência de terceiros recomendada por IA em relação a checksums criptográficos e a uma lista de permissões aprovada; manter chaves de API brutas, tokens OAuth de longa duração e outros segredos fora do alcance das extensões; e restringir a saída de rede das estações de trabalho para que o tráfego de dependências seja roteado apenas por repositórios internos controlados.

Caso dois: uma credencial de CI/CD transformada em um hub de co-depuração com IA

O segundo caso é uma investigação de nuvem empresarial numa organização global de saúde. A Mandiant rastreou atividade anómala até uma credencial de CI/CD de developer de longa duração comprometida, que o intruso utilizou para criar uma instância de VM não isolada e convertê-la num hub ofensivo ativo. Em vez de construir ferramentas offline, o atacante ligou modelos de linguagem de grande dimensão diretamente ao servidor em execução e iterou contra eles no local.

A Mandiant descreve um fluxo de trabalho em três estágios. Primeiro veio a preparação do contexto: pacotes de código sincronizados por meio de sessões remotas e arquivos README do projeto carregados no contexto de chat do modelo, para direcionar a geração de código posterior aos objetivos da campanha. Depois, a depuração interativa: o atacante fez o modelo construir um framework de coleta de dados com múltiplos workers e trabalhou com ele na resolução de erros lógicos de divisão de scripts, elevando a cadência de exfiltração para um ciclo de três horas. Por fim, evasão e exploração: o modelo escreveu scripts dinâmicos de rotação de IP para trocar endereços de servidor na lista de bloqueio em tempo real, e codesenvolveu uma ferramenta baseada em Rust para fazer login em contas de vítimas e verificar saldos financeiros.

A Mandiant afirma que a campanha comprometeu milhares de credenciais e exfiltrou chaves de API e segredos financeiros coletados para um repositório controlado pelo atacante. O relatório não diz a quem pertenciam as contas visadas pela ferramenta Rust, a que pertenciam os saldos financeiros verificados, nem o que aconteceu com as credenciais depois. Nenhum dado de paciente é mencionado em qualquer parte do estudo de caso.

Os controles recomendados seguem a credencial, e não o modelo: substitua chaves de acesso de longa duração por relações de confiança de curta duração do Workload Identity Federation usando OIDC; contenha o egress com o VPC Service Controls para que ambientes de execução e de desenvolvimento não consigam alcançar provedores de modelos externos não aprovados; execute varredura contínua de segredos em todos os workspaces; e coloque um firewall de prompt em tempo de execução, como o Model Armor, no caminho para interceptar credenciais embutidas no código e bloquear scripts utilitários ofensivos durante a execução.

Caso três: o agente que gastou US$ 50.000 em menos de uma hora

O terceiro caso não tinha adversário. Um provedor global de serviços financeiros corporativos implantou um agente para reconciliar anomalias em seu razão contábil e lhe concedeu acesso de leitura e escrita a bancos de dados internos de faturamento. Um valor nulo corrompido quebrou a ferramenta de formatação do agente, e o agente respondeu entrando no que a Mandiant chama de loop de raciocínio recursivo e irrestrito para corrigir o problema por força bruta.

Em menos de uma hora, ele emitiu mais de 15.000 chamadas de API de raciocínio de alta frequência e alto custo, produzindo um pico repentino de faturamento de nuvem de aproximadamente US$ 50.000. O mesmo loop causou um bloqueio grave do banco de dados local que interrompeu transações comerciais ativas. A Mandiant classifica o caso como "negação de carteira" (denial-of-wallet), e as correções que prescreve são operacionais, e não no nível do modelo: um limite de gastos, recursão limitada e um disjuntor para interromper um agente que continua falhando na mesma tarefa.

O relatório não diz se a cobrança foi paga, creditada ou contestada, por quanto tempo as transações foram interrompidas, se clientes foram afetados ou o que a empresa mudou depois. Também não informa a data. O resumo da SecurityWeek de 18 de setembro o agrupa sob o que o relatório sinaliza como uma nova categoria de risco financeiro, e não como uma intrusão convencional.

Os controles propostos pela Mandiant são correspondentemente financeiros: definições de identidade e de acesso baseado em função para agentes, limites máximos de custo e monitoramento como governança, além de disjuntores financeiros automatizados que interrompem um agente após um número definido de falhas consecutivas de tarefa. No nível de serviço e de projeto, ela recomenda tetos financeiros rígidos, limites de recursão circunscritos e limites de taxa, para que um loop de autocorreção seja limitado antes de se tornar uma indisponibilidade.

O que está estabelecido, o que é atribuído, o que não é divulgado

Comprovado. A Mandiant publicou este relatório, e ele diz o que está resumido acima. Quatro publicações do setor cobriram-no em um intervalo de três dias entre si — Help Net Security e The Hacker News em 16 de setembro, SecurityBrief UK em 17 de setembro e SecurityWeek em 18 de setembro — e suas matérias coincidem com o relatório em todos os números que repetem. A Cloud Security Alliance publicou uma nota de pesquisa separada sobre o primeiro caso em 18 de setembro, chegando à mesma leitura de sua mecânica e à mesma conclusão sobre o que a Mandiant omitiu.

Atribuído, não verificado de forma independente. Os números específicos são da Mandiant: aproximadamente 100 repositórios, milhares de credenciais, um ciclo de exfiltração de três horas, mais de 15.000 chamadas de raciocínio, cerca de US$ 50.000, menos de uma hora. Nenhum veículo de imprensa publicou telemetria de qualquer uma das três vítimas, e nenhuma das três foi nomeada por ninguém. A corroboração que existe é do conteúdo do relatório, não dos eventos. Essa distinção é tudo o que um leitor pode usar como base aqui, e o grau de confiança do arquivo também deve ser lido assim.

Não divulgado. O relatório não fornece datas para nenhum dos três trabalhos, nem nomes de vítimas, nem relato de como a sessão do assistente no caso um foi assumida. Não diz se os tokens OAuth do GitHub e os segredos de repositório coletados foram revogados, se as milhares de credenciais do caso dois foram usadas ou redefinidas, se os titulares dos dados da organização de saúde foram afetados, se a cobrança do agente de contabilidade foi recuperada, ou o que qualquer uma das três organizações mudou depois. Este artigo não encontrou declaração de vítima, aviso de regulador ou reportagem de acompanhamento publicada desde 16 de setembro que preencha essas lacunas.

Onde a cobertura diverge. A nota da Cloud Security Alliance descreve a segunda infecção no caso 1 como disseminada pelo próprio namespace npm da empresa. O texto da Mandiant diz apenas "um pacote dentro do namespace oficial da organização" e não nomeia um ecossistema ali; a interpretação como npm é um acréscimo, não uma citação. Separadamente, o The Hacker News é explícito que o worm neste caso não está ligado, pelas evidências disponíveis, ao worm npm de agosto que plantou ganchos para assistentes de codificação, nem a uma variante de Shai-Hulud encontrada escaneando 469 locais em busca de credenciais — o mesmo nome de família, campanhas separadas, sem evidências no artigo que as relacione.

O que o relatório diz que deveria mudar

As recomendações da Mandiant repetem-se ao longo dos estudos de caso do relatório: abandonar credenciais de longa duração e contas de serviço em favor de identidades vinculadas a uma carga de trabalho e de curta duração por conceção; tratar os assistentes de programação com IA e os servidores MCP como sessões privilegiadas cujas extensões e hooks de CLI são verificados antes da execução; encerrar as cargas de trabalho dos agentes em perímetros de rede que bloqueiem a saída para fornecedores de modelos não aprovados; e instrumentar a utilização de tokens, as chamadas de API entre aplicações e o acesso dos agentes a ativos sensíveis, de modo que uma primeira leitura de um repositório sensível surja como um sinal em vez de se confundir com o tráfego legítimo das ferramentas.

Em termos de custo, ele traça uma linha entre a governança da IA e a governança para a IA: de um lado, políticas que definem apetite a risco e regras de contratação; do outro, limites técnicos impostos. O agente de contabilidade é o exemplo do relatório de falha do segundo tipo: segundo o relato da Mandiant, nada em sua implantação limitava o loop, e os controles que o teriam detectado — um teto, um limite de taxa, um disjuntor — são controles comuns aplicados a uma carga de trabalho incomum.

Os três casos não compartilham uma causa. Um é um problema de confiança, em que a recomendação de um assistente carregava a autoridade da de um colega. Outro é um problema de credenciais que antecede qualquer modelo, com os modelos tornando a intrusão mais rápida e mais adaptativa uma vez lá dentro. O terceiro não é nem uma coisa nem outra: nenhum atacante, nenhum exploit, apenas um agente com acesso de escrita a um livro-razão e sem teto para o que poderia gastar para consertar uma ferramenta defeituosa. O que eles têm em comum é que, em cada um, o sistema de IA tinha uma autoridade que ninguém havia delimitado — para recomendar, para reconfigurar, para continuar tentando.