Pentest MCP: Escopo, Riscos e O Que Testar

Resumo:

• Um Pentest MCP avalia a cadeia entre host, clients, servidor, tools, dados e sistemas conectados.
• Um pentest tradicional de API cobre parte dos riscos, mas não substitui o MCP security testing quando há tool calling, prompt injection, agentic workflows ou autorização mediada pelo modelo.
• O escopo deve incluir, conforme a arquitetura, autenticação, OAuth, autorização, ferramentas, recursos, prompts, outputs, egress, filesystem, supply chain, logging e detecção.
• A avaliação faz mais sentido antes de produção, após mudanças relevantes e quando agentes passam a acessar dados, APIs ou comandos com impacto real.
• O objetivo é validar se uma condição pode ser explorada e qual impacto ela produz no ambiente.

O Model Context Protocol (MCP) criou uma forma padronizada de conectar aplicações de IA a ferramentas, dados, APIs e outros sistemas. O mesmo mecanismo que torna os agentes mais úteis também amplia a superfície de ataque: uma tool pode ler arquivos, consultar um banco, chamar uma API ou executar uma ação real em nome do usuário.

Por isso, um Pentest MCP, além de verificar se o servidor responde corretamente ou se a API está protegida, também deve validar até onde um client, um agente ou uma tool pode ser manipulado para agir além do esperado. 

Isso inclui testar autenticação, autorização, tool schemas, conteúdo não confiável, credenciais, sistemas conectados e os fluxos que ligam todos esses componentes.

O que é um Pentest MCP?

Um Pentest MCP é uma avaliação ofensiva de uma implementação de Model Context Protocol. Em vez de olhar apenas para uma aplicação ou API isolada, o teste considera a cadeia que conecta o usuário ao host de IA, ao MCP client, ao MCP servidor, às tools e aos sistemas de destino.

Essa leitura acompanha a própria especificação atual do MCP, que descreve hosts, clientes e servidores como participantes distintos e reconhece que o protocolo habilita o acesso a dados e os caminhos de execução com implicações relevantes de segurança. A especificação também deixa claro que o consentimento, o controle de acesso, a proteção de dados e a segurança das tools dependem da implementação; o protocolo, sozinho, não consegue impor esses princípios.

O OWASP MCP Security Testing Guide trata o MCP como uma barreira de segurança que vai do usuário ao sistema de destino. O guia reúne testes para clients e hosts, servidores, tools, recursos, prompts, transportes, autorização, supply chain, gateways, workflows agentic, logging e detecção. É uma boa referência externa para entender por que o MCP security testing exige um escopo mais amplo do que uma checagem de configuração.

Pentest de API é suficiente?

Só em parte. Um pentest de API continua sendo essencial para validar o básico de segurança, como autenticação, autorização, injeções e lógica de negócio. Em MCP, porém, o risco muda: o modelo decide quais tools chamar, o conteúdo de entradas/saídas pode manipular o agente, as permissões se encadeiam e as ações legítimas podem causar estragos fora de contexto.

O próprio OWASP MCP Security Testing Guide diferencia os dois cenários. Em uma API tradicional, o teste costuma focar em parâmetros, sessões e autorização direta; em MCP, entram também a manipulação de tool schemas, dynamic tool lists, tokens armazenados pelo host, approval flows, tool chaining, planner loops e conteúdo retornado ao modelo.

Se o MCP apenas encapsula uma API, parte do risco ainda está na API. Mas, quando a aplicação de IA descobre tools, recebe conteúdo externo, decide ações ou opera com credenciais e permissões próprias, a avaliação precisa acompanhar esse fluxo completo.

O que deve ser testado?

O escopo depende da arquitetura, mas uma avaliação madura precisa esclarecer um ponto crítico: o que um agente ou atacante conseguiria fazer a partir do acesso disponível?

• Hosts e clients

O host é a aplicação de IA com a qual o usuário interage; o client mantém a conexão com um servidor MCP. Aqui, o teste deve observar a configuração, o consentimento, as trust decisions, os tratamento de sessões, o armazenamento de tokens e como o host apresenta ou aprova chamadas de tools. 

