Proteja seu sistema MCP: 11 riscos comuns e como se proteger contra eles

Os riscos do MCP se dividem, de modo geral, em três categorias: manipulação de LLMs, segurança de dados e de acesso e vulnerabilidades de infraestrutura.

Como os servidores MCP costumam dar acesso a uma grande variedade de sistemas internos, o risco potencial de segurança é alto. No entanto, a probabilidade depende muito da configuração.

Há muitas medidas que pessoas e empresas podem adotar para garantir a proteção de seus sistemas, e os protocolos devem ser sempre proporcionais às capacidades e aos dados que os servidores MCP conectados podem expor.

O que é o MCP e o que é segurança de MCP?

O Model Context Protocol (MCP) é um padrão aberto criado pela Anthropic para conectar apps baseados em LLMs (ou hosts) a sistemas externos.

Um sistema MCP tem três componentes principais: o host, o cliente e o servidor. O host, que muitas vezes é um assistente de IA, se conecta a um servidor MCP externo por meio de um cliente. Assim, ele pode enviar solicitações para executar funcionalidades externas (ferramentas), recuperar dados (recursos) ou obter prompts para adicionar à janela de contexto do LLM.

Expandir

A segurança de MCP se refere aos protocolos que protegem as conexões e os componentes de um sistema MCP. Há vários desafios importantes exclusivos do MCP, incluindo o fato de que apps de IA muitas vezes têm recursos agênticos e de que instruções maliciosas podem estar embutidas em mensagens.

Problemas já conhecidos que não são específicos dos MCPs, como injeção de prompt, autenticação fraca e integrações de terceiros inseguras, também representam riscos. Como qualquer sistema computacional, o MCP depende de uma combinação de protocolos procedimentais, como usar apenas servidores confiáveis, e controles técnicos, como gateways de API, para se proteger.

Qual é a gravidade das ameaças ao MCP?

O MCP rapidamente se tornou uma tecnologia de LLM popular, usada por muitas organizações e apps voltados ao consumidor. Como os servidores MCP são programas escritos em código, eles têm vulnerabilidades como qualquer outro aplicativo.

No entanto, quando as organizações usam o MCP em implantações controladas, ele costuma ser seguro. Há uma enorme diferença entre construir um sistema com servidores confiáveis e permissões verificadas e conectar um agente autônomo a uma dúzia de servidores não avaliados.

Ameaça nº 1: injeção indireta de prompt

Um invasor pode inserir instruções direcionadas ao LLM em um documento, uma página da web ou uma saída de ferramenta retornada por um servidor MCP. Se o host adicionar esse material à janela de contexto, é possível que o LLM o confunda com instruções genuínas.

Além disso, essas instruções podem parecer apropriadas à primeira vista. Por exemplo, um ticket de suporte recuperado pode instruir o LLM a exportar registros confidenciais de clientes antes de gerar uma resposta.

Como se proteger contra a injeção indireta de prompt

As injeções de prompt normalmente devem ser tratadas no nível do host. O conteúdo externo deve ser marcado como não confiável, e solicitações de informações confidenciais devem exigir a aprovação informada de um humano no processo (human-in-the-loop). Testes de segurança que acionem documentos ou dados maliciosos para ver como o host e o LLM respondem também podem ser úteis.

Ameaça nº 2: envenenamento de ferramentas e rug pulls

Em um ataque de envenenamento de ferramentas, código malicioso é adicionado à descrição ou ao esquema de uma ferramenta MCP. Isso pode influenciar o LLM na fase de descoberta, quando o MCP expõe pela primeira vez as ferramentas disponíveis.

Expandir

Um rug pull é um tipo especial de envenenamento de ferramentas em que metadados aprovados são alterados. Essa forma de envenenamento de ferramentas pode mudar a maneira como um modelo usa ferramentas confiáveis, em vez de invocar diretamente uma ferramenta maliciosa.

Como se proteger contra envenenamento de ferramentas e rug pulls

O host deve inspecionar a definição completa de cada ferramenta antes de usá-la e compará-la com uma lista de ferramentas confiáveis aprovadas, detectando assim quaisquer alterações. Verificações de parâmetros podem ajudar a identificar e sinalizar possíveis recursos perigosos.

Ameaça nº 3: permissões excessivas

