OWASP MCP Top 10: cada risco explicado com exemplos

Um único servidor MCP pode entregar a um agente de IA seus repositórios, sua caixa de entrada e seu banco de dados em uma tarde, e aprová-lo muitas vezes leva um único clique. Essa comodidade é exatamente o que o OWASP MCP Top 10 existe para frear. Ele lista os dez riscos com mais chances de afundar uma implantação do Model Context Protocol, desde tokens vazados até servidores que ninguém da equipe de segurança conhece. Este artigo percorre cada item na ordem, mostra como é o ataque com um exemplo real ou documentado e fecha cada seção com a correção que vale a pena fazer primeiro.

A lista vem do projeto OWASP MCP Top 10, versão 2025, liderado por Vandana Verma Sehgal. A página do projeto atualmente o classifica em fase de testes beta e piloto, então a redação e a ordem ainda podem mudar. Trate os dez itens como um vocabulário comum, e não como um padrão finalizado.

O que é o OWASP MCP Top 10

MCP é o protocolo que permite a um modelo chamar ferramentas. Um cliente MCP (o aplicativo que hospeda o modelo) se conecta a um ou mais servidores MCP, e cada servidor expõe ferramentas, recursos e prompts que o modelo pode usar. Cada uma dessas conexões é uma decisão de confiança: o servidor confia que o cliente vai se comportar, o cliente confia nas descrições e saídas do servidor, e o modelo confia em qualquer texto que chegue à sua janela de contexto.

O Top 10 mapeia os pontos em que essa confiança se quebra. Aqui estão os dez de relance:

💡 Nota sobre o nome: a página de visão geral do projeto rotula o sexto item como "Prompt Injection via Contextual Payloads", enquanto a página de detalhes do MCP06 tem o título "Intent Flow Subversion". Ambos apontam para a mesma posição, e este artigo usa o título da página de detalhes.

Segredos, permissões e ferramentas envenenadas

MCP01: Gestão inadequada de tokens e exposição de segredos

Este é o problema mais antigo da segurança, com roupa nova. Segredos de API embutidos no código, tokens de longa duração e credenciais coladas em prompts ou arquivos de configuração acabam em logs, no histórico de conversas e na memória do modelo. Quando um segredo está dentro da janela de contexto, basta uma injeção de prompt pedir ao modelo que o repita.

Cenário da OWASP: um desenvolvedor commita um segredo durante os testes, o servidor MCP o lê na inicialização, e o assistente depois o imprime em uma resposta para outra pessoa.

O que fazer:

• Emita tokens de curta duração e escopo restrito em vez de tokens permanentes.
• Rode a varredura de segredos em repositórios e pipelines de CI.
• Mantenha os segredos fora de descrições de ferramentas, prompts de sistema e exemplos de payload.
• Revogue e gere novos imediatamente após qualquer suspeita de exposição.

💡 Dica: segredos com um prefixo fixo são fáceis de caçar. Os segredos de API da PicassoIA começam com pia_sk_, então uma regra de scanner de uma linha pode sinalizá-los em qualquer repositório. Adicione o mesmo tipo de regra para cada provedor que você usa.

MCP02: Escalonamento de privilégios por expansão de escopo

As permissões começam restritas e vão se afrouxando com o tempo. Um token feito para um repositório é ampliado "só para esta sprint", um agente ganha acesso de escrita porque o de leitura era incômodo, e ninguém revoga nada. O modelo acaba com muito mais poder do que qualquer tarefa única exige, então uma instrução ruim causa muito mais dano.

Cenário da OWASP: uma injeção de prompt escondida em uma issue pública do GitHub redireciona um agente com amplo acesso a repositórios, e o agente copia código privado para um pull request público.

O que fazer:

• Projete para privilégio mínimo: um escopo por tarefa, não um escopo por equipe.
• Coloque uma expiração automática em cada concessão.
• Separe as ferramentas de leitura das de escrita para que as aprovações possam ser diferentes.
• Revise as permissões dos agentes em um cronograma fixo, da mesma forma que revisa o acesso das pessoas.

MCP03: Envenenamento de ferramentas

Os modelos escolhem ferramentas lendo seus nomes e descrições, o que torna essas descrições uma superfície de ataque. Uma ferramenta envenenada esconde instruções em seus metadados, esquema ou saída. Em abril de 2025, a Invariant Labs demonstrou o ataque com uma ferramenta inocente de soma cuja descrição oculta mandava o agente ler um arquivo de configuração MCP local e uma chave privada SSH, e depois repassar o conteúdo em um parâmetro extra, enquanto a resposta falava de aritmética.

Uma variante mais perigosa é o rug pull: a ferramenta se comporta bem quando você a aprova e, depois da instalação, muda a descrição.

O que fazer:

• Fixe as versões das ferramentas e guarde um hash de cada descrição no momento da aprovação.
• Emita alerta para qualquer mudança em descrição ou esquema.
• Mostre aos usuários a descrição completa da ferramenta, não um resumo encurtado.
• Prefira ferramentas assinadas de fornecedores que você consegue identificar.

MCP04: Ataques à cadeia de suprimentos e adulteração de dependências