Um fluxo de aprovação que parece existir na interface, por exemplo, não é suficiente se puder ser contornado por outra rota ou se esconder parâmetros sensíveis do usuário.

• MCP servidors

No servidor, entram controles clássicos e específicos: exposição do endpoint, autenticação, autorização, transportes, tratamento de requests, validação de argumentos, rate limits e isolamento. Em servidores remotos, também vale testar audience, issuer, scopes, resource binding e outras condições do fluxo OAuth. Em servidores locais, filesystem, processo, rede e credenciais do desenvolvedor podem ampliar drasticamente o impacto.

• Tools e schemas

As tools não são apenas funções disponíveis ao modelo. Suas descrições, parâmetros, schemas e metadados também fazem parte da superfície de ataque. O teste deve verificar se uma tool consegue ser manipulada, sombreada, alterada ou chamada com argumentos fora do esperado. Se tools amplas demais permitem executar ações que deveriam estar separadas, e se mudanças de definição passam sem nova revisão ou consentimento.

A OWASP MCP Security Cheat Sheet destaca riscos como tool poisoning, rug pull, tool shadowing, confused deputy, permissões excessivas e supply chain. Esses cenários mostram por que o teste precisa olhar para a definição da tool e para o que ela realmente executa.

• Autenticação e autorização

Autorização em MCP raramente é uma única checagem. Pode existir uma fronteira entre usuário e host, outra entre client e servidor, outra na própria tool e ainda uma regra adicional no sistema de destino. Por isso, a avaliação deve mapear roles, scopes, tenants, objetos, operações de leitura e escrita e credenciais usadas em cada etapa.

Entre os testes sugeridos pelo guia de security testing estão matrizes de autorização por tool, role, scope, tenant, objeto e fronteira read/write, além de cenários com IDs válidos pertencentes a outros usuários. Em OAuth, também entram validações de audience, issuer, resource, scope, assinatura, expiração, redirect URI, state e PKCE.

• Recursos, prompts e outputs

Conteúdo retornado por uma tool não deve ser tratado automaticamente como confiável. Um documento, ticket, e-mail, página, log ou arquivo pode conter instruções maliciosas que o modelo interpreta como comando. Isso cria uma rota de prompt injection indireta mesmo quando o usuário nunca digitou uma instrução perigosa.

Por isso, o teste deve observar se outputs externos são rotulados como não confiáveis, se segredos são filtrados, se conteúdos muito grandes são limitados, se campos inesperados são rejeitados e se uma resposta de uma tool consegue influenciar silenciosamente a próxima ação. Esse tipo de cadeia é especialmente importante quando o agente pode reutilizar dados sensíveis em outra integração.

• Sistemas conectados

O impacto de uma falha MCP depende do que existe do outro lado. Uma tool pode acessar um CRM, um banco de dados, um repositório, um serviço cloud, um terminal ou um sistema interno. O pentest precisa validar não apenas se a chamada é possível, mas se o acesso está limitado ao que a função realmente necessita.

Aqui entram cenários de SSRF, command injection, path traversal, consultas excessivas, egress para destinos não autorizados, leitura de arquivos e uso indevido de credenciais. O ponto não é testar cada integração como se fosse um produto separado, e sim entender como a combinação entre MCP e sistema downstream muda o risco.

• Workflows agentic

Uma ação isolada pode parecer segura e ainda assim participar de uma cadeia perigosa. Um agente pode ler um documento, extrair um valor, chamar uma segunda tool e depois usar o resultado em um terceiro sistema. O teste deve avaliar essas sequências, inclusive loops, retries, escalada de privilégios e aprovação de ações sensíveis.

Esse é um dos pontos em que MCP security e pentest em sistemas de inteligência artificial se encontram: a segurança depende tanto do protocolo quanto do comportamento do agente quando recebe contexto potencialmente malicioso.

• Logs e detecção

Uma avaliação ofensiva também pode verificar se o ambiente registra o que importa: conexão, identidade, servidor, tool descoberta, tool chamada, decisão de aprovação, argumentos relevantes, políticas aplicadas e outputs filtrados. Sem esse contexto, uma ação indevida pode ocorrer sem que o time consiga reconstruir o caminho ou responder rapidamente.