É comum que os usuários concedam aos servidores MCP e aos LLMs conectados (por meio do host) mais permissões do que o necessário para uma tarefa. Por exemplo, permissões de gravação quando apenas leitura bastaria, ou acesso completo a um sistema interno de arquivos (como o Google Drive).

Esse acúmulo excessivo de permissões pode aumentar o raio de impacto de outras vulnerabilidades, como chamadas de ferramentas maliciosas. É comum que as permissões “se somem” à medida que os usuários concedem privilégios ao longo do trabalho diário com ferramentas de IA em uma empresa (acúmulo de privilégios).

Como se proteger contra permissões excessivas

A maneira mais direta de se proteger contra esse problema é restringir as permissões e os escopos OAuth (leitura, gravação, acesso total etc.). As aprovações dos usuários, especialmente para operações sensíveis, são uma parte importante disso, mas as permissões também devem ser controladas no nível do sistema (sistema operacional, host MCP e servidor).

Ameaça nº 4: autenticação e autorização fracas

A autenticação verifica a identidade de usuários ou aplicativos que se conectam a um servidor MCP. A autorização determina quais ferramentas e recursos eles podem acessar.

Servidores MCP mal configurados podem aceitar solicitações ou tokens sem autenticar corretamente os usuários nem aplicar restrições de acesso. Além disso, credenciais roubadas podem permitir que agentes mal-intencionados obtenham acesso se a validação for fraca.

Como se proteger contra autenticação e autorização fracas

Autenticação baseada em OAuth para servidores MCP remotos, tokens de curta duração e controle de acesso baseado em funções (RBAS) são medidas que ajudam a mitigar a autorização fraca. O acesso baseado em funções é útil porque impede que os usuários acessem dados e ferramentas além de suas permissões, mesmo que o próprio servidor tenha acesso.

Ameaça nº 5: vazamento e uso indevido de credenciais

Os servidores MCP usam rotineiramente credenciais, como chaves de API e tokens de acesso OAuth, para se conectar a serviços externos. Se essas credenciais forem expostas ou usadas indevidamente, invasores podem obter acesso a dados e funcionalidades confidenciais.

Um exemplo é o token passthrough, em que um servidor MCP encaminha um token de acesso para outro serviço sem verificar se ele de fato se destina ao serviço receptor. Isso, por sua vez, pode resultar em vazamento se o serviço receptor tiver proteções inadequadas.

Como se proteger contra vazamento e uso indevido de credenciais

Tokens de curta duração e escopo restrito, além da rotação de credenciais, são eficazes para limitar até que ponto dados vazados podem ser usados por agentes mal-intencionados. Chaves de API e credenciais devem sempre ser armazenadas com segurança em um gerenciador de segredos.

Ameaça nº 6: ataques de confused deputy

Um ataque de confused deputy ocorre quando um invasor engana um aplicativo confiável para que ele use as próprias permissões para executar uma ação não autorizada por um usuário legítimo. Nesse caso, o servidor MCP é o “deputy”, ou seja, o intermediário enganado.

Expandir

O invasor explora uma vulnerabilidade do servidor MCP (como verificações de OAuth fracas) para executar um processo malicioso, como uma chamada de ferramenta ou uma recuperação de dados.

Como se proteger contra ataques de confused deputy

A validação de autorização, em que se verifica se cada chamada de ferramenta pertence a um usuário específico, ajuda a limitar ataques de confused deputy. Além disso, ações sensíveis, como exportações de dados, devem exigir autorização explícita.

Ameaça nº 7: servidores maliciosos e dependências comprometidas

Os servidores MCP podem conter código malicioso (eles são, essencialmente, programas externos) ou usar dependências comprometidas, como bibliotecas de terceiros. Trata-se de um problema da cadeia de suprimentos de software, e não de um problema exclusivo do MCP.

Uma maneira simples de isso acontecer é um invasor distribuir uma integração que parece legítima. Depois de configurada, ela pode roubar e reutilizar credenciais, acessar dados confidenciais e executar operações não autorizadas.

Como se proteger contra servidores maliciosos e dependências comprometidas

Instale servidores MCP apenas de fontes confiáveis e verificadas. Se possível, revise o código deles e sempre verifique as dependências externas. Garanta que os servidores sejam atualizados e corrigidos regularmente.

