Os servidores de protocolo de contexto de modelo (MCP) oferecem aos LLMs a capacidade de chamar ferramentas, consultar fontes de dados e agir no mundo real. Mas estas capacidades adicionais criam novos riscos. Para permanecer seguro, a implantação do MCP de produção precisa de um plano de controle.
Este artigo explica como o plano de controle funciona na segurança do servidor MCP, como é a aplicação na camada de execução e os controles para autenticação e autorização MCP.
O que torna a segurança do MCP um desafio
Os modelos tradicionais de segurança policiam o comportamento humano. Uma pessoa clica em um botão e um segurança digital verifica se essa ação é permitida. Com o MCP, os bots de IA fazem escolhas autônomas. Em vez de esperar que uma pessoa autorize cada ação, a IA agente decide quais ferramentas MCP usar e como encadeá-las.
Senhas e chaves digitais também criam vulnerabilidades. Esses segredos geralmente ficam trancados em armazenamento seguro, mas em um sistema MCP, há novos riscos de expor essas chaves quando elas viajam para ajudar a IA agente a concluir tarefas. Os agentes de IA trocam de trabalho e misturam ferramentas de maneiras inesperadas, o que significa que a zona de perigo está sempre mudando. Os sistemas de segurança MCP precisam verificar constantemente a identidade da IA, definir limites sobre o que ela pode acessar e registrar cada movimento que ela faz para evitar perder vulnerabilidades importantes.
Como os invasores exploram servidores MCP
Os riscos de vulnerabilidade do MCP se enquadram em várias classes principais, que podem ser agrupadas em algumas categorias, dependendo da estratégia de ataque.
Os invasores cujas explorações envolvem a manipulação do comportamento do agente dependem de injeção imediata, envenenamento de ferramentas e classes de ataque confusas. Aqueles que obtêm acesso não autorizado geralmente escolhem passagem de token, sequestro de sessão e permissões excessivas. E os invasores que exploram diretamente o servidor usam injeção de comando e falsificação de solicitação do lado do servidor (SSRF).
Aqui está uma visão mais detalhada de como cada classe de ataque funciona e seu impacto.
Role para mais ➔
Ao contrário dos ataques típicos de API, novas formas de explorar servidores MCP nem sempre parecem ameaças.
Uma injeção imediata muitas vezes parece uma ação humana normal à primeira vista. Da mesma forma, uma exploração de deputado confusa segue um fluxo OAuth legítimo, mas depois pula a etapa de consentimento. E mesmo para envenenamento por ferramenta, o nome da ferramenta permanece o mesmo, então o agente continua chamando-a como se nada tivesse mudado. Para uma ferramenta de segurança tradicional, isso significa que não há nenhuma solicitação malformada para bloquear e nenhum código de status anômalo para sinalizar. É precisamente por isso que o ataque foi bem-sucedido.
Como prevenir e mitigar os riscos de segurança do MCP
Para prevenir e mitigar vulnerabilidades, as implantações de MCP de produção precisam de uma camada de orquestração que avalie chamadas de ferramentas, isole credenciais e registre cada execução. Seguir as práticas recomendadas de segurança do MCP significa ter essa camada instalada antes que os agentes cheguem à produção.
Injeção de prompt e comando
Os invasores realizam ataques de injeção imediata, ocultando instruções maliciosas no conteúdo que o LLM já está lendo. Isso pode incluir um documento, uma resposta de API ou uma saída de ferramenta. O modelo geralmente não consegue distinguir entre uma instrução real e uma instruída, então segue ambas.
Solução: Trate todo o conteúdo externo como não confiável antes de chegar ao modelo. Adicione proteções para verificar a intenção do prompt, envolva a entrada do usuário em tags XML predefinidas (ou seja,
Envenenamento de ferramentas e integridade da cadeia de suprimentos
Com o envenenamento por ferramenta, os invasores mudam o que a ferramenta faz, mas mantêm o mesmo nome. O agente continua chamando essa ferramenta maliciosa porque é levado a pensar que a reconhece. Isso está mais próximo de um ataque à cadeia de suprimentos no contexto do agente do que a típica fuga de prisão de um usuário.
Solução: O registro dinâmico é o caminho de maior risco porque um invasor pode usá-lo para trocar um servidor aprovado. Verifique as definições da ferramenta antes de carregá-las, assinando-as, fixando versões do servidor e revisando suas definições de configuração para registro dinâmico.
Escopo de capacidade e exposição de ferramentas com privilégios mínimos
A vulnerabilidade de segurança de protocolo de contexto de modelo mais comum são os tokens superprovisionados. Mesmo sem um plano sofisticado por trás disso, essa abordagem pode causar muitos danos, como roubar informações confidenciais com sucesso.
Solução: Comece com acesso somente leitura e credenciais de escopo especificamente para o que cada um deles pode realmente precisar.
Como impor a autenticação e limitar o escopo do token
Quando mal configurado, o MCP tende a quebrar e permitir a entrada de invasores. A maioria dos problemas remonta a três fontes principais relacionadas aos requisitos de autenticação. Estes, por sua vez, estão ligados a padrões de ataque específicos que as ferramentas de segurança e as equipes de TI que as utilizam devem aprender a identificar.
Veja como mitigar os riscos de MCP relacionados à autenticação.
OAuth 2.1 e segurança de transporte
O OAuth 2.1 oferece aos servidores MCP uma maneira padrão de verificar quem chama uma ferramenta antes de ela ser executada. Ele aceita tokens emitidos por um servidor de autorização e verifica se cada um é válido, não expirado e emitido especificamente para esse terminal.
Solução: Todas as URLs relacionadas ao OAuth devem usar HTTPS na produção porque conexões HTTP inseguras expõem tokens em trânsito.
Deputado confuso
O problema confuso do deputado ocorre quando um proxy MCP compartilha o mesmo ID de cliente com um servidor de autorização de terceiros. Um invasor pode então induzir um usuário a clicar em um link malicioso que tira proveito de sessões de consentimento salvas anteriormente. Isso pode ignorar a tela de consentimento e enviar um código de autorização ao invasor.
Solução: A especificação MCP deve exigir que o servidor proxy mantenha um registro de consentimento por cliente. Ele deve validar identificadores uniformes de recursos (URIs) de redirecionamento com correspondência exata de string antes de encaminhar para o servidor de autorização de terceiros e rejeitar a solicitação se o URI de redirecionamento for alterado.
Passagem de token
A passagem de token cria um risco semelhante ao da confusa estratégia de deputado. Se um servidor aceitar tokens não emitidos diretamente para ele, o servidor não poderá confirmar com precisão quem fez a solicitação ou rastrear quais ações eles executam. Isso complica o monitoramento, a auditoria e a conformidade.
Solução: Os servidores MCP devem aceitar apenas tokens emitidos especificamente para eles e rejeitar todos os outros.
Minimização de escopo
Quando você dá muita energia a uma chave digital, o uso indevido e o roubo causam danos massivos. A concessão de amplo acesso agrava as vulnerabilidades, causa confusão adicional e torna mais difícil rastrear quem fez o quê.
Solução: Nunca provisione acesso total desde o início. Conceda mais acesso apenas quando uma tarefa específica exigir.
Comece a criar fluxos de trabalho MCP seguros com n8n
A segurança do servidor MCP acontece na camada de execução – onde as ferramentas são executadas, as credenciais são usadas e cada ação deixa um rastro. É exatamente aí que fica o n8n.
n8n atua como intermediário entre o agente e os sistemas que ele toca. O LLM vê uma superfície de ferramenta limpa; n8n mantém as credenciais, define o escopo dos parâmetros e registra as chamadas. O resultado é uma implantação de MCP em que o agente tem capacidade suficiente para realizar seu trabalho e nada mais.
Expor ferramentas sem expor credenciais
A maneira mais rápida de comprometer uma implantação MCP é permitir que os tokens de autenticação viajem com o agente. Com o Gatilho do servidor MCPo n8n expõe fluxos de trabalho e APIs externas como ferramentas MCP que o agente pode chamar pelo nome, mas as chaves de API, os tokens OAuth e as senhas do banco de dados permanecem Armazenamento de credenciais criptografadas do n8n e ser injetado no momento da execução. O LLM nunca os vê, o que fecha diretamente a passagem de token e os caminhos de ataque de representantes confusos.
Defina o que o agente pode controlar com ferramentas
n8n permite que você expor ferramentas individuais, não APIs inteiras. Em vez de entregar ao agente uma integração com Slack ou Salesforce com cada endpoint anexado, você publica endpoints de API individuais ou agrupa várias etapas em um subfluxo de trabalho, ou seja, “postar no canal #alerts”, “criar um ticket de suporte” – como uma ferramenta MCP nomeada. A superfície acessível do agente é aquela que você escolheu expor e nada mais.
Dentro de cada ferramenta, a vinculação de parâmetros oferece controle refinado sobre o que o LLM pode realmente preencher:
- Os valores estáticos são codificados no fluxo de trabalho. O agente não pode substituí-los. Use isso para qualquer coisa que o LLM nunca deveria decidir – um ID da organização, um canal de destino, um tipo de registro.
- Os valores dinâmicos vêm da lógica do fluxo de trabalho e das saídas dos nós anteriores. Ainda invisível para o agente.
- Parâmetros $fromAI são os únicos campos que o LLM pode preencher, e você opta explicitamente por cada um deles.
Essas duas abordagens limitam o risco excessivo de permissões e garantem uma exposição deliberada, por ferramenta e por parâmetro, com menos privilégios.
Proteger um servidor é uma grande tarefa. Escolher as ferramentas certas e seguir as práticas recomendadas prepara as equipes para o sucesso.
Vale lembrar que a segurança do servidor MCP não acontece no nível do protocolo. Ele reside na camada de execução, onde executa ferramentas, bloqueia chaves e rastreia ações. Para uma protecção eficaz, a ferramenta de segurança certa tem de funcionar a este nível. n8n faz.
n8n é uma plataforma de automação de fluxo de trabalho disponível na fonte, criada para fornecer aos operadores o plano de controle que as implantações de MCP precisam. As soluções da n8n tratam a governança do MCP como uma responsabilidade operacional contínua que se adapta aos seus sistemas, e não como um exercício único de fortalecimento.
Perguntas frequentes
Qual é a diferença entre autorização MCP e autorização API padrão?
A autorização padrão da API pergunta se um chamador pode acessar um endpoint específico. A resposta geralmente é fixa, o que significa que uma rota permite uma solicitação ou não.
Em vez disso, a autorização MCP funciona no nível da ferramenta com um filtro sensível ao contexto em vez de um filtro fixo. Ele pergunta se um chamador pode usar uma ferramenta específica, com entradas específicas, com base no que seu token diz sobre sua função e permissões.
O que é encadeamento de servidor MCP?
O encadeamento de servidores MCP ocorre quando um servidor MCP local malicioso aguarda no caminho de uma integração de servidor MCP remoto confiável, como uma integração oficial do Slack ou do Google Drive. Os invasores então exploram os dados confidenciais que passam pela integração autorizada, para que não precisem comprometer o servidor legítimo.
