Servidores MCP, explicados: como dar ferramentas a um agente de IA sem entregar suas chaves

Todo agente de IA útil enfrenta a mesma barreira. O modelo pode raciocinar o dia todo, mas por conta própria não consegue ler seus arquivos, consultar seu banco de dados ou reiniciar um serviço — ele não tem mãos. Ele precisa de ferramentas. MCP, o Protocolo de Contexto do Modelo, é a maneira padrão de fornecer a um modelo ferramentas sem conectá-las diretamente ao aplicativo. Vale a pena entender por si só, porque no momento em que uma ferramenta toca algo real — um banco de dados, uma API, um servidor — você tomou uma decisão de segurança, quer você quisesse ou não.

O que é realmente um servidor MCP

MCP é um protocolo aberto para conectar aplicações de IA a capacidades externas. Ele tem três funções, e os nomes são importantes:

• Host — o aplicativo em que o modelo reside: um cliente de chat de desktop, um agente de codificação, um plugin de IDE. O host é com quem o usuário interage.
• Cliente — um conector dentro do host. Há um cliente por servidor, e ele gerencia essa única conexão.
• Servidor — um pequeno programa que expõe alguma capacidade. Um servidor de sistema de arquivos, um servidor GitHub, um servidor SSH. Ele faz uma única tarefa e fala MCP.

O fluxo é sempre o mesmo. O servidor anuncia o que pode fazer. O host mostra essas capacidades ao modelo. Quando o modelo quer usar uma, o host chama o servidor e alimenta o resultado de volta na conversa. O modelo nunca executa nada por conta própria — ele pede, e o host faz o trabalho. Essa indireção é a razão pela qual o MCP é importante para a segurança: há um ponto de verificação entre "o modelo decidiu" e "isso aconteceu", e é aí que você pode impor regras.

Ferramentas, recursos, prompts

Um servidor MCP pode expor três tipos de coisas, e a distinção é prática, não acadêmica:

• Ferramentas — ações que o modelo pode invocar. run_query, create_issue, ssh_exec. Ferramentas fazem algo e podem mudar o estado.
• Recursos — dados que o modelo pode ler. Um arquivo, uma tabela, uma página de documentos. Contexto somente leitura.
• Prompts — modelos pré-definidos que um usuário pode escolher em um menu, preenchidos pelo servidor.

Recursos são em sua maioria inofensivos — o pior cenário é o modelo ler algo que não deveria. Ferramentas são onde o risco reside. Uma ferramenta muda o estado, e para mudar o estado em um sistema real, ela precisa de uma credencial. O que nos leva à questão que decide tudo.

stdio e HTTP: servidores locais e remotos

Antes disso, uma divisão prática. Servidores MCP se conectam através de um dos dois transportes:

• stdio — o host inicia o servidor como um subprocesso local e se comunica com ele através de entrada/saída padrão. O servidor roda na sua máquina, como você, com suas permissões. A maioria dos servidores locais funciona assim.
• Streamable HTTP — o servidor é um ponto de rede que o host chama via HTTPS. É assim que servidores hospedados ou compartilhados funcionam, e como um servidor pode atender a muitos usuários.

Registrar um servidor local (stdio) geralmente é uma linha de comando:

claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem /caminho/para/dir

Um servidor remoto (HTTP) é um pequeno bloco de configuração:

{
  "mcpServers": {
    "exemplo": {
      "url": "https://example.com/mcp",
      "headers": { "Authorization": "Bearer ..." }
    }
  }
}

O transporte não muda a questão de segurança. Ele apenas muda onde a credencial reside — na sua máquina ou no servidor de alguém.

A questão da credencial que todo servidor precisa responder

Aqui está a linha de raciocínio. Qualquer ferramenta que faz trabalho real precisa de um segredo: uma senha de banco de dados, um token de API, uma chave SSH. Existem apenas dois lugares para colocá-lo, e a escolha é toda a história de segurança.

Coloque-o no ambiente do agente. A rota direta — coloque o segredo na configuração do servidor ou em uma variável de ambiente que o agente controla, e deixe a ferramenta usá-lo. Isso funciona imediatamente, e é a armadilha. Agora o contexto do modelo efetivamente contém uma credencial portadora: quem possui os bytes pode agir como você. Você não pode desfazê-lo — uma vez que um segredo passou pelo contexto de um modelo, uma transcrição ou uma chamada de ferramenta que você não leu, você não pode provar que não vazou. E a injeção de prompt chega até ele: um documento envenenado ou um resultado de ferramenta armadilhado pode convencer o modelo a exfiltrar o próprio segredo que foi entregue.

Deixe o servidor mantê-lo e agir em nome do agente. O servidor mantém a credencial e faz a autenticação. O agente obtém a capacidade de solicitar uma ação restrita — não o segredo em si. Comprometa o contexto do agente e tudo o que você obtém é "pode pedir ao corretor para fazer coisas listadas", não "pode impersonar você em qualquer lugar". Desligar o acesso é um interruptor, porque nada foi compartilhado.

É isso. Essa única escolha de design — quem mantém a credencial — separa uma configuração MCP na qual você pode dormir de uma que você não pode. Tudo o mais é detalhe.

SSH é a versão mais aguda do problema

Em nenhum lugar isso é mais claro do que no SSH. Uma chave privada SSH é a credencial portadora mais pura que existe: possuí-la significa que você é o usuário, em todos os hosts que confiam nela, com um shell completo. Portanto, um servidor MCP SSH que mantém a chave no ambiente do agente é o pior caso do padrão ingênuo — raio de explosão máximo, zero retornos.

A boa versão é o que as equipes de infraestrutura já chamam de modelo de custódia. O servidor mantém as chaves (ou emite certificados de curta duração), assina em nome do agente e adiciona os controles que a versão ingênua carece: o agente só alcança hosts listados, cada host possui uma política de comando, um humano pode assistir ao vivo, e cada ação é registrada e atribuível. Nós percorremos isso do início ao fim em deixando um agente implantar sem suas chaves e, para modelos que rodam em seu próprio hardware, dando a um LLM local acesso SSH seguro.

Como o Termalin faz isso

Termalin é um cliente SSH com um servidor MCP embutido, então o padrão de custódia é o padrão em vez de um projeto que você precisa montar.

• Servidor local, via stdio. Registre-o com seu agente (claude mcp add termalin -- <caminho>/termalin-mcp) e ele expõe ferramentas — listar hosts, executar um comando, abrir uma sessão persistente, ler e escrever arquivos via SFTP. O acesso do agente está desligado por padrão; você o habilita por host.
• Sua chave permanece com o custodiante. O servidor mantém a chave e a usa para autenticar o agente, permitindo que ele execute ações sem expor a chave privada.