Servidores MCP
Ele roda na sua máquina com as suas permissões, como qualquer pacote. Diferente de um pacote, as descrições das ferramentas dele caem dentro do contexto do modelo, onde são lidas como instruções. A segurança de um servidor MCP precisa dar conta das duas metades.
Nenhum deles é exótico. Todos saem de como o protocolo funciona e de onde as pessoas guardam suas credenciais.
tool poisoning
O nome, a descrição e o schema de parâmetros de uma ferramenta chegam ao modelo como texto. Um servidor pode escrever uma descrição que manda o modelo ler um arquivo e passar o conteúdo como argumento, e o modelo não tem como distinguir isso de uma instrução legítima.
entrega de credencial
Servidores MCP locais rodam por stdio como processos filhos. Eles recebem o ambiente que você entrega, o que normalmente significa um token de vida longa numa variável. Dali em diante a credencial saiu das suas mãos.
mudança de schema
Descrições e schemas de ferramentas podem mudar na próxima atualização. O servidor que você revisou em março não é necessariamente o que roda em junho, e nada no protocolo faz barulho com essa mudança.
escopo do token
Servidores remotos guardam tokens de acesso em seu nome. Um servidor que aceita ou repassa um token emitido para outro recurso vira um procurador bem conveniente para alcançar coisas que você nunca autorizou.
sem registro
A maioria das configurações não guarda registro de qual ferramenta MCP rodou, com quais argumentos, contra qual host. O problema aparece no calendário de outra pessoa, geralmente numa fatura ou num aviso de vazamento.
O fio comum: quem lê as descrições das ferramentas é o modelo, e a credencial está em algum lugar onde o servidor consegue ler. Resolva a segunda metade e a primeira para de conseguir render alguma coisa.
Servidores MCP locais e remotos se autenticam de formas completamente diferentes, e essa diferença pesa mais do que a maioria dos guias de instalação sugere.
Não existe etapa de autenticação. O servidor é um processo filho que você iniciou, e ele é tão confiável quanto o ambiente com que você o iniciou. O token que você exportou agora é token do servidor também.
confiança = o seu ambiente
O perfil de autorização do MCP se apoia em OAuth 2.1: o cliente descobre o servidor de autorização, você consente no navegador, e o cliente guarda um token de acesso de vida curta com um token de refresh atrás dele.
confiança = o escopo do token
Nada aqui precisa de um produto. É a revisão que você faria em qualquer dependência, mais as duas perguntas específicas de MCP.
Instale uma versão específica em vez do que latest resolver hoje. Um servidor que se atualiza sozinho pode mudar as descrições das ferramentas depois que você as aprovou.
O README foi escrito para você. As descrições foram escritas para o modelo. Leia as que o modelo vai receber de fato.
Um servidor stdio é um processo filho com as suas permissões. Dê a ele a credencial mais estreita que ainda resolva, nunca um token de root que estava ali por perto.
Um token revogável e de vida curta ganha de um personal access token numa variável de ambiente, mesmo que a configuração leve cinco minutos a mais.
Um recurso, um destinatário. Um servidor que quer um token de escopo amplo, ou que aceita um emitido para outra coisa, já está te dizendo como vai se comportar.
Juntar cinco serviços atrás de um único servidor MCP concentra todas as credenciais num processo só. Separe e o pior caso encolhe.
Se você não consegue dizer o que um servidor fez na terça passada, você está confiando nele em vez de verificar. Logs são o que transforma um incidente num incidente delimitado.
Trate uma mudança de schema de ferramenta como um bump de dependência: olhe o diff. É a checagem que quase ninguém faz, que é exatamente por isso que ela funciona como ataque.
O Sallyport fica na frente dos servidores MCP com que o seu agente conversa. As chamadas deles sobem a mesma escada que todo o resto e caem no mesmo registro.
01
Claude Code, Cursor ou qualquer cliente MCP se conecta ao Sallyport. O Sallyport apresenta http.request, ssh.exec e os servidores upstream que você configurou.
02
Servidores stdio locais e servidores OAuth 2.1 remotos passam os dois pelo proxy. O Sallyport lacra os tokens deles no cofre e faz o refresh dentro do app.
03
Um cofre trancado nega a chamada. Uma chave marcada para aprovação por chamada levanta um cartão. Fora isso, a aprovação de sessão que você já deu cobre a execução.
04
Criptografado e encadeado por hash enquanto acontece, para que a resposta a "o que aquele servidor fez na terça passada" exista antes de você precisar dela.
Um limite honesto: um servidor MCP local por stdio que você configurar recebe sim a credencial que você vincular a ele. O proxy te dá aprovação e registro das chamadas dele; ele não tira a chave de volta de um processo que você escolheu iniciar.
Download grátis. Apple Silicon, macOS 14 ou mais recente. Sem conta, nunca.
brew install --cask olegsotnikov/tap/sallyportmacOS 14+ · Apple Silicon