Quais riscos merecem atenção?

Não existe uma única vulnerabilidade “de MCP”. O risco nasce da combinação entre protocolo, implementação, modelo e sistemas conectados. Entre os cenários mais relevantes estão:

• Tool poisoning: instruções maliciosas escondidas em descrições, schemas ou metadados que influenciam o modelo.
• Prompt injection indireta: conteúdo malicioso em documentos, tickets, páginas, e-mails ou outputs que alteram o comportamento do agente.
• Permissões excessivas: servidores ou tools com acesso administrativo quando a função exige apenas leitura ou um subconjunto de ações.
• Confused deputy: um componente com privilégios maiores executa uma ação em nome de quem não deveria ter aquele acesso.
• Tool shadowing e cross-servidor abuse: um servidor malicioso interfere na forma como o agente interpreta ou usa tools de outro servidor confiável.
• Secret leakage: tokens, chaves, cookies, credenciais cloud ou variáveis de ambiente entram no contexto, logs ou respostas.
• SSRF e egress indevidos: tools que recebem URLs ou destinos permitem alcançar serviços internos, metadata endpoints ou hosts não autorizados.
• Command injection e path traversal: argumentos gerados pelo modelo chegam a shell, filesystem ou banco sem validação suficiente.
• Supply chain e rug pull: um pacote, servidor ou definição de tool muda depois de aprovado e passa a executar comportamento não esperado.
• Tool chaining: ações individualmente permitidas são combinadas para produzir um resultado que não deveria ser autorizado.

O valor do pentest está justamente em sair da lista abstrata de riscos e validar quais deles são exploráveis no contexto real da empresa.

Quando fazer um Pentest MCP?

Nem toda prova de conceito precisa de um pentest completo. A prioridade aumenta quando o MCP deixa de ser experimental e começa a ter acesso real a dados, credenciais, sistemas ou ações. Alguns momentos merecem atenção especial:

• Antes de colocar um MCP servidor ou integração relevante na produção.
• Quando um agente passa a acessar CRM, ERP, banco de dados, repositório, e-mail, cloud, terminal ou outros sistemas críticos.
• Após adicionar novas tools, servidores, clients ou fluxos de autorização.
• Quando permissões, escopos ou credenciais foram ampliados para suportar novos casos de uso.
• Quando o agente passa a executar ações com menos intervenção humana.
• Depois de mudanças relevantes em OAuth, autenticação, isolamento, gateway ou arquitetura.
• Antes de disponibilizar um servidor MCP a clientes, parceiros ou múltiplos tenants.
• Como validação após incidentes, achados internos ou mudanças relevantes de threat model.

Também é importante testar contra a versão efetivamente implantada. O MCP evolui rapidamente, e o próprio guia de security testing recomenda citar a versão da especificação sob o teste. Isso evita avaliar controles com base em requisitos que mudaram entre as revisões do protocolo.

Como definir o escopo?

Um bom escopo começa pelo mapeamento do fluxo real, não por uma lista genérica de testes. Antes de começar, é preciso saber quais componentes existem, quem confia em quem e qual impacto cada conexão pode gerar.

Esse mapeamento também evita dois erros comuns: limitar o teste ao servidor e ignorar o agente, ou tentar testar “todo o ambiente de IA” sem uma fronteira clara. O Pentest MCP precisa ser amplo o suficiente para capturar a cadeia de confiança, mas específico o suficiente para produzir uma evidência reproduzível e uma recomendação acionável.

O que exigir do fornecedor?

Como o mercado ainda está formando referências para MCP security testing, o nome do serviço diz menos do que a metodologia. Antes de contratar, vale confirmar se a avaliação inclui:

• Threat modeling da arquitetura MCP antes da exploração.
• Testes no protocolo, no servidor, no client e no comportamento do agente quando aplicável.
• Validação de autenticação, OAuth, autorização e isolamento entre usuários ou tenants.
• Testes de tool poisoning, prompt injection indireta e manipulação de tool schemas e outputs.
• Análise de sistemas downstream, permissões, credenciais e caminhos de impacto.
• Testes manuais, além de scanners e checklists automatizados.
• Evidências de exploração reproduzíveis e contexto de negócio para priorização.
• Recomendações específicas para correção, não apenas descrições genéricas do risco.
• Reteste para confirmar que o caminho de exploração foi efetivamente eliminado ou reduzido.