Um servidor MCP é código escrito por outra pessoa, baixado de um registro. Um pacote comprometido ou falso recebe o mesmo acesso que você concede ao verdadeiro. Em setembro de 2025, um pacote npm chamado postmark-mcp copiou uma integração genuína do Postmark e acrescentou uma única linha que enviava uma cópia oculta de cada e-mail de saída para um endereço controlado pelo atacante. Pesquisadores da Koi Security o relataram como o primeiro servidor MCP malicioso visto em uso real, e o texto da Snyk detalha o caso. Ele chegou a cerca de 1.500 downloads por semana antes de ser removido.

O que fazer:

• Mantenha uma lista de materiais de IA (AI bill of materials): cada servidor, sua versão e sua origem.
• Fixe versões exatas e leia o diff antes de cada atualização.
• Instale apenas de fornecedores que você consegue verificar, e prefira versões assinadas.
• Rode a varredura de dependências antes de aprovar um servidor, e execute os desconhecidos em um contêiner sem acesso à rede até que sejam revisados.

MCP05: Injeção de comandos e execução

Agentes montam comandos a partir de texto. Quando esse texto é controlado pelo atacante (um comentário em issue, um nome de arquivo, uma página da web), o shell faz o resto. Segundo o detalhamento da lista feito pela Cycode, a CVE-2025-6514 em mcp-remote tinha pontuação CVSS de 9,6, afetava um pacote com mais de 437.000 downloads e permitia injeção de comandos do sistema operacional. Ela fica na fronteira entre este item e o MCP04.

A diferença entre arriscado e seguro costuma ser uma linha:

import re
import subprocess

# Risky: untrusted text is spliced into a shell string
subprocess.run(f"git log --author={author}", shell=True)

# Safer: fixed command, argument list, validated input, no shell
if not re.fullmatch(r"[A-Za-z0-9._@][A-Za-z0-9 ._@-]{0,63}", author):
    raise ValueError("invalid author")
subprocess.run(["git", "log", "--author", author], shell=False, check=True)

Copiar prompt

O que fazer:

• Prefira APIs parametrizadas a comandos de shell.
• Quando um comando for inevitável, use listas de argumentos e validação rigorosa de entrada.
• Aplique uma política de negação por padrão sobre quais comandos um servidor pode executar.
• Coloque servidores locais em sandbox para que uma injeção bem-sucedida fique dentro de uma caixa pequena.

Intenção sequestrada e portas abertas

MCP06: Subversão do fluxo de intenção

O agente lê uma página da web, uma issue ou um PDF, e esse conteúdo traz instruções. Um modelo não consegue separar de forma confiável dados de comandos, então pode segui-las. O resultado é o sequestro de objetivo: o agente continua parecendo estar fazendo a sua tarefa enquanto serve a outra pessoa.

O caso real mais claro veio da Invariant Labs em maio de 2025, contra o servidor MCP oficial do GitHub. Um atacante abre uma issue maliciosa em um repositório público. Quando o dono pede ao agente que veja as issues abertas, o agente lê a issue, é injetado, puxa dados de repositórios privados para o seu contexto e os publica em um pull request no repositório público. Os pesquisadores chamaram isso de fluxo tóxico de agente, disseram que se tratava de um problema de arquitetura e não de um bug no código do servidor, e suspeitaram que muitas pessoas escolhem uma política de aprovação "sempre permitir", que elimina a verificação humana.

O que fazer:

• Ancore o objetivo original e confira cada ação planejada em relação a ele.
• Adicione um modelo de guarda independente que veja apenas o pedido do usuário e a chamada de ferramenta proposta.
• Marque o conteúdo recuperado como dado não confiável e instrua o modelo a tratá-lo como texto passivo.
• Exija aprovação humana para qualquer coisa que escreva, envie ou apague, e nunca deixe "sempre permitir" como padrão.

💡 Dica: um classificador é uma camada, não a defesa inteira. O Llama Guard 4 12B na PicassoIA é um modelo de moderação de conteúdo que pode filtrar textos antes que cheguem ao seu agente, mas é um classificador de segurança e não um detector dedicado de injeção, então mantenha as aprovações e o privilégio mínimo ativos.

MCP07: Autenticação e autorização insuficientes

Alguns servidores MCP nunca perguntam quem está chamando. Um endpoint exposto sem autenticação permite que qualquer um invoque suas ferramentas, e um servidor que verifica a identidade uma vez, mas nunca verifica as permissões a cada chamada, deixa um usuário de baixo privilégio acionar ações de alto privilégio.

Um caso concreto é a CVE-2025-49596 no MCP Inspector da Anthropic, classificada com CVSS 9,4. As versões abaixo da 0.14.1 não tinham autenticação entre o cliente Inspector e seu proxy, então solicitações não autenticadas podiam executar comandos via stdio. Combinado com uma falha do navegador e com cross-site request forgery, bastava visitar um site malicioso para executar código na máquina de um desenvolvedor.

O que fazer:

