Implementando um Servidor MCP Seguro

Um servidor MCP geralmente começa com um requisito aparentemente simples: um host de IA deve encontrar e resumir tickets sobre um tópico. Uma vez que os dados do domínio atual entram em um contexto de modelo, o endpoint não é mais a questão central. O que importa é quais dados se tornam visíveis, sob quais permissões são pesquisados e quais ações o servidor está autorizado a expor.

Essa questão surgiu enquanto implementava o acesso MCP para Lutions, um projeto de desenvolvimento privado centrado em uma aplicação web para trabalho com projetos e tickets. Não houve nenhum incidente de segurança por trás da decisão que se seguiu. Antes que a primeira ferramenta de produção existisse, a posição arquitetônica estava clara: o servidor MCP não deve se tornar uma segunda API de produto aberta ou uma camada de agente autônoma. O primeiro artigo desta série explica o caminho entre host, modelo, servidor MCP e sistema de domínio (Hermanns, 2026e). Esta retrospectiva mostra como essa posição foi colocada em prática no design de acesso, permissões de domínio e operações.

Para orientação, o host é a aplicação de IA que passa uma pergunta do usuário e as capacidades MCP permitidas para um modelo. O servidor MCP então fornece um contexto limitado ou realiza uma operação de domínio permitida; ele não responde à pergunta do usuário em si.

Corte a superfície de acesso antes de adicionar capacidades

O MCP separa recursos, prompts e ferramentas. Ferramentas são funções que um modelo pode solicitar através de um host; recursos e prompts desempenham papéis diferentes na construção do contexto. A especificação atual trata essas capacidades do servidor separadamente e identifica ferramentas como uma interface controlada pelo modelo e relevante para a segurança (Modelo Contexto Protocolo, 2026a; Modelo Contexto Protocolo, 2026b).

No Lutions, isso levou a uma escolha simples, mas consequente: o núcleo de produção começa com seis ferramentas somente para leitura. Elas pesquisam tickets visíveis, carregam tickets individuais ou múltiplos e retornam comentários limitados, links ou um pacote de contexto compacto. O servidor se descreve de acordo como somente leitura, e a visualização de status lista as mesmas seis ferramentas como somente leitura.

Essa fronteira reduz várias incertezas de uma só vez. Uma ferramenta de leitura ainda pode tocar em informações sensíveis, então ela precisa das mesmas visibilidades e limites de projeto que a aplicação em si. Mas não altera o fluxo de trabalho, propriedade, prioridade ou efeito externo de um ticket. A primeira questão de segurança, portanto, permanece gerenciável: este token pode ver esta informação—e esta informação exata pode entrar no contexto do host?

A superfície de ferramenta estreita também ajuda o modelo. Não é um controle de segurança em si; descrições de ferramentas não são decisões de autorização. Mas reduz o uso indevido e torna possível alinhar listas de ferramentas mais de perto com o contexto de permissão real (Modelo Contexto Protocolo, 2026b).

Uma ferramenta na prática: pesquisa, não acesso livre

O ganho não está apenas no número de ferramentas, mas no contrato de cada uma. Por exemplo, search_zockets não aceita nenhum comando universal. Ele aceita texto de pesquisa limitado, um limite de resultado de 1 a 50 e filtros de domínio opcionais. Esta é uma versão simplificada e legível do esquema do lado do servidor:

{
  "name": "search_zockets",
  "readOnly": true,
  "input": {
    "query": "string, máximo 200 caracteres",
    "limit": "inteiro, 1 a 50, padrão 10",
    "status": "opcional",
    "priority": "opcional",
    "type": "opcional",
    "projectKey": "opcional"
  }
}

O esquema não substitui a autorização. No entanto, evita que a pesquisa se torne uma função oculta de “realizar acesso arbitrário”. A validação do lado do servidor e o contexto do usuário ainda determinam quais resultados podem ser retornados.

O que um pedido se torna

Um usuário pode pedir por riscos abertos e decisões sobre um tópico. O host primeiro usa search_zockets para encontrar candidatos visíveis. Somente então ele usa get_zocket_context_bundle para carregar uma seleção limitada de tickets, comentários visíveis opcionais e links. A resposta do modelo é criada apenas a partir desse material limitado.

No Lutions, a pesquisa segue uma sequência clara: pesquisar primeiro, recuperar contexto direcionado em segundo lugar, responder por último. Isso não impede que um modelo malinterprete o conteúdo. Isso evita que um pedido comece com acesso irrestrito a todos os tickets ou uma exportação completa de texto. Esse é o primeiro benefício prático de um núcleo de leitura: informações atuais sobre tickets estão disponíveis para análise sem abandonar a fronteira de pesquisa ou permissões de domínio.

Permissões permanecem no sistema de domínio

Uma conexão MCP não cria sua própria zona de confiança. Ela não deve revelar tickets ou informações a um host de IA que o usuário associado não poderia ver diretamente no Lutions.

O endpoint do Lutions, portanto, utiliza a autenticação de token API existente. Para acesso de leitura, issues:read é a base do domínio. mcp:connect adicionalmente marca o acesso MCP e pode ser aplicado após o caminho de migração documentado. Tokens vinculados a projetos permanecem limitados aos seus projetos permitidos através do MCP também, e o endpoint tem seu próprio limite de taxa.

Figura 1: Configuração de teste para uma conexão MCP somente leitura com mcp:connect e issues:read. Segredos de token não são exibidos nem na interface do usuário nem neste artigo.

O servidor MCP não inventa seu próprio modelo de permissão. Ele traduz um pedido em uma operação de domínio e deve respeitar os mesmos limites que se aplicam fora do MCP. Isso segue um princípio de segurança central do MCP: o acesso a dados e ações requer controles de acesso efetivos, e o protocolo não impõe essa arquitetura por si só (Modelo Contexto Protocolo, 2026a).

Em retrospectiva, essa é uma das decisões mais duráveis. O MCP é uma superfície de integração adicional, não uma forma de contornar a interface do usuário, API e poli