Nova pesquisa da Microsoft mostra como invasores podem sequestrar agentes de inteligência artificial (IA) que agem em nome do usuário, usando apenas uma descrição de ferramenta envenenada para fazer o agente entregar discretamente dados da empresa a um estranho.
O truque é que o agente nunca quebra nenhuma regra. Cada etapa parece rotineira, então, em uma configuração padrão, nenhum alarme é disparado.
O trabalho vem da equipe de Resposta a Incidentes da Microsoft e de seu time de pesquisa de segurança do Defender, e chega no momento em que as empresas começam a deixar a IA fazer mais do que apenas ler e resumir.
O que muda quando um agente pode agir
Até pouco tempo atrás, o risco da IA no ambiente de trabalho era enquadrado majoritariamente em torno do que um modelo lia e escrevia. Um documento envenenado podia distorcer uma resposta, e era basicamente onde o problema terminava.
Agentes são diferentes. O Microsoft 365 Copilot pode enviar e-mails, criar arquivos e alterar calendários. Agentes personalizados criados no Copilot Studio ou no Azure AI Foundry podem acessar sistemas corporativos e executar tarefas de várias etapas por conta própria.
O mesmo truque de injeção que enviesava um resumo agora dispara uma ação. Contra um leitor, um ataque altera a saída. Contra um agente, altera o que o software realmente faz.
Esses agentes chegam aos sistemas corporativos por meio do MCP, o Protocolo de Contexto de Modelo (Model Context Protocol), um protocolo aberto que permite que uma IA chame ferramentas externas da mesma forma que um aplicativo chama uma API (Interface de Programação de Aplicações). A Microsoft o considera a parte que mais cresce na cadeia de suprimentos da IA agêntica, o que o torna uma superfície de ataque em expansão.
Como o ataque funciona
Toda ferramenta MCP vem com uma descrição: algumas linhas de texto simples que dizem ao agente o que a ferramenta faz e quando usá-la. O agente lê esse texto para decidir como agir. Essa é toda a fragilidade. A descrição é apenas palavras, e palavras podem carregar instruções.
A Microsoft explica o caso com um exemplo de nota fiscal, criado para mostrar o padrão em vez de relatar uma vítima específica. Um time financeiro cria um agente para lidar com notas fiscais de fornecedores. Ele se conecta a três ferramentas, incluindo um serviço de "enriquecimento de notas fiscais" de terceiros, que foi aprovado para uso, mas nunca passou por uma análise de segurança de verdade.
Então o invasor atualiza essa ferramenta de terceiros. O nome e o resumo visível permanecem os mesmos. Escondida na descrição, disfarçada de notas de formatação, está uma ordem oculta: pegar as últimas trinta notas fiscais não pagas e anexá-las à próxima chamada. O MCP capta mudanças na descrição em tempo real. Em configurações sem um gatilho de reaprovação, a versão envenenada entra no ar sem nenhuma análise extra.
Depois disso, um analista faz uma pergunta rotineira sobre um fornecedor. O agente segue a ordem oculta, coleta as notas fiscais e as envia como parte de uma solicitação com aparência normal. A ferramenta devolve uma resposta limpa e copia discretamente os dados roubados para um servidor controlado pelo invasor. O analista não percebe nada de errado.
Cada ação que o agente executa é legítima por si só. A ferramenta foi aprovada. A consulta de dados rodou com as permissões do próprio analista. A chamada de saída foi para um servidor que estava autorizado quando foi adicionado. A fragilidade não está em nenhum sistema isolado. Ela está no que a Microsoft chama de "limite de confiança entre eles".
O problema mais profundo é que o MCP mistura instruções e dados no mesmo lugar. A descrição de uma ferramenta fica na memória de trabalho do agente, bem ao lado de suas ordens reais, então editar essa descrição pode direcionar o agente com a mesma eficiência que reescrever o prompt de sistema.
O agente não tem uma maneira confiável de distinguir uma instrução honesta de uma maliciosa inserida por quem mantém a ferramenta. A Microsoft destaca que isso não é um bug do Copilot em si. É uma lacuna de confiança aberta ao conectar ferramentas externas.
O que os defensores devem fazer
As recomendações da Microsoft, em termos simples:
- Trate cada ferramenta conectada como parte da sua cadeia de suprimentos. Mantenha uma lista de publicadores de ferramentas aprovados, desative o "permitir todos" e deixe um agente usar apenas as ferramentas específicas de que ele precisa.
- Trate a descrição de uma ferramenta como um prompt de sistema. Revise mudanças nela como você revisaria uma alteração de código e analise o texto em busca de comandos que não têm motivo para estar em um campo de ajuda.
- Coloque um humano na frente de ações arriscadas. Qualquer coisa que movimente dinheiro, compartilhe dados fora da empresa ou altere contas deve exigir a aprovação de uma pessoa.
- Dê a cada agente sua própria identidade e monitore o que ele faz. Registre suas ações, defina um padrão de comportamento normal e sinalize novos endpoints, coletas de dados maiores ou consultas estranhas.
- Aplique o princípio do menor poder de atuação, e não apenas o menor privilégio. Mesmo um agente com permissões baixas pode causar danos reais se puder agir sem verificações.
A Microsoft mapeia seus próprios produtos para cada etapa, incluindo Prompt Shields, Purview DLP (Prevenção de Perda de Dados), Entra Agent ID, Defender for Cloud e Sentinel, mas os princípios valem para qualquer stack que você utilize.
Não é teoria: como chegamos aqui
Essa classe de ataque tem um histórico documentado. A Invariant Labs nomeou o "envenenamento de ferramentas" (tool poisoning) em abril de 2025, com uma prova de conceito que escondia instruções na descrição de uma ferramenta de calculadora e fazia o editor Cursor ler a chave SSH (protocolo de acesso remoto seguro) privada de um usuário e enviá-la para fora. O desenvolvedor Simon Willison investigou o caso dias depois.
O mesmo grupo mostrou depois um truque relacionado: uma issue maliciosa no GitHub podia sequestrar um agente conectado ao servidor MCP do GitHub e extrair dados de repositórios privados. As ferramentas ali eram confiáveis e não tinham sido alteradas; as instruções maliciosas vieram embutidas nos dados que o agente lia.
A OWASP (Projeto Aberto de Segurança de Aplicações Web) agora cita esse caso como exemplo de Vulnerabilidades na Cadeia de Suprimentos Agêntica em seu Top 10 para Aplicações Agênticas de dezembro de 2025.
Uma falha de cadeia de suprimentos relacionada já aconteceu na vida real. Em setembro de 2025, pesquisadores da Koi Security encontraram um pacote npm (gerenciador de pacotes do Node.js) chamado postmark-mcp. Ele tinha espelhado uma ferramenta legítima de e-mail por quinze versões limpas antes de a versão 1.0.16 incluir uma linha que secretamente adicionava um BCC (cópia oculta) em todos os e-mails que um agente enviava para um invasor. A Koi o chamou de primeiro servidor MCP malicioso do mundo real.
Pesquisadores acadêmicos também começaram a medir o problema. O benchmark MCPTox, lançado em agosto de 2025, executou descrições de ferramentas envenenadas contra 45 servidores MCP reais e 20 modelos de IA de ponta. Ele descobriu que o ataque é amplamente eficaz, com uma taxa de sucesso de até 72,8%, e os modelos quase nunca se recusaram a executar.
O fio condutor é justamente o que a Microsoft está destacando agora. Uma IA que pode agir só é tão confiável quanto as ferramentas que você deixa ela tocar, e, neste momento, essas ferramentas são fáceis de envenenar e difíceis de monitorar.
