Para proteger um servidor MCP local ou interno, escolha primeiro o transporte e a identidade que precisa controlar. Em stdio, o cliente inicia um processo e conversa pela entrada e saída padrão; as permissões do sistema operacional continuam essenciais. Em HTTP, autenticação, autorização e proteção da conexão precisam ser projetadas explicitamente. Uma rede corporativa não é, por si só, uma fronteira suficiente.
O mTLS autentica as duas pontas de uma conexão TLS por certificados. RBAC associa identidades a papéis e permissões. Eles podem trabalhar juntos, mas não substituem os requisitos de autorização do MCP nem garantem que uma ferramenta autorizada execute uma operação segura. A arquitetura deste guia separa transporte, identidade, política e execução, sem apresentar um servidor HTTP genérico como implementação completa do protocolo.
Resumo rápido
- Stdio é comunicação entre processos, não uma sandbox automática.
- Para MCP por HTTP, use transporte e autorização compatíveis com a versão adotada.
- mTLS pode autenticar uma máquina ou serviço sem identificar o usuário final.
- RBAC precisa controlar ferramenta, recurso e argumentos relevantes.
- Teste acessos negados, isolamento entre clientes e revogação antes de liberar escrita.
1. Diferencie servidor local de serviço na rede
Um servidor iniciado pelo cliente em um notebook tem uma superfície diferente de um serviço compartilhado por várias equipes. No primeiro caso, o processo pode herdar acesso a arquivos, variáveis de ambiente e credenciais do usuário. No segundo, uma única aplicação pode atender identidades distintas e acessar recursos de múltiplos clientes. Documente essa diferença antes de escolher controles.
A especificação de transportes MCP consultada descreve stdio e Streamable HTTP. Este último pode usar SSE para transmitir mensagens, mas não deve ser confundido com o transporte HTTP+SSE legado. Fixe a versão do protocolo e do SDK no projeto e confirme a compatibilidade com o cliente escolhido.
Para HTTP local, a especificação orienta validação de Origin e vínculo ao endereço de loopback, em vez de exposição indiscriminada a todas as interfaces. Essas medidas ajudam contra acesso indevido a serviços locais, mas não transformam loopback em autenticação de usuário. Outros processos da máquina ainda precisam ser considerados no desenho.
| Cenário | Fronteira principal | Controle adicional necessário |
|---|---|---|
| Stdio no notebook | Processo e conta do sistema | Permissões mínimas de arquivos e credenciais |
| HTTP em loopback | Aplicação local | Origin, autenticação e restrição de interfaces |
| HTTP interno compartilhado | Gateway e aplicação | Identidade por requisição e isolamento de recursos |
| Serviço entre máquinas com mTLS | Certificados e política | Ciclo de vida das credenciais e autorização de negócio |
Para entender a sequência de mensagens e o papel de ferramentas, recursos e clientes, consulte o guia do Model Context Protocol. Não abra uma porta na rede apenas para contornar uma dificuldade de configuração local.
2. Separe mTLS, autorização MCP e RBAC
O certificado apresentado no mTLS prova posse da chave privada associada, dentro das regras de confiança configuradas. Isso não significa que o operador esteja autorizado a consultar qualquer conta. Um certificado compartilhado entre vários agentes identifica uma credencial compartilhada; ele não fornece autoria individual por mágica.
A especificação de autorização do MCP define um modelo baseado em OAuth para transportes HTTP. Quando esse modelo for adotado, implemente descoberta e validação de tokens conforme a especificação, inclusive sua destinação ao recurso correto. Não descreva mTLS como substituição universal e interoperável desse fluxo.
Uma arquitetura interna pode exigir mTLS no gateway e, adicionalmente, um token de usuário no serviço. Nesse desenho, o certificado autentica o cliente de rede e o token identifica o contexto delegado. A política deve combinar essas informações sem permitir que o chamador invente o usuário em um parâmetro JSON.
RBAC é a parte que traduz identidade em permissões. Defina papéis pequenos, como consulta operacional, revisão e execução administrativa. Evite um papel com curinga para todas as ferramentas como configuração inicial. A aplicação deve negar por padrão e decidir novamente a cada operação relevante.
Escopos de acesso, papéis e propriedade do recurso resolvem perguntas diferentes. Um escopo pode autorizar leitura de pedidos, mas a aplicação ainda deve verificar quais pedidos pertencem ao cliente atendido. O artigo sobre permissões para agentes de IA aprofunda essa separação entre capacidade geral e ação concreta.
3. Organize certificados e a fronteira do proxy
Use um processo de emissão que produza certificados com identidades únicas e extensões apropriadas para servidor e cliente. O certificado de servidor deve corresponder ao nome usado na conexão. Não recomende desativar a validação de hostname para fazer um laboratório funcionar. Também não copie a chave privada da autoridade certificadora para o host da aplicação.
Defina responsáveis por emissão, renovação e retirada de acesso. Proteja chaves privadas com controles adequados ao sistema operacional e evite compartilhamento entre pessoas. O prazo de validade faz parte dessa operação; um certificado curto exige renovação confiável, e um certificado longo amplia a necessidade de resposta a comprometimento.
O módulo SSL do Nginx documenta verificação de certificados de cliente, autoridades confiáveis e mecanismos de revogação. Habilitar a exigência do certificado é somente parte da configuração. Confirme também a cadeia confiável, os usos permitidos e como a política de revogação será aplicada no ambiente.
Se o proxy encaminhar a identidade à aplicação por cabeçalho, remova qualquer valor enviado pelo cliente e crie o cabeçalho a partir do certificado efetivamente validado. Restrinja o backend para aceitar conexões apenas do proxy confiável, ou proteja esse enlace por outro mecanismo autenticado. Um cabeçalho com nome convincente não comprova sua origem.
Evite autorizar pelo Common Name isolado. Cadastre a identidade a partir de atributos e emissor verificados, usando uma convenção administrada pela organização. Trate colisões e certificados desconhecidos como negação. Renovação não deve criar privilégios novos nem reutilizar automaticamente o cadastro de outra identidade.
4. Aplique a política antes de executar ferramentas
Use um SDK MCP compatível com a versão definida. Ele deve cuidar do ciclo de inicialização, negociação de capacidades, mensagens, sessões e transporte. Uma classe baseada em HTTPServer que recebe JSON e devolve “executado” não implementa essas responsabilidades. A política deve integrar o despachante real, antes do efeito da ferramenta.
Separe método do protocolo e nome da ferramenta. Em uma chamada de ferramenta, valide o nome e os argumentos com o esquema esperado. Em leitura de recursos, valide a URI e o objeto acessado. Não use o nome recebido nos argumentos como substituto indiscriminado do método solicitado, pois isso mistura operações com regras diferentes.
Uma política de leitura pode permitir consultar o status de um pedido, mas deve verificar o identificador do cliente e limitar os campos devolvidos. O agente não deve escolher seu próprio papel. Também não deve selecionar um banco, caminho de arquivo ou comando arbitrário apenas porque tem permissão para uma ferramenta genérica.
Ao listar ferramentas, exponha somente o conjunto adequado ao contexto quando a implementação permitir. Revalide na execução: esconder um nome da lista não impede uma chamada direta. Aplique limites de tamanho, tempo, concorrência e volume retornado. Operações de escrita devem ter regras específicas para aprovação e repetição segura.
A documentação ssl do Python descreve verificação de certificados e o comportamento de CERT_REQUIRED. Esse recurso não cria RBAC nem ativa sozinho uma política completa de revogação. Caso o TLS termine na aplicação Python, confira os controles oferecidos pelo servidor e sua integração com o SDK, sem presumir que toda biblioteca exponha a identidade do par da mesma forma.
Registre identificador de correlação, identidade efetiva, operação, recurso, decisão e versão da política. Não registre tokens, chaves ou conteúdo confidencial desnecessário. Relacione as ações de uma sessão, mas não use o identificador da sessão como prova autônoma de autorização. Mudanças de permissão precisam valer segundo uma política explícita de atualização e invalidação.
Exemplo: equipe de suporte em Barueri
Considere um cenário ilustrativo: uma empresa de software em Barueri oferece à equipe de suporte um servidor MCP para consultar status de integrações de clientes. A equipe também possui uma ferramenta administrativa de reprocessamento. O objetivo é permitir diagnóstico sem entregar o mesmo poder operacional a todo agente.
O desenho proposto usa um gateway que autentica os clientes de rede e uma aplicação que valida a identidade do usuário. O papel de suporte pode consultar apenas os clientes vinculados ao seu atendimento. O papel de operação pode solicitar reprocessamento, mas depende da aprovação definida pela empresa. Cada ferramenta usa credenciais próprias com permissões limitadas no sistema de destino.
A validação começa com casos negativos: ausência de certificado quando exigido, autoridade desconhecida, token para outro recurso e tentativa de acessar o cliente errado. Em seguida, testa chamadas diretas a ferramentas que não aparecem na listagem e cabeçalhos de identidade forjados. Os testes devem alcançar o backend pela rota real para verificar se existe acesso que contorne o gateway.
Por fim, a equipe remove a autorização de uma conta com sessão aberta e observa o comportamento da próxima chamada. Também testa renovação e retirada de certificados conforme a infraestrutura escolhida. Não há resultados de desempenho ou incidente real neste exemplo; essas verificações são critérios de aceitação propostos para a implantação.
Erros comuns
- Confundir mTLS com autorização de negócio: um cliente autenticado ainda pode pedir dados que não lhe pertencem.
- Confiar em cabeçalhos vindos da rede: sem uma fronteira protegida, o próprio chamador pode declarar outra identidade.
- Autorizar somente tools/call: controle também a ferramenta específica, seus argumentos e os recursos envolvidos.
- Esquecer interfaces alternativas: portas de administração, rotas de depuração e acesso direto ao backend podem contornar a política.
- Prometer revogação imediata: caches, sessões e conexões existentes precisam entrar no teste de retirada de acesso.
Outro erro é presumir que criptografia impede injeção de prompt. Um usuário legítimo pode enviar conteúdo malicioso e um modelo pode interpretar instruções indevidas presentes em documentos. Restrinja a execução no servidor, com parâmetros validados e permissões mínimas, independentemente do texto de orientação do agente.
Não declare que certificados tornam o serviço imune a vazamentos. Uma chave comprometida pode permitir impersonação até que os controles efetivamente retirem o acesso. Planeje detecção, substituição e bloqueio de credenciais. Compare também o custo operacional de mTLS com a infraestrutura de identidade que a organização já mantém.
Perguntas frequentes
Preciso de mTLS para um servidor stdio?
Não há conexão TLS nesse transporte. Controle o processo, os arquivos acessíveis, as credenciais herdadas e a origem do pacote executado. Se houver uma ponte HTTP, analise essa nova fronteira separadamente.
mTLS elimina OAuth em servidores MCP?
Não como regra geral. Verifique o modelo de autorização do protocolo e a compatibilidade dos clientes. Uma política privada de rede não equivale automaticamente à implementação interoperável do fluxo de autorização MCP.
É seguro usar apenas o nome do certificado como papel?
Não é uma boa base de autorização. Valide a cadeia e a identidade conforme uma convenção controlada e consulte um cadastro de permissões. Um atributo textual isolado não deve conceder administração.
Como testar a retirada de acesso?
Remova a autorização e teste novas chamadas, sessões abertas e caminhos alternativos. Para certificados, confira o comportamento real do mecanismo de revogação configurado. Defina o prazo aceitável para que a mudança tenha efeito.
Qual cliente suporta certificados de forma nativa?
Isso depende do produto e da versão. Consulte a documentação do cliente antes da implantação e teste o handshake. Não presuma campos de configuração universais; uma ponte local também precisa de manutenção e controles próprios.
