Seu plugin de IA trabalha para quem? Como auditar MCPs e extensões

Tempo estimado de leitura: 10 minutos.

Você instala uma extensão, conecta um servidor MCP e, poucos minutos depois, a IA consegue consultar documentos, abrir tarefas e mexer no projeto. A demonstração funciona. A pergunta que costuma chegar atrasada é bem menos animadora: quais dados essa ferramenta consegue acessar e para onde eles podem ir?

No trabalho com integrações na Oombe, uma preocupação acompanha qualquer funcionalidade: o que aquele acesso permite fazer na conta conectada. Com agentes de IA, essa preocupação ganha novos caminhos. Um recurso que parece apenas ajudar a escrever código pode participar de uma sequência envolvendo arquivos, credenciais, serviços externos e modelos de diferentes fornecedores.

O botão “instalar” é pequeno. A lista de decisões escondida atrás dele pode ser bem grandinha.

A boa notícia é que dá para organizar essa análise sem transformar toda instalação em uma investigação de cinema. O começo é separar problemas diferentes, porque cada um pede evidências e controles próprios.

Três problemas que merecem nomes diferentes

Software malicioso é aquele preparado para executar uma ação indevida. Imagine uma ferramenta fictícia que promete resumir chamados, mas também envia cópias a um endereço externo. A operação aparentemente útil serve de embalagem para a operação escondida.

Software vulnerável pode ter uma finalidade legítima e uma falha explorável. Um erro de autorização, por exemplo, poderia permitir que uma pessoa consultasse informações de outra. Nesse caso, corrigir a falha e entender o alcance da exposição exige trabalho diferente de investigar uma intenção maliciosa.

Lacuna contratual acontece quando a documentação não explica suficientemente o tratamento realizado. Um fornecedor pode usar serviços adicionais sem descrevê-los de forma clara. Isso exige esclarecimento e avaliação, mas não permite concluir automaticamente que houve vazamento.

Essas situações podem se combinar. Ainda assim, chamar tudo de “MCP malware” atrapalha o diagnóstico. Também facilita uma conclusão confortável demais: trocar a ferramenta e acreditar que a governança ficou resolvida.

O OWASP LLM03:2025 inclui dependências, componentes e modelos de terceiros na discussão sobre cadeia de suprimentos de IA. Esse enquadramento ajuda a enxergar a aplicação como um conjunto de relações, com responsabilidades distribuídas.[1]

O MCP conecta ferramentas; a confiança precisa ser construída

O ponto interessante de um agente é poder agir sobre sistemas. Isso também exige perguntar quem definiu a ferramenta, quais instruções ela apresenta ao modelo e quais ações o ambiente efetivamente permite.

Em abril de 2025, a Invariant Labs demonstrou ataques de tool poisoning: instruções maliciosas inseridas em descrições de ferramentas podiam influenciar o agente. A demonstração registra uma classe de risco; não comprova que todo cliente atual tenha a mesma vulnerabilidade.[2]

Pense em uma recepção que recebe bilhetes de fornecedores. Um bilhete pode informar o horário de uma entrega. Isso não deveria autorizá-lo a mudar quem tem acesso ao cofre. Em um sistema com IA, essa separação precisa existir também nos controles externos ao modelo.

A documentação draft de segurança do MCP aborda autorização, isolamento e validação do destinatário dos tokens, além de proibir token passthrough inadequado. Ela também diferencia riscos de determinadas arquiteturas de proxy do transporte stdio em si.[3]

A consequência prática é direta: um aviso escrito no prompt não substitui permissões aplicadas pelo sistema. Se uma ferramenta só precisa consultar uma informação, o desenho deve restringir o que ela consegue consultar e impedir alterações desnecessárias.

O contrato conta a mesma história que a arquitetura?

Um levantamento da DataGrail, publicado em 2026, reportou que 63,6% dos fornecedores avaliados no levantamento não divulgavam subprocessadores de IA de terceiros na documentação jurídica. A empresa descreve o cruzamento de contratos com evidências como integrações, atividade no GitHub e páginas comerciais.[4]

O número pede atenção, mas precisa manter seu significado. Ele aponta uma lacuna de transparência no levantamento de um fornecedor comercial. Não significa que 63,6% das ferramentas vazaram dados, nem comprova o destino de cada solicitação processada.

Para avaliar um produto específico, eu começaria com perguntas objetivas: quais empresas recebem dados; em quais situações; por quanto tempo; com quais condições de uso; e como mudanças serão comunicadas.

Um detalhe merece lugar nessa conversa: o fallback. Se o modelo principal estiver indisponível, o serviço poderá chamar outro? Essa alternativa precisa estar dentro da política aprovada. Vale definir provedores permitidos, categorias de dados autorizadas e comportamento quando nenhuma opção aceita estiver disponível.

Esse tema conversa com as diferenças entre Política de Privacidade e Termos de Uso. Documentação clara ajuda a estabelecer expectativas; a implantação precisa sustentar essas expectativas.

O que o Bumblebee ajuda a descobrir

O Bumblebee, da Perplexity, coleta metadados locais de pacotes, extensões e determinadas configurações de ferramentas em macOS e Linux. Opera em modo somente leitura e compara o inventário com catálogos de exposições conhecidas. Seu escopo não equivale a um detector universal de malware ou a uma auditoria de contratos.[5]

Isso é útil para uma pergunta bem específica: “temos o componente ou a versão citada neste alerta?”. Um inventário organizado reduz o trabalho de procurar essa resposta máquina por máquina.

Mas há outras perguntas: a ferramenta enviou dados? O destino estava autorizado? A credencial permitia acesso demais? O contrato descrevia o processamento? Cada uma exige evidência adicional.

