Boas práticas de segurança de MCP: riscos, checklist e auditoria

Um servidor MCP é uma porta para os seus sistemas que um modelo de IA abre por conta própria. Quando um cliente, como um assistente de chat ou um editor de código, se conecta, o modelo pode ler arquivos, consultar bancos de dados, chamar APIs internas e enviar mensagens, normalmente com as permissões de quem instalou o servidor. Por isso, as boas práticas de segurança de MCP devem fazer parte da primeira sprint, e não da análise pós-incidente. Este artigo mapeia os riscos que de fato aparecem em produção, apresenta um checklist de 20 pontos que você pode colar em um ticket e percorre uma auditoria que sua equipe consegue concluir em uma tarde.

Versão curta, caso você esteja com pressa: trate toda descrição de ferramenta como entrada não confiável, dê a cada servidor o menor conjunto de permissões que ainda funciona, mantenha os segredos fora do alcance do modelo e registre cada chamada de ferramenta para poder reconstruir o que aconteceu.

Por que a segurança de MCP é diferente

A segurança de APIs clássicas parte do princípio de que um desenvolvedor escreveu o código que chama o seu endpoint. O MCP quebra essa premissa. O Model Context Protocol permite que um modelo de linguagem escolha ferramentas em tempo de execução, com base em texto que ele lê. Texto pode ser forjado, e o modelo não consegue distinguir de forma confiável uma instrução legítima de uma instrução plantada. Isso torna a segurança de servidores MCP um problema diferente de proteger uma API REST.

O modelo passou a ser o novo chamador

Em uma integração comum, uma pessoa revisa o caminho do código antes de ele ir para produção. Com MCP, quem chama é um sistema probabilístico que lê nomes de ferramentas, descrições e resultados como parte do seu prompt. Uma frase escondida na descrição de uma ferramenta tem quase o mesmo peso de uma frase no seu próprio prompt de sistema. Esse fato sozinho explica a maioria dos incidentes com MCP.

Isso também muda quem é considerado um atacante. Você não precisa de acesso ao servidor. Qualquer pessoa que consiga colocar texto diante do modelo pode tentar direcioná-lo: o autor de uma página web, um cliente que abre um chamado de suporte, um desconhecido que registra uma issue em um repositório público. Uma boa segurança de agentes de IA começa por reconhecer que o canal de entrada está aberto ao mundo.

Onde ficam as fronteiras de confiança

Desenhe quatro fronteiras antes de escrever qualquer linha de configuração:

O transporte também importa. Um servidor local iniciado via stdio é um processo na máquina do usuário, rodando com as permissões dele, então um pacote malicioso equivale, na prática, a execução de código arbitrário. Um servidor remoto via HTTP acrescenta exposição de rede, autenticação e gerenciamento de sessão. Cada transporte precisa do seu próprio modelo de ameaças, e um servidor que oferece os dois exige duas revisões.

💡 Dica: A configuração mais arriscada é um agente que pode ler dados privados, ler conteúdo não confiável e enviar dados para fora. Pesquisadores de segurança chamam essa combinação de "trifecta letal". Remova pelo menos uma dessas pernas e a maioria dos caminhos de exfiltração se fecha.

Os sete riscos que importam

Nem toda ameaça merece a mesma atenção. Estas sete aparecem repetidamente em pesquisas públicas sobre MCP e em relatórios de incidentes, e cada uma corresponde a itens do checklist mais adiante.

Prompt injection por meio da saída de ferramentas

Prompt injection é o risco principal porque não exige código de exploração. Em 2025, pesquisadores mostraram que uma integração com o GitHub podia ser direcionada por uma issue maliciosa em um repositório público para ler repositórios privados e devolver o conteúdo. O modelo fez exatamente o que lhe foi pedido. Só que o pedido veio de um atacante.

Defesas que funcionam:

• Trate os resultados das ferramentas como dados, nunca como instruções. Envolva os resultados em delimitadores claros e diga isso no prompt de sistema.
• Separe as funções. O agente que lê páginas não confiáveis não deve ter acesso de escrita a nada valioso.
• Controle as ações de saída. Enviar, publicar e excluir exigem um clique humano.
• Filtre nos dois sentidos. Rode um classificador de segurança sobre entradas e saídas, como mostrado no tutorial abaixo.

Envenenamento de ferramentas e rug pulls

O envenenamento de ferramentas esconde instruções dentro da descrição ou do esquema de uma ferramenta. Você vê uma ferramenta inofensiva de "somar dois números". O modelo vê um parágrafo extra mandando ler um arquivo de credenciais e passar o conteúdo como parâmetro. Um rug pull é a versão lenta: o servidor se comporta bem durante a revisão e, depois que você aprova, altera discretamente as definições de suas ferramentas.

A correção é simples e eficaz. Calcule o hash do manifesto completo da ferramenta (nomes, descrições e esquemas) no momento da aprovação, compare-o a cada conexão e recuse a execução quando o hash mudar. Mostre aos usuários a descrição completa, não um resumo encurtado.

A cadeia de suprimentos merece um item próprio. Em 2025, um servidor de e-mail com nome parecido publicado no npm foi denunciado por copiar mensagens enviadas para um endereço externo depois de uma atualização de rotina. Fixar versões e manter uma lista de permissões (itens 9 e 10 do checklist) são a defesa.

Credenciais e tokens vazados

Segredos vazam de formas banais: um token colado em um arquivo de configuração que vai parar no commit, uma variável de ambiente impressa em um log de depuração, uma senha de banco de dados devolvida dentro de um resultado de ferramenta e que agora fica no contexto do modelo pelo resto da sessão. Assim que um segredo entra no contexto, qualquer injeção posterior pode pedir ao modelo que o repita.

Guarde os segredos em um cofre ou no gerenciador de credenciais do sistema operacional, entregue-os ao processo do servidor na inicialização e nunca os devolva na saída. Prefira tokens de vida curta, que expiram em minutos, porque um token roubado que morre na hora do almoço é um problema pequeno.

Permissões excessivas se acumulam

Um servidor que "só precisa ler chamados" costuma sair com um token de administrador porque esse foi o caminho mais rápido para uma demonstração. Então, uma única instrução injetada pode fechar chamados, exportar listas de clientes ou alterar configurações. Permissões definem o raio de impacto, e você escolhe o tamanho dele no primeiro dia.

Aplique o privilégio mínimo à ação mais restrita: leitura, e não escrita; um projeto, e não o workspace inteiro; uma tabela, e não o banco de dados. Quando um fornecedor oferece apenas um token de tudo ou nada, coloque na frente um proxy enxuto que exponha somente as chamadas que você aceita.

Um checklist de segurança de 20 pontos

Cole isto no seu sistema de tickets e avalie cada servidor com base nele. Tudo o que você não conseguir marcar hoje vira um ticket com responsável e prazo.

Identidade e acesso

1. Use OAuth 2.1 com tokens de acesso de vida curta para servidores remotos. Evite tokens compartilhados estáticos.
2. Verifique se cada token foi emitido para o seu servidor (validação de audiência). Nunca repasse o token do cliente para uma API de jusante. Solicite um separado.
3. Dê a cada servidor a sua própria identidade, para poder revogar um sem tocar nos outros.
4. Use escopos somente leitura por padrão. Escopos de escrita exigem uma justificativa por escrito.
5. Exija aprovação humana para ações destrutivas ou de saída: excluir, enviar, pagar, publicar.
6. Vincule as sessões ao usuário autenticado e nunca trate um ID de sessão como prova de identidade.
7. Remova o acesso de colegas que saem da equipe no último dia, por meio de uma etapa automatizada de desligamento.

Endurecimento do servidor

