Arquitetura e Segurança de Servidores MCP em Produção

Arquitetura e Segurança de Servidores MCP em Produção

Um servidor MCP de demonstração pode rodar em um notebook, chamar uma API e retornar uma resposta simpática. Em produção surgem questões menos glamorosas: e se a solicitação chegar a outra instância? Quem é a pessoa por trás dela? O que acontece quando a API downstream fica lenta? Alguém do suporte consegue investigar uma falha sem ver o token de acesso de outra pessoa?

A boa notícia é que o protocolo MCP atual foi projetado para funcionar com a infraestrutura HTTP comum. O desafio é o mesmo de qualquer serviço em produção: deixar explícitos identidade, permissões, estado, falhas e operação.

Comece pela fronteira do serviço

Um host em produção conecta-se a um endpoint MCP remoto por Streamable HTTP. Um fluxo típico é: host de IA → TLS / gateway de borda → aplicativo MCP → serviços de domínio e fontes de dados. O host controla a experiência e a conexão; o aplicativo MCP oferece um conjunto específico de ferramentas, recursos e prompts. Coloque regras de negócio e acesso a dados em serviços que possam aplicá-los de maneira consistente, sem depender da descrição da ferramenta.

A revisão 2026-07-28 introduziu um ciclo de protocolo stateless: removeu o handshake de inicialização e o Mcp-Session-Id do protocolo. As solicitações levam a versão do protocolo e metadados do cliente; uma descoberta server/discover pode anunciar revisões e capacidades aceitas. Assim, qualquer solicitação pode chegar a uma instância saudável atrás de um balanceador comum — sem roteamento aderente ou armazenamento de sessão de protocolo.

Protocolo stateless não quer dizer que todo produto deva ser sem estado. Se um fluxo de trabalho precisa de estado duradouro, armazene-o em um banco de dados da aplicação e passe um identificador opaco, validado pela autorização, entre as chamadas. Não dependa de uma variável em memória de uma instância ou de um cabeçalho de sessão antigo para manter o fluxo da pessoa.

Deixe claras as fronteiras de confiança

Para um servidor remoto protegido, use o modelo de autorização MCP com um servidor de autorização externo. O aplicativo MCP atua como servidor de recursos: valida tokens destinados a ele e depois verifica as permissões da ferramenta e dos dados solicitados. Autenticação responde quem está chamando; autorização responde se essa identidade pode realizar esta ação neste registro e nesta organização.

Nunca confie em clientInfo, IDs de pessoa ou organização, ou permissões enviados como argumentos comuns da ferramenta para comprovar identidade. Vincule a identidade autenticada a verificações no servidor. Use TLS, valide emissor, público/recurso e validade, peça somente o menor privilégio necessário e não encaminhe o token do seu servidor MCP a outra API. Obtenha credenciais próprias para cada recurso downstream.

Trate solicitações de ferramentas como entradas não confiáveis, mesmo quando passaram pela validação do esquema. Limite tamanho de textos, listas, duração e respostas. Rejeite caminhos de arquivos e URLs inesperados. Se uma ferramenta buscar URLs fornecidas por usuários, bloqueie faixas de IP privadas e locais, verifique de novo o DNS depois de redirecionamentos, restrinja conexões de saída e use um componente confiável para reduzir o risco de SSRF.

Em endpoints HTTP, valide Host e Origin conforme os domínios esperados da implantação; use o middleware do SDK ou as proteções da plataforma quando disponível. Um servidor público não deve aceitar silenciosamente conexões de qualquer origem de navegador. Autorize cada solicitação e cada ferramenta com efeitos importantes, não apenas no balanceador de carga.

Dê ao gateway o papel certo

Um gateway de borda pode terminar TLS, impor políticas de rede, aplicar limites de taxa gerais e encaminhar solicitações. No Streamable HTTP atual, os cabeçalhos Mcp-Method e, para operações com nome, Mcp-Name permitem inspecionar a operação sem interpretar o corpo JSON. O endpoint MCP ainda precisa verificar se os cabeçalhos correspondem ao corpo da solicitação e aplicar a autorização de negócio.

O gateway não substitui verificações de acesso por pessoa. Não trate Mcp-Name ou metadados enviados pelo cliente como identidade autenticada. Use uma identidade própria para a conexão gateway-serviço, impeça acesso direto que contorne o gateway quando isso fizer parte do seu modelo de ameaças e configure explicitamente quais proxies são confiáveis.

Faça escala e estado serem previsíveis