Como uso Windows no dia a dia, eu também verificaria a cobertura antes de transformar uma ferramenta em recomendação operacional. Um procedimento apresentado para Linux não deve ser vendido como auditoria completa de uma estação Windows. O objetivo é mapear o ambiente real, inclusive os pontos que o scanner não cobre.

Uma auditoria que começa com perguntas respondíveis

O primeiro entregável pode ser uma tabela simples. Para cada ferramenta, registre responsável, origem, versão, finalidade, acesso concedido, destinos esperados e data da última revisão. Depois, avance por seis perguntas.

1. Quem mantém este software? Confira o caminho entre a página oficial, o repositório e o pacote instalado. Nomes parecidos ajudam a encontrar coisas; sozinhos, não demonstram procedência. Registre como a identidade foi verificada e quem acompanha futuras atualizações.

2. Quais recursos ele realmente precisa? Compare a tarefa com as permissões. Uma ferramenta usada para ler documentação precisa de acesso de escrita ao projeto inteiro? Precisa das mesmas credenciais empregadas em produção? Toda capacidade extra merece uma justificativa operacional.

3. Quais dados atravessam a integração? Desenhe uma solicitação do início ao fim. Inclua anexos, trechos de código e resultados retornados. Considere também componentes auxiliares: registro de erros, suporte e observabilidade podem participar do fluxo.

4. Quais destinos são permitidos? Documente provedores, serviços e condições de fallback. Sempre que viável, faça essa política valer no ambiente de execução. Um texto dizendo “use apenas o provedor aprovado” deixa uma pergunta em aberto: o que impede outra chamada?

5. Como as mudanças chegam? Defina quem revisa atualização de pacote, mudança de ferramenta e ampliação de permissão. A aprovação inicial perde parte do valor se alterações posteriores entrarem sem qualquer acompanhamento.

6. Como interromper e recuperar? Saiba revogar a credencial, desabilitar a integração, preservar evidências necessárias e identificar operações afetadas. O procedimento deve caber na realidade da equipe. Um plano impossível de executar às três da tarde dificilmente ficará mais fácil às três da manhã.

Essas respostas formam um retrato verificável. O resultado também revela prioridades: primeiro corrigir os acessos e fluxos de maior impacto, depois aprofundar o restante.

Um exemplo próximo de quem trabalha com marketplaces

Imagine um assistente fictício para uma operação de comércio eletrônico. Ele lê dúvidas de clientes, consulta informações do pedido e prepara uma resposta. A proposta faz sentido. Agora coloque todas essas funções atrás de uma única credencial capaz também de alterar anúncios e configurações da conta.

O problema arquitetural aparece antes de qualquer ataque: a capacidade concedida excede a tarefa descrita.

Uma alternativa seria separar consulta de pedido, acesso à base de conhecimento e preparação de resposta. O envio teria uma regra própria. Alterações comerciais ficariam em outro fluxo, com permissões e validações específicas.

Se o assistente receber um texto estranho em uma mensagem, essa separação reduz o conjunto de ações disponíveis. A pergunta deixa de ser apenas “o modelo vai entender corretamente?” e inclui “qual consequência o sistema permite se ele interpretar errado?”.

O exemplo é hipotético, não um relato de incidente na Oombe. A experiência com integrações serve para formular a pergunta certa: quais capacidades estamos delegando, a quem e em quais condições?

Um teste pequeno que rende evidência útil

Antes de levar um ambiente sensível ao laboratório, monte um projeto de demonstração com documentos e credenciais fictícios. Defina duas ferramentas: uma pode ler uma pasta de exemplos; a outra consulta uma API de teste com escopo limitado.

Prepare tarefas esperadas e situações fora do escopo. Verifique se o agente consegue solicitar uma ação indevida, se o ambiente bloqueia essa ação e se o registro permite entender o que ocorreu. Também simule a indisponibilidade do provedor principal: o fallback respeita a lista permitida?

Registre o resultado sem atalhos: tentativa solicitada, decisão de autorização, execução efetiva e destino. Uma ação sugerida pelo modelo e uma ação executada têm consequências diferentes.

Esse exercício não certifica segurança completa. Ele produz evidências para um conjunto definido de requisitos e ajuda a localizar controles que estavam apenas no discurso.

O serviço que vale entregar

Para quem pretende oferecer consultoria, há uma entrega concreta aqui: inventário, mapa de dados, matriz de permissões, análise das condições contratuais e plano de correção priorizado. A revisão jurídica pode exigir participação especializada; o trabalho técnico precisa mostrar o que a arquitetura realmente faz.

O valor está em reduzir incertezas de uma operação específica. Prometer que um scanner “garante segurança” cria uma expectativa que ele não consegue sustentar.

Na discussão sobre privacidade e poder sobre os dados, a pergunta prática continua sendo quem consegue fazer o quê. Agentes ampliam a utilidade das integrações. Nossa responsabilidade é fazer os limites crescerem junto.

Antes de instalar a próxima maravilha, vale reservar cinco minutos para uma pergunta: se essa ferramenta agir fora do esperado, o ambiente consegue impedi-la? A resposta costuma dizer mais sobre a maturidade do projeto do que a beleza da demonstração.

Fontes e leituras

1. OWASP — LLM03:2025 Supply Chain.
2. Invariant Labs — MCP Security Notification: Tool Poisoning Attacks, abril de 2025.
3. Model Context Protocol — Security Best Practices, documentação draft.
4. DataGrail — discussão do Privacy & AI Trends Report 2026, junho de 2026.
5. Perplexity — repositório oficial do Bumblebee.

Fontes consultadas em 26 de outubro de 2026. Recursos, cobertura e recomendações de segurança devem ser conferidos na versão adotada.