8. Rode servidores locais em um contêiner ou sandbox sem acesso ao diretório pessoal por padrão.
9. Fixe versões e checksums, e revise o diff antes de cada atualização.
10. Mantenha uma lista de permissões dos servidores que sua equipe pode instalar. Bloqueie o restante.
11. Aprove novamente um servidor sempre que a lista de ferramentas ou as descrições mudarem.
12. Valide todo argumento de ferramenta no servidor: caminhos, SQL, URLs e strings de shell. Nunca passe a saída do modelo para um shell sem escape.
13. Vincule servidores HTTP locais a 127.0.0.1 e verifique o cabeçalho Origin para impedir DNS rebinding.
14. Mantenha ferramentas de depuração, como inspetores de protocolo, fora de redes compartilhadas e atrás de autenticação.

Dados e rede

15. Guarde os segredos em um cofre ou no gerenciador de credenciais do SO, nunca em prompts, arquivos de repositório ou resultados de ferramentas.
16. Oculte segredos e dados pessoais dos resultados das ferramentas antes que cheguem ao modelo.
17. Restrinja o tráfego de saída com uma lista de permissões de saída, para que um agente sequestrado não consiga enviar dados para hosts arbitrários.
18. Aplique limites de taxa e tetos de gasto por servidor e por usuário.
19. Registre cada chamada de ferramenta com usuário, servidor, hash dos argumentos, tamanho do resultado e carimbo de data e hora. Envie os logs para um armazenamento que o agente não consiga editar.
20. Mantenha um botão de desligamento de emergência que desative qualquer servidor em menos de cinco minutos, e ensaie o procedimento.

💡 Dica: Os itens 5, 11 e 17 são os mais baratos de implementar e fecham os caminhos mais perigosos: ações não aprovadas, mudanças silenciosas nas ferramentas e dados saindo da rede. Se a sua semana está curta, comece por aí.

Como fazer uma auditoria de MCP

Uma auditoria responde a uma pergunta: o que o modelo pode fazer agora e quem aprovou isso? Reserve uma tarde, convide um engenheiro e um revisor de segurança e trabalhe em três etapas. Antes da primeira, escreva um modelo de ameaças de uma página com quatro respostas: a quais dados o agente consegue chegar, que conteúdo não confiável ele lê, para onde ele pode enviar dados e quais ações são irreversíveis.

Inventarie todos os servidores

Você não consegue proteger o que não consegue listar. Reúna os servidores a partir dos arquivos de configuração dos clientes, das configurações da IDE, de repositórios compartilhados da equipe, dos pipelines de CI e de qualquer configuração "temporária" que nunca foi removida. Registre isto para cada um:

Espere surpresas. Equipes encontram com frequência servidores que ninguém se lembra de ter instalado, rodando com um token pessoal de administrador.

Reproduza e revise os logs

Extraia trinta dias de chamadas de ferramentas e procure padrões que não deveriam existir: chamadas em horários estranhos, resultados incomumente grandes, ferramentas acionadas logo depois que o agente lê uma página externa e argumentos que contenham caminhos de arquivo ou URLs que o usuário nunca mencionou. Para triagem em escala, um modelo como o Claude Sonnet 5 pode agrupar milhares de chamadas em uma lista curta de anomalias, desde que você oculte segredos e dados pessoais antes de enviar qualquer coisa.

Classifique e corrija os achados

Atribua a cada achado uma severidade e um prazo. Mantenha a escala pequena para que as pessoas realmente a usem:

Refaça a auditoria após cada mudança importante e pelo menos uma vez por trimestre. Uma lista de servidores que estava limpa em janeiro raramente está limpa em junho.

Monitoramento e resposta a incidentes

A prevenção falha em algum momento, então planeje para o dia em que isso acontecer. O objetivo é perceber em minutos e conter em uma hora.

O que registrar

