Aqui está o ponto sobre proxies MCP que a maioria dos diagramas de arquitetura discretamente ignora: você não percebe que precisa de um até estar gerenciando seis servidores MCP de backend, três tipos diferentes de transporte, nenhuma aplicação centralizada de autenticação e uma sensação crescente de que algo na cadeia vai expor a coisa errada ao agente errado no momento errado.
A orientação de cibersegurança da NSA de maio de 2026 sobre MCP deixa isso claro: o protocolo já está em execução em produção nos ambientes de negócios, finanças, jurídico e desenvolvimento de software. Muitas dessas implementações omitem a autenticação por completo. Várias não contam com nenhum controle baseado em funções. A conversa sobre segurança já passou da teoria. Uma camada de proxy não é mais uma recomendação acadêmica. É o que você coloca entre seu agente e tudo o que ele pode acessar.
Este artigo explica o que um proxy MCP realmente é, onde as conexões diretas falham, como funcionam os mecanismos de roteamento e delegação e quando o proxy deixa de ser opcional.
A parte que a maioria das equipes aprende depois do primeiro incidente
- Um proxy MCP delega para servidores de backend — ele não contém lógica de ferramentas e não os substitui.
- Incompatibilidades de transporte entre clientes e backends são invisíveis até o momento da conexão; um proxy faz a ponte entre eles.
- Sem um proxy, não há um único ponto de aplicação para autenticação, políticas ou auditoria em toda a sua pilha de servidores MCP.
O que um Proxy MCP Realmente É
Um proxy MCP é um servidor MCP intermediário. Ele fica entre um cliente e um ou mais servidores MCP de backend, recebe solicitações de ferramentas, recursos e prompts e encaminha essas solicitações ao backend que realmente possui a capacidade necessária. Em seguida, ele retorna o resultado ao cliente. O proxy não contém lógica própria de ferramentas.
Essa última frase é a importante. Trata-se de delegação, não de hospedagem.
A distinção importa porque as pessoas confundem um proxy MCP com um proxy HTTP genérico, como Nginx ou HAProxy. Essas ferramentas roteiam tráfego HTTP inspecionando URLs e cabeçalhos. Elas não têm noção da semântica do protocolo MCP, não reconhecem namespaces de ferramentas, não conseguem agregar capacidades de vários servidores em uma superfície unificada e não têm como fazer a ponte entre transportes MCP de cliente e backend. Chamar essas coisas de iguais leva imediatamente a decisões arquiteturais erradas.
Um proxy MCP fala o model context protocol nativamente dos dois lados. Para o cliente, ele parece um único servidor MCP que expõe um conjunto completo de capacidades. Para os backends, ele parece um cliente fazendo solicitações. O cliente nunca precisa saber quantos servidores estão atrás do proxy nem quais transportes eles utilizam. Essa invisibilidade é o objetivo.
Por que Conexões Diretas com Servidores MCP Falham Sob Cargas de Trabalho Reais
Conexões diretas funcionam bem quando você tem um cliente, um servidor, transportes compatíveis e ninguém perguntando quem fez cada solicitação. Isso descreve o notebook de um desenvolvedor em uma terça-feira à tarde. Não descreve uma implantação de IA em produção.
Quando você escala — mais clientes, mais servidores de backend, ambientes heterogêneos — os problemas se acumulam rapidamente. Cada cliente precisa de sua própria configuração de conexão para cada servidor. Cada servidor expõe diretamente seu transporte, o que significa que um backend que só fala stdio de repente precisa ser acessível a um cliente baseado na web que só fala HTTP. Não existe um ponto único em que você possa perguntar: "quem tem permissão para chamar o quê?" Cada implantação de servidor tem sua própria abordagem de autenticação ou, mais comumente, nenhuma abordagem de autenticação.
O relatório da NSA é específico sobre isso: muitas implantações MCP omitem completamente o controle de acesso baseado em funções, e o protocolo atualmente não tem um mecanismo nativo para troca de permissões RBAC na instanciação. A vulnerabilidade não é especulativa. Laboratórios públicos lançaram exploits funcionais que demonstram execução arbitrária de código e replay de tokens contra servidores executados sem uma camada de aplicação à frente deles.
É aqui que o chamado geralmente começa.
O Problema de Incompatibilidade de Transporte: stdio, SSE e HTTP Streamable
O MCP oferece suporte a vários transportes: stdio para comunicação entre processos locais, SSE para fluxos de eventos enviados pelo servidor e HTTP streamable para interações HTTP sem estado. O problema é que clientes e servidores MCP de backend frequentemente falam transportes diferentes, e essa incompatibilidade é completamente invisível até que alguém realmente tente conectá-los.
Um plugin de IDE pode esperar se comunicar pelo transporte stdio. O servidor MCP de backend que ele precisa acessar é executado como um serviço remoto por HTTP streamable. Sem algo no meio, essa conexão não acontece. Não acontece lentamente, nem de forma inadequada. Simplesmente não acontece.
Pense nisso como um problema de adaptador de viagem. O plugue existe. A tomada existe. Há eletricidade dos dois lados. Mas, sem o adaptador, nada flui. Um proxy MCP é esse adaptador para transportes MCP: ele aceita uma conexão de entrada no transporte que o cliente utiliza e a encaminha ao backend pelo transporte que aquele servidor utiliza. A tradução é invisível para ambos os lados.
O que Acontece ao Encaminhar Solicitações Entre Vários Servidores de Backend
Imagine que seu agente precise de ferramentas de quatro servidores MCP de backend diferentes: um para acesso ao calendário, um para dados de CRM, um para documentação interna e um para execução de código. Sem um proxy, o cliente precisa de quatro configurações de conexão separadas, quatro configurações de autenticação separadas e exposição direta a quatro endereços e transportes de servidor diferentes.
Quando você precisa encaminhar solicitações entre vários servidores em um ambiente de produção, isso se transforma em dívida de configuração que cresce toda vez que alguém adiciona uma nova ferramenta. Projetos como o mcp-proxy da tbxark resolvem exatamente isso: agregam vários servidores atrás de um único ponto de entrada HTTP para que o cliente veja um servidor de backend, não quatro. A configuração do cliente não muda quando você adiciona um quinto backend. O proxy absorve essa mudança.
Esse é o problema de fan-out tornado gerenciável.
Como um Proxy MCP Funciona: Roteamento de Solicitações e Delegação de Capacidades
Vale a pena entender a mecânica com precisão, pois o comportamento do proxy parece diferente dependendo de qual lado dele você observa.
Da perspectiva do cliente, o servidor proxy MCP parece um servidor MCP padrão. O cliente se conecta, negocia capacidades e envia solicitações normalmente. Ele não tem visibilidade do que acontece depois.
O que acontece em seguida: o proxy recebe a solicitação, identifica qual servidor MCP de backend possui a capacidade solicitada — por nome de ferramenta, URI de recurso ou identificador de prompt — e encaminha a solicitação a esse backend usando o transporte adequado. Quando o backend responde, o proxy repassa o resultado ao cliente. O proxy não invoca nenhuma lógica própria. Ele não reescreve a saída da ferramenta. Ele delega, de forma transparente.
A etapa de resolução de capacidades é onde o proxy justifica sua complexidade. Se um cliente quiser invocar uma ferramenta chamada "search_docs", o proxy precisa saber qual backend possui essa ferramenta. Isso exige que o proxy mantenha um registro interno de quais ferramentas, recursos e prompts ficam em quais backends. Ele cria esse registro consultando cada backend durante a inicialização e armazenando os resultados em cache. Quando chega uma nova solicitação de ferramenta, o proxy a resolve no registro e direciona a solicitação adequadamente.
Esse registro também é o que torna o proxy mais do que um simples retransmissor. Ele pode aplicar políticas no momento da resolução: rejeitar solicitações de ferramentas que não estejam na lista de permissões, remover capacidades de backends antes de expô-las a clientes específicos ou adicionar contexto de autenticação antes do encaminhamento. A camada de roteamento também é a camada de aplicação.
Agregando Ferramentas, Prompts e Recursos em um Único Endpoint
Do ponto de vista do cliente, o proxy apresenta uma superfície de capacidades unificada. Quando o cliente pergunta quais ferramentas estão disponíveis, o proxy responde com o conjunto combinado de todos os backends. O cliente vê um ponto de conexão de cliente MCP, um endpoint, uma lista de capacidades negociada. Ele não sabe — e não precisa saber — que "search_docs" veio de um servidor de backend e "create_ticket" veio de outro.
Esse padrão de endpoint de proxy único é o que torna IDEs e frameworks de agentes práticos em ambientes com vários backends. Claude Desktop, Cursor ou qualquer agente compatível com MCP precisa de apenas uma conexão configurada. Você adiciona um servidor de backend, atualiza o registro do proxy e cada cliente conectado tem acesso imediato às novas ferramentas. Sem reconfiguração de clientes. Sem novas credenciais de conexão para distribuir.
O backend aqui é plural e invisível. A superfície que o cliente acessa é sempre singular.
Ponte de Transporte e Isolamento de Sessão Entre Cliente e Backend
O proxy mantém estados de conexão separados para cada lado. Um cliente se conecta por HTTP sem estado, e o proxy mantém essa sessão. Quando o proxy encaminha a um backend que espera uma conexão persistente com estado, ele gerencia essa conexão de forma independente. A sessão do cliente e a sessão do backend ficam isoladas uma da outra.
O isolamento de sessão importa por um motivo fácil de ignorar: sem ele, o estado da sessão de um cliente pode vazar para a de outro. Se dois agentes estiverem conectados ao mesmo proxy e um deles tiver estado parcial de execução em um backend compartilhado, esse estado precisa ser invisível ao outro. O gerenciamento de sessões do proxy impõe esse limite.
Um exemplo concreto: um cliente se conecta por SSE, o proxy aceita esse fluxo com estado e encaminha solicitações individuais de ferramenta a servidores MCP remotos por HTTP sem estado. O backend nunca vê a conexão SSE persistente. O cliente nunca vê a ausência de estado por solicitação. O proxy faz a ponte entre eles e mantém os contextos limpos.
Autenticação, Autorização e Governança: Onde o Proxy Ganha seu Espaço
É aqui que o argumento arquitetural se torna real.
Em um modelo de conexão direta, autenticação e autorização são tratadas — ou não são tratadas — em cada servidor individual. Se você tem seis backends, tem seis configurações de autenticação, seis problemas de gerenciamento de credenciais e seis lugares onde uma configuração incorreta pode expor algo que não deveria. Não há um único lugar para perguntar: "este solicitante tem permissão para invocar esta ferramenta?"
Um proxy muda isso completamente. Cada chamada de ferramenta, solicitação de recurso e invocação de prompt passa pelo proxy antes de chegar a qualquer backend. Isso torna o proxy o ponto natural de aplicação de toda a sua pilha de credenciais e políticas. Em vez de distribuir a lógica de autenticação pelos backends, você a centraliza. O proxy valida a identidade, verifica permissões e encaminha apenas as solicitações aprovadas pelas políticas. Os backends não precisam saber nada sobre quem é o solicitante. O proxy já tomou essa decisão.
O debrief da Coalition for Secure AI sobre a RSAC 2026 resume a pergunta que continuou surgindo na comunidade: "Quem está fazendo esta solicitação? Como eu sei? O que acontece quando um agente atua em nome de um usuário em vários saltos?" Um proxy que centraliza controles de segurança de nível empresarial é a resposta direta às três perguntas. Ele fornece a visibilidade e o controle que configurações de autenticação por servidor estruturalmente não conseguem proporcionar.
A avaliação da NSA sobre a especificação de autorização MCP é igualmente direta: o protocolo não tem troca nativa de RBAC na instanciação. Um proxy não corrige a lacuna do protocolo. Mas adiciona a camada de aplicação sobre ela, que é o que as implantações de produção precisam neste momento.
💡 Vale saber:
As equipes frequentemente assumem que, como cada servidor MCP tem sua própria autenticação, o sistema é seguro. Mas, sem um proxy, não existe um ponto de aplicação capaz de impedir um agente de chamar um servidor incluído na lista de permissões e outro não incluído nessa lista no mesmo ciclo. A autenticação individual de servidores não impede isso. Apenas uma camada que controla quais servidores podem coexistir no mesmo contexto de agente consegue evitar isso — e um proxy é essa camada. Um servidor MCP malicioso adicionado ao ambiente se torna chamável no momento em que não há uma camada verificando o registro.
Autenticação e Autorização no Nível do Protocolo
Um proxy intercepta cada chamada de ferramenta antes que ela chegue a qualquer backend. Esse ponto de interceptação é onde ficam a lógica de autenticação e autorização em uma implantação MCP bem governada. Validação de tokens, declarações de identidade, fluxos oauth, verificação de escopo de permissões — tudo isso é executado no proxy antes que uma única solicitação seja encaminhada.
Na prática, funciona assim: um cliente envia uma solicitação de ferramenta com um token de autenticação. O proxy valida o token, mapeia a identidade do solicitante para um conjunto de permissões, verifica se essa identidade pode invocar a ferramenta solicitada e, então, encaminha ou rejeita a solicitação. Se o backend precisar de uma credencial diferente — conta de serviço, chave de API com escopo definido — o proxy troca os tokens nesse limite. A credencial do cliente nunca chega diretamente ao backend.
Cada solicitação encaminhada é registrada: identidade do solicitante, nome da ferramenta, data e hora, status do resultado. Essa trilha de auditoria é o que as equipes de segurança pedem e raramente recebem em arquiteturas de conexão direta, porque ninguém pensou em adicioná-la antes da produção.
Implementando Lista de Permissões de Servidores MCP e Aplicação de Políticas
A lista de permissões é o padrão de governança mais simples e o que mais vale implementar cedo. O proxy mantém um registro de servidores MCP de backend aprovados. Solicitações destinadas a qualquer servidor que não esteja nesse registro são rejeitadas antes do encaminhamento. Um agente não pode chamar um backend que não apareça na lista aprovada, independentemente das ferramentas que esse backend anuncia.
Implementar a governança MCP dessa forma significa que a supervisão organizacional fica na configuração do proxy, e não dispersa entre configurações individuais de agentes. Quando as equipes de segurança perguntarem "quais servidores MCP nossos agentes podem acessar?", a resposta será "os que estiverem na lista de permissões do proxy". Isso é auditável. Pode ser alterado sem reconfigurar todos os agentes. E é o controle fundamental para evitar a classe de risco em que um novo servidor não avaliado entra no ciclo de ferramentas sem revisão.
O padrão de proxy MCP empresarial amplia isso ainda mais: escopo de ferramentas por usuário ou função, limites de taxa para categorias específicas de ferramentas e filtragem de saída nas respostas antes que cheguem ao agente. Os riscos de segurança no MCP não acontecem apenas no momento da autenticação. Eles também estão na cadeia de saída, e o proxy é onde você intercepta isso. Os controles de autenticação determinam o que é chamado. Os filtros de saída controlam o que retorna.
Quatro Padrões em que um Proxy MCP Resolve um Problema Arquitetural Real
Não se trata de linguagem sobre benefícios. Cada um é um modo de falha que o proxy evita.
Camada de segurança e governança empresarial
Uma equipe de engenharia de segurança que executa fluxos de agentes em backends de CRM, documentos internos e execução de código não tem um ponto central para auditar qual agente chamou qual ferramenta, com qual identidade e quando. Cada backend executa sua própria autenticação ou não executa nenhuma. O proxy se torna o ponto único de aplicação: cada solicitação passa por ele, a identidade é validada, o escopo é verificado e o registro completo das chamadas é capturado. Sem ele, a resposta a incidentes após um evento de envenenamento de ferramenta exige reconstruir o histórico de execução a partir de seis logs de servidor diferentes, se esses logs existirem. Implantar uma camada de governança aqui é a diferença entre "podemos investigar o que aconteceu" e "não podemos".
Hub de agregação para servidores MCP heterogêneos
Uma equipe de RevOps que usa Cursor precisa acessar ferramentas de um servidor de calendário, um servidor de CRM e uma base de conhecimento interna. Sem um proxy, Cursor precisa de três configurações de servidor separadas, três conjuntos de credenciais, e a equipe precisa atualizar cada cliente de agente toda vez que um backend muda. Com um proxy agregando os três atrás de um único ponto de entrada HTTP, a configuração do cliente permanece estável. Adicione um quarto backend ao registro do proxy e cada agente conectado o terá imediatamente. Na Latenode, isso corresponde a usar o MCP Server Builder integrado para expor capacidades controladas como uma superfície unificada de servidor MCP local para clientes como Claude Desktop, com o tratamento automático de credenciais OAuth da Latenode para as conexões subjacentes com servidores de recursos. Configuração de cliente limpa, acesso governado e o modelo de preços por execução mantêm a contabilidade simples à medida que a quantidade de backends cresce.
Ponte de transporte entre clientes e backends incompatíveis
Um servidor MCP de backend criado para ser executado localmente como um processo stdio precisa atender um cliente de agente baseado na web que fala HTTP streamable. Essas duas coisas não podem se conectar diretamente. Um proxy aceita a conexão HTTP do cliente e encaminha para o processo stdio do backend. O backend não muda de lugar. O cliente não muda. O proxy absorve a incompatibilidade. As equipes que implantam servidores MCP de forma incremental enfrentam isso constantemente: um servidor criado para desenvolvimento local de repente precisa atender agentes remotos. O proxy resolve isso sem exigir que o servidor seja reescrito.
Reempacotamento de capacidades com autenticação personalizada, limitação de taxa e análises
Uma equipe de plataforma de IA quer expor um subconjunto de ferramentas MCP internas para desenvolvedores externos sem expor diretamente os servidores de backend. Uma camada de proxy MCP de produção fica à frente, aplica autenticação por chave de API, aplica limites de taxa por solicitante, remove metadados internos das respostas e registra todas as chamadas para análises e faturamento. Sem essa camada, implantar capacidades MCP externamente significa expor a infraestrutura de backend diretamente. O proxy é onde você separa a interface pública da implementação interna. As equipes que pulam esta etapa e implantam servidores MCP diretamente se arrependem na primeira vez que um solicitante esgota a capacidade do backend ou extrai mais dados do que o previsto. A capacidade do proxy de reduzir a carga do backend por meio da aplicação de limites de taxa e cache é um benefício operacional real, não teórico.
Proxy MCP vs. Gateway de API: Por que a Distinção Importa para Arquitetos
Arquitetos que recorrem a um gateway de API para resolver problemas de governança MCP descobrirão que ele cobre cerca de 60% do que precisam e deixa de fora os 40% específicos do MCP. Vale a pena ser preciso sobre essa distinção.
| Capacidade | Gateway de API | Proxy MCP |
|---|---|---|
| Conhecimento do protocolo | HTTP/REST; roteia por URLs e cabeçalhos | Protocolo MCP; roteia por nome de ferramenta, recurso e prompt |
| Agregação de capacidades | Não; roteia para um upstream por endpoint | Sim; agrega ferramentas de vários backends em uma única superfície |
| Recursos específicos de MCP | Nenhum; sem encaminhamento de ferramentas nem roteamento de prompts/recursos | Nativo; delega chamadas de ferramentas, recursos e prompts entre backends |
| Ponte de transporte | Não; pressupõe HTTP nos dois lados | Sim; faz a ponte entre stdio, SSE e HTTP streamable |
| Caso de uso mais adequado | APIs REST, limitação de taxa, autenticação em tráfego HTTP | Implantações MCP com vários servidores, transportes mistos ou requisitos de governança |
Um gateway de API pode lidar com autenticação e limitação de taxa para tráfego HTTP, o que é realmente útil e vale a pena implantar na camada HTTP da sua pilha. A lacuna é a delegação: um gateway roteia ao corresponder URLs e invocar um upstream. Ele não tem mecanismo para descobrir que uma ferramenta chamada "search_docs" está no backend A e "create_ticket" está no backend B, agregá-las em uma lista única de capacidades e apresentá-las nativamente a um cliente. Isso não é um problema de configuração do gateway. É uma incompatibilidade arquitetural entre o que o gateway faz e o que o MCP exige.
📊 Na prática:
Um gateway de API configurado para rotear tráfego MCP pode encaminhar uma solicitação HTTP a um endereço de servidor proxy — ele é uma camada de transporte válida. O que ele não pode fazer é expor uma superfície unificada de ferramentas MCP a um cliente quando essas ferramentas estão distribuídas entre vários backends. O gateway vê URLs. Ele não vê namespaces de ferramentas. Um cliente que fala MCP com um gateway de API obtém roteamento. Não obtém agregação nem ponte de transporte. As duas camadas são complementares, não intercambiáveis.
