O MCP é seguro para usar? Depende dos servidores que você instala, das permissões que concede e do conteúdo que seu agente lê. Este artigo reúne incidentes reais com MCP, uma tabela de riscos, uma lista de verificação de segurança para imprimir e um jeito prático de analisar textos em busca de conteúdo inseguro.
Resposta curta: sim, desde que você trate cada servidor como um software que pode agir em seu nome. Então, é seguro usar MCP? O Model Context Protocol é um padrão de mensagens simples. Ele transporta pedidos entre um app de IA e uma ferramenta, mas não decide o que essa ferramenta pode acessar. O risco está em três lugares: os servidores que você instala, as permissões que você entrega a eles e o conteúdo que seu agente lê ao longo do caminho. Acerte esses três pontos e o MCP é uma forma razoável de conectar um modelo a arquivos, bancos de dados e serviços web. Erre e uma única descrição de ferramenta envenenada pode enviar um repositório privado para um desconhecido.
Este artigo mostra os riscos reais dos servidores MCP, cita os incidentes que de fato aconteceram e termina com uma verificação de segurança que você pode fazer em cerca de dez minutos. Sem alarmismo e sem exagero, apenas os modos de falha e as correções.
O MCP é um padrão aberto que a Anthropic introduziu no fim de 2024 para que apps de IA conversassem com ferramentas externas de um jeito único e consistente. Antes dele, cada integração era um código de cola feito sob medida. Agora um app fala um único protocolo, e um servidor expõe ferramentas (ações, como executar uma consulta), recursos (dados, como um arquivo) e prompts (modelos reutilizáveis). As mensagens viajam como JSON-RPC, por um canal local (stdio) ou por HTTP.
Essa simplicidade é ao mesmo tempo a boa e a má notícia. Um padrão facilita a integração e também facilita plugar algo que você nunca avaliou. O protocolo em si não tem opinião sobre se um servidor merece sua confiança. Esse julgamento é seu.
Três papéis aparecem em toda configuração:
O modelo nunca fala diretamente com seu banco de dados. Ele pede ao host que chame uma ferramenta, o cliente encaminha o pedido, e o servidor faz o trabalho com o acesso que recebeu. Essa última parte é a mais importante. Um servidor só é tão seguro quanto o acesso que está por trás dele.
Onde o servidor roda muda bastante o modelo de ameaça. Um servidor local é um processo na sua própria máquina, iniciado pelo host. Um servidor remoto é um serviço hospedado que você acessa pela internet.
| Servidor local (stdio) | Servidor remoto (HTTP) | |
|---|---|---|
| Roda em | Sua própria máquina | Infraestrutura de terceiros |
| O código roda com | Suas permissões de usuário | As permissões do fornecedor |
| Risco principal | Um pacote ruim é executado no seu notebook | Seus dados e tokens viajam para um terceiro |
| Pergunta de confiança | Quem escreveu isso, e a versão está fixada? | Quem opera isso, e o que eles registram? |
| Melhor defesa | Sandbox, versões fixadas, acesso somente leitura | Tokens OAuth com escopo limitado e análise do fornecedor |
💡 Regra prática: um servidor local é um programa que você executa, então trate-o como qualquer download. Um servidor remoto é um serviço em que você confia seus dados, então trate-o como qualquer fornecedor.
A maioria dos incidentes com MCP não é exótica. Eles seguem alguns padrões repetíveis, e cada um já apareceu na prática. Por baixo de todos está um fato incômodo: um modelo de linguagem lê instruções e dados como o mesmo fluxo de texto, então não consegue distinguir de forma confiável um comando de um comentário.
Toda ferramenta vem com uma descrição, e o modelo lê esse texto como orientação. Os usuários raramente o veem. Em 2025, pesquisadores da Invariant Labs demonstraram que uma descrição maliciosa pode carregar comandos ocultos, como instruir o agente a ler um arquivo local de credenciais e enviar o conteúdo dentro de uma chamada que parece comum.
O envelope acima é a imagem certa: o pacote parece rotineiro, mas o bilhete dentro muda o que acontece em seguida. Ler a definição completa da ferramenta, e não apenas o nome, é a primeira defesa.
Seu agente não segue apenas as suas instruções. Ele também lê issues, e-mails, páginas da web e documentos, e qualquer um deles pode conter instruções direcionadas ao modelo. No incidente do MCP do GitHub, atacantes plantaram prompts elaborados em Issues e pull requests públicos. Um agente com acesso a repositórios privados foi enganado e vazou código privado em um pull request público.
💡 A trinca perigosa: o pesquisador de segurança Simon Willison descreve uma combinação a evitar: acesso a dados privados, exposição a conteúdo não confiável e uma forma de enviar dados para fora. Quando um único agente reúne as três, basta uma frase injetada. Remova qualquer uma delas e o ataque deixa de funcionar.
Três outros padrões vêm de problemas comuns da cadeia de suprimentos de software:
| Risco | Como funciona | Exemplo real | Primeira defesa |
|---|---|---|---|
| Envenenamento de ferramentas | Instruções ocultas em uma descrição de ferramenta | Demonstrações da Invariant Labs, 2025 | Ler as definições completas, fixar versões |
| Injeção de prompt | Instruções escondidas em conteúdo que o agente lê | Vazamento do repositório privado pelo MCP do GitHub | Separar dados privados de entrada não confiável |
| Servidor malicioso | Backdoor dentro de um pacote que você instalou | postmark-mcp, setembro de 2025 | Preferir servidores auditados e mantidos |
| Rug pull | Definições mudam após a aprovação | Padrão relatado por pesquisadores | Fixar versões, revisar a cada atualização |
| Bug no cliente | Injeção de comandos por meio de um servidor hostil | CVE-2025-6514 no mcp-remote | Aplicar correções rápido, conectar-se só a servidores confiáveis |
Quando algo dá errado, as permissões definem o tamanho da perda. Uma descrição envenenada é um incômodo quando o agente só consegue ler uma pasta. Torna-se um desastre quando o agente tem um token de administrador.
Dê a cada servidor a menor fatia de acesso que permita fazer o trabalho:
💡 Faça uma pergunta para cada ferramenta: "Se esta chamada fosse maliciosa, qual é o pior que ela poderia fazer?" Se a resposta fizer você estremecer, reduza a permissão.
Credenciais não pertencem a mensagens de chat, argumentos de ferramentas ou arquivos de configuração versionados no Git. Carregue-as de variáveis de ambiente ou de um gerenciador de segredos, prefira tokens de curta duração e troque qualquer coisa que já tenha aparecido em um log. Verifique seus arquivos de configuração do MCP antes de cada commit, já que são um esconderijo favorito de tokens colados durante um teste rápido.
Um servidor MCP remoto guarda seus dados na máquina de outra pessoa, então as verificações de identidade importam muito mais do que para um processo local.
A especificação de autorização do MCP, de junho de 2025, classifica os servidores MCP como servidores de recursos OAuth 2.0. Os clientes incluem um parâmetro resource (RFC 8707) ao pedir tokens, o que vincula cada token de acesso a um servidor específico. Um token emitido para o servidor A deve ser inútil no servidor B, e um servidor deve rejeitar qualquer token que não tenha sido emitido para ele.
Os mesmos documentos alertam contra o token passthrough, quando um servidor repassa o token que recebeu para uma API a jusante. Isso quebra as trilhas de auditoria, confunde quem é responsável e abre espaço para o problema do "deputado confuso", em que um servidor confiável é enganado para usar sua autoridade em favor de um atacante.
A especificação de ferramentas acrescenta mais uma regra que vale repetir: deve sempre haver um humano no circuito, com a capacidade de negar invocações de ferramentas. A maioria dos hosts implementa isso como um pedido de aprovação. Não clique nele no piloto automático.
Passe por esta lista antes de adicionar qualquer servidor à sua configuração.
Registre cada chamada de ferramenta com seus argumentos, o horário e a identidade por trás dela. Quando algo parecer errado, você vai querer reconstruir o que o agente leu e o que enviou. Revise o log semanalmente, do mesmo jeito que uma equipe revisa relatórios de acesso.
Fique atento a quatro sinais de alerta:
Presuma que, com o tempo, um servidor vai se comportar mal, e então limite o que isso custa para você.
Uma caixa de luvas permite que um técnico manipule uma amostra perigosa sem tocá-la. Os contêineres fazem o mesmo trabalho para o software. Rode os servidores locais em um contêiner ou em uma conta de usuário restrita, monte apenas as pastas de que precisam, bloqueie o acesso de rede de saída quando a ferramenta não exigir, e mantenha os segredos fora da imagem. Se um servidor virar hostil, ele quebra uma caixa de vidro em vez do seu notebook.
Pedidos de aprovação só funcionam se as pessoas os lerem. Equipes que aprovam tudo por reflexo não têm proteção alguma. Separe as ferramentas por risco:
| Tipo de ferramenta | Exemplo | Política de aprovação |
|---|---|---|
| Somente leitura, baixo risco | Pesquisar em um site de documentação, ler um arquivo do projeto | Permitir automaticamente |
| Grava dados | Editar um arquivo, criar uma issue | Perguntar uma vez por sessão |
| Envia dados para fora | E-mail, postar em um webhook, enviar arquivo | Perguntar toda vez |
| Destrutiva ou custosa | Apagar, publicar em produção, gastar dinheiro | Perguntar toda vez, com uma prévia |
Mantenha a lista de aprovação automática curta e revise-a sempre que um servidor for atualizado.
A análise de conteúdo é mais uma camada, não um substituto das permissões. O Llama Guard 4 12B é um modelo de segurança multimodal disponível no PicassoIA que classifica textos e imagens como seguros ou inseguros e informa a categoria de dano quando marca algo. Você pode usá-lo para verificar uma página da web, um e-mail ou o resultado de uma ferramenta antes que seu agente aja com base nisso, ou para testar se o rascunho de resposta de um agente seria sinalizado antes de chegar a um usuário.
💡 Seja realista sobre os limites. O Llama Guard 4 12B é um classificador de segurança de conteúdo que verifica categorias de dano como violência, discurso de ódio e instruções perigosas. Ele não é um firewall dedicado contra injeção de prompt, então use-o junto com os controles acima e nunca no lugar deles.
Você recebe um rótulo de seguro ou inseguro, além da categoria identificada quando o conteúdo é inseguro. Trate "inseguro" como uma placa de pare: retenha o conteúdo e mostre-o a uma pessoa. Trate "seguro" como um dado, não como um perdão. Se houver alarmes falsos, aperfeiçoe o system prompt com exemplos do que sua equipe considera aceitável.
Para a triagem, combine o veredito com um modelo de raciocínio capaz, como o Claude Sonnet 5 ou o GPT 5.6 Sol, para resumir os itens sinalizados. Execute-os sem nenhum acesso a ferramentas, para que um trecho hostil não tenha nada que possa usar.
Hábitos seguros são mais fáceis de manter quando você pratica em projetos nos quais nada sensível está em jogo. A geração de imagens e de vídeos é um bom terreno de treino. O PicassoIA Image transforma um prompt em linguagem simples em uma imagem pronta em segundos, e o Picasso IA Video renderiza clipes de 5 segundos a 24 fps (taxa de quadros), com áudio sincronizado, a partir de texto ou de uma imagem inicial, em 480p ou 720p.
O PicassoIA também oferece uma API para desenvolvedores e uma conexão MCP para geração de imagens e vídeos, e as mesmas regras valem ali: crie uma credencial para um projeto, guarde-a como segredo e acompanhe seu uso. Cada conta tem um limite de 5 execuções simultâneas, compartilhado entre credenciais de API e conexões MCP, o que também funciona como freio caso um agente fique preso em um loop.
Abra o PicassoIA, escreva um prompt e aplique a lista de verificação primeiro em algo de baixo risco. Gere algumas imagens, anime a sua favorita em um clipe curto e passe um parágrafo pelo Llama Guard 4 12B para ver como é um veredito. Depois leve os mesmos hábitos para os servidores que importam.
Escolha seu idioma