Registre o suficiente para reconstruir uma sessão sem armazenar segredos. Capture usuário, cliente, servidor, nome da ferramenta, um hash dos argumentos, tamanho do resultado, latência e a decisão de aprovação. Configure alertas para três sinais primeiro: uma rajada de chamadas para a mesma ferramenta, qualquer chamada a uma ferramenta que nunca foi usada antes e resultados grandes logo depois que o agente busca conteúdo externo.

Botões de desligamento e reversões

Todo servidor precisa de um interruptor de desligamento que uma pessoa consiga acionar sem fazer deploy. Revogue seus tokens, remova-o da lista de permissões e rotacione todo segredo que ele tocou. Depois, restaure o último hash de manifesto conhecido como bom. Pratique isso uma vez por trimestre, para que a primeira tentativa real não seja também o primeiro ensaio.

💡 Um teto na própria plataforma também ajuda. A PicassoIA, por exemplo, limita cada conta a 5 execuções simultâneas em todas as conexões, para que um agente descontrolado não lote a fila. Pergunte aos seus próprios fornecedores quais são os limites deles.

Como usar o Llama Guard na PicassoIA

Um classificador de segurança não substitui permissões nem aprovações, mas acrescenta um filtro útil. O Llama Guard 4 12B lê texto ou imagens e devolve um veredito de seguro ou inseguro com a categoria de dano correspondente, abrangendo áreas como violência, ódio e instruções perigosas. Ele não é um detector dedicado de prompt injection, então use-o como uma camada ao lado dos controles acima, por exemplo para filtrar o que os usuários enviam e o que o seu agente está prestes a devolver.

1. Abra a página do modelo. Acesse a página do Llama Guard 4 12B na PicassoIA.
2. Preencha os campos obrigatórios. Cole o conteúdo a ser verificado em Prompt. Em System Prompt, defina sua política e a saída desejada, como "Responda somente com safe ou unsafe, depois a categoria."
3. Ajuste as configurações opcionais. Defina Temperature como 0 para vereditos repetíveis, reduza Max Completion Tokens do padrão de 512 para algo curto e anexe capturas de tela em Image Input quando precisar verificar uma imagem.
4. Execute. Clique em generate e leia o veredito. Tudo o que for marcado como inseguro vai para um revisor humano, e não para o agente.
5. Salve e compare. Mantenha um pequeno conjunto de entradas de teste e execute-as de novo sempre que mudar o prompt de sistema.

Erros que as equipes continuam cometendo

• Aprovar uma vez e nunca mais olhar. Descrições de ferramentas mudam. Reaprovar a cada mudança é o controle mais barato que você tem.
• Confiar em um servidor porque ele é popular. Popularidade não é revisão. Verifique os mantenedores, o histórico de versões e o que o servidor consegue alcançar.
• Colocar segredos no prompt "só para testar". Segredos de teste viram segredos de produção em uma semana.
• Dar ao agente todas as ferramentas. Carregue apenas os servidores de que uma tarefa precisa. Menos ferramentas significam menos chances de ser direcionado.
• Pular os logs porque nada aconteceu ainda. Sem eles, você não percebe um vazamento silencioso.

Crie suas próprias imagens na PicassoIA

O trabalho de segurança é quase sempre invisível, e isso dificulta explicá-lo. Bons visuais ajudam: uma imagem de capa para um runbook, uma ilustração de cenário para um slide de treinamento, um corredor de data center para a wiki interna. A PicassoIA transforma um prompt de texto em imagens fotorrealistas e vídeos curtos, sem software de design e sem licença de banco de imagens para controlar.

Experimente com o tema que você acabou de ler. Descreva uma cena como "um engenheiro de segurança revisando um checklist impresso em uma sala de servidores silenciosa, luz suave de janela, lente de 35mm", gere a imagem e ajuste o ângulo, a iluminação e a lente até que ela combine com o seu documento. Abra a PicassoIA, navegue pela lista completa de modelos e teste os seus próprios prompts hoje.