• Use OAuth 2.1 com autenticação multifator para pessoas.
• Valide o público do token em cada servidor, para que um token emitido para um servidor falhe em outro.
• Dê aos serviços identidades gerenciadas em vez de contas compartilhadas.
• Restrinja os servidores locais ao localhost e exija um token mesmo ali.
• Verifique as permissões a cada chamada de ferramenta, e não uma vez por sessão.

Pontos cegos e servidores paralelos

MCP08: Falta de auditoria e telemetria

Sem logs, todos os outros riscos desta lista se tornam invisíveis. Roubo de token, injeção de comandos e injeção de prompt podem acontecer sem que nada seja registrado, e a resposta a incidentes vira adivinhação. Este item amplifica os outros nove.

Um log útil de chamadas de ferramenta é pequeno. Para cada chamada, registre:

O que fazer:

• Grave os logs em armazenamento imutável que o agente não consiga editar.
• Emita alertas para padrões, como uma rajada de leituras privadas seguida de uma gravação em um lugar público.
• Observe sequências inteiras de ações, e não apenas chamadas isoladas.

MCP09: Servidores MCP paralelos (shadow)

Um desenvolvedor sobe um servidor experimental numa sexta-feira, ele continua rodando com credenciais padrão e configurações abertas, e na segunda-feira já tem dados reais. Ninguém aprovou, ninguém monitora e ele nunca aparece em um inventário. Isso é um servidor MCP paralelo.

Onde procurar primeiro:

• Arquivos de configuração MCP nos notebooks dos desenvolvedores e em repositórios compartilhados.
• Pipelines de CI/CD e registros de contêineres.
• Contas na nuvem, para listeners em portas incomuns.
• Aplicativos de desktop e extensões de editor que podem adicionar as próprias entradas de servidor.

O que fazer:

• Rode uma varredura contínua desses lugares, e não uma auditoria anual.
• Aplique uma lista de permissões para que o cliente recuse servidores desconhecidos.
• Proíba credenciais padrão no nível da plataforma.

MCP10: Injeção de contexto e excesso de compartilhamento

Janelas de contexto compartilhadas ou persistentes vazam. Quando um agente atende vários usuários ou locatários e o contexto não é isolado, os dados de uma pessoa podem aparecer na sessão de outra. O cenário da OWASP é um único agente atendendo muitos usuários e vazando os dados pessoais de um deles para a sessão de outro.

Isso já aconteceu com um produto real. A BleepingComputer relatou que a Asana alertou os usuários em junho de 2025 que uma falha de lógica em seu novo recurso MCP expôs dados de algumas organizações a outras. Cerca de 1.000 clientes foram afetados, e a Asana desativou o recurso de 5 a 17 de junho enquanto corrigia o bug. Foi um erro de lógica, não um ataque, e a falha ficou ativa por cerca de um mês antes de a Asana identificá-la.

O que fazer:

• Dê a cada usuário e locatário sua própria janela de contexto com escopo.
• Torne a memória efêmera por padrão e faça-a expirar rapidamente.
• Imponha o isolamento entre locatários na camada do protocolo, e não apenas no prompt.
• Redija os dados pessoais antes de qualquer coisa ser armazenada para reutilização futura.

Quais riscos corrigir primeiro

Você não consegue fechar os dez em uma semana, então comece onde o dano é maior e o trabalho é menor.

Maior impacto, menor esforço

• MCP01: ative a varredura de segredos e reduza a duração dos tokens.
• MCP07: coloque autenticação na frente de cada servidor, inclusive os que estão no localhost.
• MCP09: liste cada servidor que sua equipe roda hoje. Você não consegue proteger o que não contou.

Mais lentos, mas necessários

• MCP03 e MCP04: fixar versões e gerar hashes exige uma configuração real, mas impede mudanças silenciosas.
• MCP06: aprovações e guardas exigem trabalho de design e ajuste constante.
• MCP08 e MCP10: logs e isolamento mexem na arquitetura, então planeje-os como projetos.
• MCP02 e MCP05: ficam no meio-termo; aperte os escopos enquanto revisa cada servidor.

Um plano de endurecimento de uma semana

💡 Erros comuns: aprovar "sempre permitir" para cortar cliques, confiar em um servidor só porque ele tem muitos downloads, e registrar tudo menos os argumentos das ferramentas que importam.

Crie seus próprios visuais de segurança

Uma lista de verificação de segurança causa mais impacto quando as pessoas conseguem visualizá-la. Cada imagem deste artigo usa uma representação simples e física de uma falha abstrata: um anel cheio de crachás para a expansão de escopo, uma porta escorada aberta para a autenticação fraca, um livro de registro em branco para a falta de trilhas de auditoria. Você pode criar o mesmo tipo de visual para seus próprios modelos de ameaça, apresentações de treinamento e wikis internas.

Experimente na PicassoIA. Abra um modelo de texto para imagem, como o Seedream 5 Pro, o Qwen Image 3 ou o GPT Image 2, descreva um objeto real que represente o seu risco e acrescente a iluminação e a lente que quiser. Gere algumas variações, escolha a mais nítida e use-a na sua próxima revisão. Se você também escreve a documentação, os modelos de linguagem da PicassoIA podem ajudar a montar a primeira versão antes de você editar à mão.