Outro bom sinal é a capacidade de explicar o limite da avaliação. Um fornecedor sério deve deixar claro quais servidores, clients, tools, dados e integrações entraram no escopo, quais ações foram permitidas e qual versão da especificação foi considerada.

Teste o que seu MCP realmente permite

Uma integração MCP pode estar funcionando exatamente como foi projetada e, ainda assim, permitir ações que ninguém pretendia autorizar. É essa diferença entre funcionar e resistir ao abuso que o Pentest MCP da Vantico procura validar.

A avaliação começa pelo que existe de verdade no ambiente: servidores, clients, fluxo do agente, tools, credenciais e sistemas conectados. A partir desse mapa, os testes procuram responder perguntas que um checklist sozinho não consegue resolver:

• Uma instrução maliciosa consegue alterar o comportamento esperado do agente?
• Uma tool legítima pode ser usada para produzir um impacto não previsto?
• Permissões, tokens ou credenciais permitem avançar além do necessário?
• A combinação entre servidor, agente e sistema conectado cria um caminho que não aparece quando cada componente é analisado isoladamente?

O processo inclui kickoff e mapeamento, modelagem de ameaças, testes no protocolo e no servidor, testes no agente, relatório com recomendações e reteste. Os achados são documentados com evidências e passos de reprodução, e a entrega pode incluir Carta de Atestado para apoiar clientes, auditorias e processos de due diligence.

Se o seu MCP já tem acesso a dados, APIs ou comandos reais, a pergunta não é apenas se ele funciona. É até onde esse acesso pode ser levado quando alguém tenta sair do caminho esperado.

Conheça o Pentest MCP da Vantico e converse com nosso time sobre o escopo da avaliação.

FAQ: Perguntas frequentes sobre pentest MCP

O que é um Pentest MCP?

É uma avaliação ofensiva de uma implementação de Model Context Protocol que testa servidor, client, tools, autenticação, autorização, conteúdo, integrações e os sistemas que podem ser alcançados por meio deles. O objetivo é validar o que alguém conseguiria fazer a partir do acesso disponível, e não apenas revisar configurações.

Pentest de API é suficiente para MCP?

Não necessariamente. Um pentest de API cobre riscos importantes de autenticação, autorização, injeção e lógica de negócio, mas MCP adiciona superfícies como tool schemas, outputs não confiáveis, prompt injection, tool chaining, approval flows e workflows agentic.

O que deve ser testado em um Pentest MCP?

O escopo pode incluir hosts, clients, servidores, tools, recursos, prompts, OAuth, permissões, credenciais, transportes, outputs, filesystem, egress, sistemas downstream, supply chain, logs e detecção. A combinação exata depende da arquitetura e do impacto permitido pelas integrações.

Prompt injection faz parte de um Pentest MCP?

Sim, quando o ambiente permite que conteúdo não confiável influencie o modelo ou o uso de tools. A avaliação pode testar prompt injection direta e indireta em recursos, tool outputs, documentos, páginas, tickets, e-mails e outras fontes de contexto.

É necessário testar MCP client e MCP servidor?

Quando ambos fazem parte da arquitetura e influenciam a decisão ou execução das tools, sim. O servidor concentra parte dos controles, mas o client e o host também participam de consentimento, trust decisions, armazenamento de tokens, rendering e aprovação de ações.

Quando uma empresa deve fazer um Pentest MCP?

A prioridade aumenta antes de produção, quando agents passam a acessar sistemas sensíveis, após mudanças de tools ou permissões, antes de expor um servidor MCP a terceiros e sempre que uma alteração relevante muda a cadeia de confiança ou o possível impacto do ambiente.

Em MCP, a segurança não termina no protocolo. Ela depende de como identidades, tools, dados, agentes e sistemas reais se conectam. Um Pentest MCP bem definido torna essa cadeia testável e mostra onde uma ação legítima pode se transformar em um caminho de ataque.