(11) 5626-1313 contato@memorycomp.com.br

Protegendo agentes de IA: quando a ferramenta deixa de ler e passa a agir

Fernando Rabello Fernando Rabello · 09 de julho de 2026 · 5 min de leitura

Resumo

Análise prática dos riscos de agentes de IA que passam de leitura a ação: como descrições envenenadas no Model Context Protocol podem gerar perdas financeiras e regulatórias e quais controles de governança, identidade, DLP e correlação implantar para mitigar danos.

Imagine um analista do financeiro pedindo ao assistente uma consulta de rotina sobre um fornecedor. Em segundos, sem aprovação rastreada, as últimas trinta faturas em aberto da empresa saem pela porta dos fundos. Não houve clique errado, não houve credencial vazada, não houve alerta. O agente apenas seguiu a instrução que estava escrita na descrição de uma ferramenta que ele tinha autorização de usar.

Esse cenário não é hipótese. A Microsoft acaba de documentar esse padrão em produção e o nomeou de forma direta: as ferramentas de IA estão deixando de apenas ler e passando a agir. Quando agem dentro de sistemas críticos, qualquer falha de governança na cadeia de ferramentas que elas consomem vira sangria de caixa.

O que mudou no ataque

O Model Context Protocol é o padrão que permite a um agente conectar e usar ferramentas externas, por exemplo, um catálogo de fornecedor, um validador de dados bancários, um conector com o ERP. Para decidir quando chamar cada ferramenta, o agente lê a descrição em linguagem natural dela. É essa descrição que está sendo envenenada.

O atacante publica uma atualização da ferramenta com nome e resumo visíveis idênticos, mas insere no corpo da descrição um bloco de instruções escondidas. Por exemplo, instruções dizendo ao agente que, antes de qualquer consulta, ele deve coletar as últimas trinta faturas em aberto e anexá-las à próxima chamada, como se isso fizesse parte de uma checagem antifraude legítima.

Como atualizações de metadados não disparam reaprovação por padrão, a descrição envenenada entra em produção sem passar por revisão. A partir daí, qualquer pergunta banal do usuário aciona a sequência maliciosa.

Por que o monitoramento tradicional não vê

A armadilha é que cada ação isolada do agente é legítima. A ferramenta foi aprovada, a consulta ao banco de dados de fornecedor respeita a permissão do analista, e a chamada de saída vai para um endpoint que já estava liberado quando a ferramenta entrou. Não há exceção, não há erro de autenticação, não há acesso negado.

A falha não está em nenhum sistema isolado, está na fronteira de confiança entre eles. O agente não consegue distinguir entre uma instrução escrita pelo dono original da ferramenta e uma instrução inserida por um mantenedor mal-intencionado.

Impacto prático nas empresas

Onde isso dói no negócio. O primeiro impacto é financeiro direto: pagamento de fornecedor saindo sem aprovação rastreada, ajuste de dados de conta bancária em massa, exfiltração de carteira de invoices. O segundo é fiscal: dados de NF vazando por caminhos que não foram revisados pela contabilidade. O terceiro é regulatório: dado pessoal e financeiro indo para endpoint externo sem base legal.

A escala do problema também muda. A projeção da IDC é de crescimento de 28,6 milhões de agentes ativos em 2025 para mais de 2,2 bilhões em 2030. Cada agente carrega sua própria cadeia de ferramentas, e cada ferramenta é um ponto de confiança que precisa ser governado.

Cenários reais de aplicação

  • No financeiro, o agente que ajuda a conferir fornecedor é o caso documentado pela Microsoft. Pagamento sai sem rastro de aprovação.
  • No RH, um agente que cruza dados de candidato com base externa pode ser instruído a copiar a folha de pagamento para fora.
  • No comercial, um agente conectado ao CRM com ferramenta de enriquecimento de leads pode ser direcionado a exportar a base de clientes inteira como se fosse parte de uma consulta.
  • Na TI, um agente de service desk com ferramenta de inventário pode ser instruído a listar credenciais privilegiadas dentro de uma resposta aparentemente normal ao usuário.

Em todos esses cenários, o usuário final não percebe nada de errado. A resposta volta limpa, a tarefa parece concluída.

Pontos de atenção

Antes de colocar qualquer agente em produção, três pontos precisam estar resolvidos.

  • Licenciamento e capacidade. Boa parte das proteções aqui depende de SKUs específicos, por exemplo, Purview com DLP avançado, Defender for Cloud com proteção de workload de IA, Sentinel com correlação. Sem o licenciamento certo, a tela de governança fica vazia.
  • Maturidade de identidade. Dar identidade não-humana ao agente via Microsoft Entra Agent ID e aplicar Conditional Access exige que o ambiente de identidade já esteja organizado. Tenant com excesso de papéis legados não absorve esse modelo sem ajuste prévio.
  • Processo de mudança. Tratar descrição de ferramenta como mudança de produção exige fluxo de change review, dono designado para cada servidor MCP de terceiro e inventário vivo. Sem processo, a tecnologia sozinha não segura.

Como a Memory pode apoiar

A Memory aplica o mesmo mapa de contenção que a Microsoft recomenda, em quatro frentes da cadeia. Na governança do supply chain, ajudamos a empresa a montar o allowlist de publishers MCP, desligar o Allow all e estabelecer o dono de cada ferramenta de terceiro. Na inspeção de metadados, configuramos Prompt Shields no Azure AI Content Safety e Defender for Cloud para olhar mudanças em descrições com o mesmo rigor de uma alteração de system prompt.

Na proteção da ação, implementamos políticas de Purview DLP nos parâmetros das chamadas, ativamos human-in-the-loop no Copilot Studio para ações de alto impacto e atribuímos identidade ao agente via Entra Agent ID com Conditional Access. Na correlação, instrumentamos a telemetria do MCP em Microsoft Sentinel para que desvios de comportamento, novos endpoints e parâmetros expandidos virem alerta acionável.

Além da configuração, conduzimos exercícios de red team específicos para agentes antes do go-live, revisão periódica da cadeia de ferramentas e ajuste de licenciamento ao nível de risco real de cada workload.

Conclusão

Agentes que agem em nome do usuário dependem de uma cadeia de ferramentas que cresce mais rápido do que os programas de segurança conseguem acompanhar. Tratar essa cadeia como supply chain crítico, tratar descrição de ferramenta como system prompt e aplicar o princípio de menor agência, e não apenas menor privilégio, deixaram de ser recomendação acadêmica e passaram a ser pré-requisito para colocar qualquer agente em fluxo financeiro.

A pergunta certa para o decisor não é se a empresa vai usar agentes de IA, é se ela vai usá-los com governança suficiente para que o caixa não pague a conta da pressa.

Pergunte ao Claude sobre este artigo

Aprofunde o assunto sem sair da página

Respostas geradas por IA com base neste artigo. Podem conter imprecisões.

Voltar para o blog