Ameaça nº 8: falsificação de solicitação do lado do servidor (SSRF)

A falsificação de solicitação do lado do servidor (SSRF) ocorre quando um invasor engana um servidor MCP para que ele envie solicitações de rede a endereços internos que o usuário não pretendia acessar.

Isso pode acontecer quando um servidor MCP expõe uma ferramenta que recupera informações de uma URL. Se um invasor conseguir influenciar o parâmetro de URL, poderá alterá-lo para o endereço de rede que quiser, como uma API interna ou um serviço de nuvem. Isso pode fazer com que dados confidenciais sejam recuperados e, potencialmente, tornados acessíveis

Como se proteger contra a falsificação de solicitação do lado do servidor (SSRF)

Os servidores MCP devem sempre validar URLs, bloquear o acesso a endereços restritos da rede interna e impedir o acesso de saída à rede. Os redirecionamentos também devem seguir esse protocolo.

Ameaça nº 9: sequestro de sessão

O sequestro de sessão ocorre quando um invasor assume o controle de uma conexão ativa entre um cliente MCP e um servidor.

Por exemplo, o invasor pode roubar um identificador de sessão de um aplicativo MCP mal protegido (por exemplo, um host ou um servidor). Se o servidor MCP aceitar esse identificador, o invasor poderá chamar ferramentas com as permissões legítimas do usuário.

Como se proteger contra

O risco de sequestro de sessão pode ser reduzido com uma verificação rigorosa de identidade em todos os aplicativos de um sistema MCP. A criptografia entre clientes MCP e servidores remotos também é essencial para evitar que identificadores de sessão sejam descobertos.

Ameaça nº 10: ataques de mix-up

Em um ataque de mix-up, o invasor engana um cliente MCP para que ele envie um código de autorização a um servidor de autorização malicioso posicionado entre o cliente e o servidor MCP. Um servidor de autorização é um aplicativo que emite tokens de acesso OAuth depois de verificar se o acesso solicitado está autorizado.

Expandir

Se um host MCP se conectar a vários serviços, cada um usando um servidor de autorização diferente, um invasor poderá controlar um deles (talvez registrando um serviço malicioso) e fazer com que o cliente envie ao servidor malicioso um código de autorização emitido por um servidor legítimo. Essa confusão pode permitir que o invasor se passe pelo aplicativo autorizado e obtenha acesso a serviços protegidos.

Como se proteger contra ataques de mix-up

Os clientes MCP devem verificar a identidade do servidor de autorização durante todo o processo OAuth. Especificamente, devem comparar o identificador do emissor (iss) do servidor com a identidade esperada e rejeitar divergências.

Ameaça nº 11: comprometimento de servidores MCP locais

Muitos servidores MCP são executados na máquina local do usuário. O usuário pode instalar o servidor de terceiros ou criá-lo por conta própria. Se um invasor conseguir comprometer esse servidor MCP local, poderá obter acesso a grandes partes do sistema local.

Há várias maneiras de um invasor obter acesso. Ele pode distribuir um servidor malicioso disfarçado de integração legítima, modificar a configuração de um host MCP para que ele emita um comando malicioso ou acessar um servidor MCP executado em um ambiente com controles de segurança insuficientes, por exemplo, por meio de DNS rebinding, técnica que engana um navegador para que ele envie solicitações a um serviço em localhost.

Como se proteger contra o comprometimento de servidores MCP locais

O uso de sandbox e protocolos rigorosos de consentimento são importantes ao usar servidores MCP locais. Os servidores MCP só devem ser instalados a partir de provedores confiáveis, e as permissões do sistema operacional devem restringir quais diretórios eles podem acessar.

Vulnerabilidades do MCP muitas vezes são velhas ameaças com nova roupagem

As vulnerabilidades do MCP costumam surgir de novas aplicações de riscos e metodologias de ataque já conhecidos. O MCP introduz novas formas de os invasores explorarem essas vulnerabilidades por meio das interações entre LLMs, servidores MCP e serviços externos.

É claro que existem ameaças específicas do MCP. No entanto, vale lembrar que protocolos de segurança padrão, como aplicar uma autorização rigorosa, usar provedores confiáveis e se proteger contra injeções de prompt, contribuem muito para proteger qualquer implementação de MCP.