Para chamadas comuns de ferramentas, mantenha o processamento curto e com limites claros. As solicitações stateless podem ser distribuídas entre instâncias; o SDK pode negociar versões do protocolo e lidar com paginação. Armazene configuração compartilhada e estado de negócio duradouro em serviços apropriados. Aplique limites de recursos e pools de conexão; no desligamento, pare de receber tráfego e permita que as chamadas em andamento terminem ou sejam canceladas com clareza.

Para trabalhos demorados, não deixe uma solicitação HTTP aberta indefinidamente. Quando cliente e servidor aceitarem a extensão io.modelcontextprotocol/tasks, uma ferramenta pode criar um identificador de tarefa para o cliente consultar ou cancelar. O armazenamento precisa ser duradouro conforme os requisitos de recuperação, e o ID deve ser imprevisível e validado para a pessoa autenticada. Uma tarefa não contorna permissões.

Use cache de catálogos e leituras de recursos apenas quando os dados puderem ser compartilhados com segurança. O protocolo atual inclui indicações ttlMs e cacheScope. Um resultado por pessoa ou organização nunca deve ir para um cache compartilhado entre contas. Inclua no cache toda dimensão relevante para segurança, expire os dados quando políticas ou permissões mudarem e evite armazenar resultados sensíveis sem uma estratégia clara de isolamento.

Crie resiliência em torno do trabalho

Nunca repita automaticamente uma compra, e-mail, exclusão ou outro efeito colateral só porque a resposta da rede se perdeu. O servidor pode ter concluído a ação mesmo depois do timeout no cliente. Torne as escritas idempotentes quando possível e retorne um ID de operação para o host consultar o resultado.

Observe chamadas sem vazar segredos

Acompanhe volume, erros, percentis de latência, trabalhos ativos, timeouts, autorizações negadas e falhas downstream. Adicione campos estruturados para nome da ferramenta, versão da implantação, ID de solicitação e uma chave pseudônima de pessoa ou organização quando a política permitir. A especificação atual documenta a propagação do contexto W3C de rastreamento em _meta, conectando host, gateway, handler MCP e chamadas a dependências.

Logs devem explicar resultados sem se transformar em transcrições de dados privados. Remova tokens bearer, cabeçalhos de autorização, senhas e argumentos secretos. Registre o mínimo necessário de prompts, entradas e saídas das ferramentas; defina a retenção e limite quem pode pesquisá-los. Configure alertas para volumes anormais, falhas repetidas de autorização, conexões de saída inesperadas e frequências incomuns de ações destrutivas.

Checklist de segurança MCP

• Ferramentas: ofereça apenas o necessário; use descrições e esquemas de entrada restritos; autorize cada chamada no próprio handler.
• OAuth: valide o token para este recurso MCP; não aceite tokens com outro público nem os encaminhe a outros serviços.
• Navegador e rede: valide host e origem; restrinja destinos de saída; proteja contra SSRF e DNS rebinding.
• Conteúdo: trate argumentos, resultados, recursos e prompts como dados não confiáveis; limite o que entra no contexto do modelo.
• Controle da pessoa: explique ações importantes e solicite aprovação explícita na interface do host.
• Operação: limite taxas e recursos; troque segredos; monitore; atualize dependências e mantenha um plano de incidentes.

O guia de segurança também alerta sobre agente confuso e sobre confiar em anotações das ferramentas como se fossem autorização. Uma anotação “somente leitura” pode ajudar o host a apresentar a ação; é o servidor quem deve controlar o que realmente acontece.

Implante por etapas

Comece com um serviço pequeno e ferramentas somente de leitura. Adicione OAuth e valide a identidade real em uma ferramenta. Teste token com público incorreto, escopo ausente, registro de outra organização, entrada malformada, saída muito grande, timeout e chamadas duplicadas. Depois, adicione uma pequena ação de escrita com confirmação clara e idempotência. Teste a carga da descoberta, da listagem e da operação downstream mais pesada; confirme que rastros e painéis não contêm segredos. Faça o lançamento com flag ou canário e mantenha uma forma de desativar rapidamente uma ferramenta arriscada.

O MCP dá ao aplicativo uma forma compartilhada de conversar com ferramentas e provedores de contexto. Preparação para produção ainda depende das fronteiras de serviço, verificações de identidade, tratamento seguro de falhas e disciplina operacional. Projete esses elementos deliberadamente e o protocolo poderá escalar junto com o restante do aplicativo.

Para saber mais

• Especificação MCP (2026-07-28)
• Boas práticas de segurança MCP
• Especificação de autorização MCP (2026-07-28)
• Visão geral de mudanças no protocolo MCP
• Extensão MCP Tasks