Criamos o Túnel MCP seguro porque os servidores MCP mais importantes para as equipes costumam ser justamente aqueles que elas menos querem expor à Internet.
Queríamos compartilhar como lidamos com essa restrição: manter os servidores privados e, ao mesmo tempo, oferecer ao ChatGPT, ao Codex e a outros produtos da OpenAI um caminho normal para requisições MCP.
O Model Context Protocol facilitou a conexão de sistemas de IA a ferramentas e dados externos. Mas muitos dos servidores MCP mais valiosos são executados em redes corporativas, malhas de serviços privadas, notebooks de desenvolvedores e outros ambientes projetados para rejeitar tráfego de entrada da rede pública. Para conectar esses servidores a produtos de IA hospedados, as equipes muitas vezes precisavam criar endpoints públicos, implantar infraestrutura adicional de proxy ou incluir novos operadores de rede em caminhos sensíveis.
O Túnel MCP seguro oferece uma abordagem mais simples: Os clientes executam um pequeno cliente de software em seu ambiente privado, que estabelece uma conexão HTTPS de saída com a OpenAI. Esse cliente:
- Recebe requisições MCP
- Encaminha essas requisições a um servidor local aprovado
- Retorna respostas e notificações pela mesma conexão.
Os produtos da OpenAI podem usar o modelo padrão de requisições e respostas do MCP, enquanto o servidor subjacente permanece protegido pelos controles de rede que o cliente já utiliza.
Para que isso funcionasse com confiabilidade e segurança, foi preciso resolver vários problemas de engenharia ao mesmo tempo: preservar os limites da rede privada do servidor, oferecer suporte aos fluxos de streaming e autenticação do MCP e fornecer às equipes um cliente de software que elas pudessem inspecionar e operar. Este artigo explica essas decisões.
Projetamos o túnel com base em um pequeno conjunto de princípios: conexões iniciadas apenas de dentro para fora, configuração explícita dos destinos, compatibilidade com streaming e notificações do MCP e um cliente de software executado pelo próprio cliente, que as equipes podem inspecionar e operar por conta própria.
Juntos, esses princípios permitem conectar facilmente ferramentas e dados privados aos produtos da OpenAI sem transformar servidores MCP privados em serviços públicos.
As escolhas habituais inadequadas
Hoje, as equipes geralmente tornam um serviço privado acessível de uma destas três formas: expõem um endpoint público, executam um túnel de terceiros ou ampliam a rede com uma VPN ou conexão de peering.
- Um endpoint público facilita o acesso ao enfraquecer os limites de proteção da rede.
- Um provedor de túneis de terceiros pode tornar um servidor privado acessível rapidamente, mas também acrescenta ao caminho da conexão mais um fornecedor que precisa ser avaliado, contratado e considerado confiável, além de um serviço a operar. Para equipes corporativas, isso não é um detalhe: o provedor do túnel passa a fazer parte da revisão de segurança, do processo de aquisição, dos procedimentos operacionais e da superfície de exposição de metadados de um sistema cujo propósito é manter as ferramentas privadas.
- VPNs e peering de rede resolvem o problema de acesso criando uma conectividade de rede ampla, o que costuma ser uma estrutura excessiva para uma integração MCP de escopo restrito.
O Túnel MCP seguro adota uma abordagem mais focada. Em vez de pedir aos clientes que movam o servidor MCP, ampliem o perímetro da rede ou incluam outro fornecedor de conectividade, o Túnel MCP seguro coloca um pequeno cliente de código aberto, que pode ser inspecionado, junto ao servidor privado e permite que esse cliente inicie e controle a conexão com a OpenAI.
O Túnel MCP seguro inverte a lógica de acesso: o lado privado toma a iniciativa. Os produtos da OpenAI enviam requisições MCP a um endpoint de túnel hospedado pela OpenAI. O serviço de túnel enfileira tarefas para um túnel específico, e o cliente de software, já em execução junto ao servidor MCP privado no ambiente do cliente, busca essas tarefas por uma conexão HTTPS de saída. O cliente de software encaminha a requisição localmente e retorna a resposta pelo mesmo caminho.
Isso oferece aos produtos da OpenAI um caminho normal para requisições MCP sem exigir que o servidor privado aceite tráfego de entrada da rede pública nem criar uma conectividade de rede mais ampla.
Figura 1. Ciclo de vida de uma requisição no Túnel MCP seguro.
Por que começar com long-polling?
Começamos deliberadamente com um transporte sem surpresas operacionais. Conexões HTTPS de saída já são familiares para firewalls corporativos, ambientes com proxy e equipes de plataforma. O long-polling permite que o cliente do túnel solicite apenas a quantidade de trabalho que consegue processar, criando um ponto natural de controle de fluxo na fila do cliente, em vez de incentivar o acúmulo ilimitado em buffers.
Essa escolha também manteve a implementação entregue fácil de entender:
- Um produto envia mensagens JSON-RPC do MCP ao endpoint hospedado pela OpenAI.
- O serviço de túnel mantém essa requisição em espera ou a transmite por streaming até que o cliente de software executado pelo cliente retorne uma resposta final
- Quando são solicitados resultados por streaming, o túnel pode encaminhar eventos intermediários enviados pelo servidor.
O resultado é um caminho normal de requisição e resposta MCP para o produto, enquanto o servidor MCP e seu endereço permanecem privados. Requisições, respostas e eventos intermediários são retransmitidos pelo endpoint de túnel hospedado pela OpenAI.
Mantendo os limites de segurança explícitos
O túnel não é uma forma de eliminar os limites da rede, mas de torná-los explícitos. O cliente do túnel executado pelo cliente se autentica no plano de controle do túnel, o lado do produto usa o endpoint de túnel hospedado pela OpenAI e o endereço MCP privado só é usado de dentro do ambiente do cliente. O acesso ao túnel fica vinculado ao contexto da organização e do workspace que o cliente já possui na OpenAI e à identidade configurada para o túnel, em vez de se tornar um caminho de rede separado com seu próprio modelo de acesso.
O projeto depende de mais do que escolher a direção correta da conexão de rede. Como o cliente do túnel é executado dentro do ambiente do cliente, seu comportamento precisa ser passível de inspeção e ter um escopo intencionalmente restrito: os clientes devem conseguir entender qual código está em execução, qual caminho de saída ele abre e quais serviços privados ele tem permissão para acessar.
Figura 2. O servidor MCP permanece dentro dos limites da rede do cliente.
Uma experiência de desenvolvimento MCP que parece local
Queríamos que o cliente do túnel fosse usado como uma ferramenta de desenvolvimento, não como um projeto de rede. Um desenvolvedor deve poder executar um servidor MCP em um notebook, iniciar o cliente do túnel junto a ele e conectar esse servidor ao ChatGPT ou ao Codex sem criar um endpoint público nem esperar por uma VPN, uma regra de firewall ou uma alteração de peering.
Esse mesmo fluxo deve continuar funcionando quando o servidor sair de um notebook e passar para o Kubernetes, uma VM ou outro ambiente controlado pelo cliente. O importante é que o modelo mental continue o mesmo: executar o cliente do túnel perto do servidor MCP privado, validar que ele consegue acessar o servidor e deixar que ele inicie o caminho de conexão com a OpenAI. As verificações de integridade e prontidão, os logs e a interface de administração local existem para permitir a inspeção desse ciclo quando algo não funciona, e não para transformar o túnel em um projeto de operações.
A experiência do desenvolvedor também está presente no próprio Codex. O cliente do túnel inclui um plug-in do Codex que transforma a configuração em um fluxo de trabalho guiado, em vez de exigir que os desenvolvedores aprendam de antemão cada flag, perfil e detalhe do plano de controle do tunnel-client. O objetivo não é criar um atalho local para uso pontual: o plug-in deve produzir a mesma estrutura de configuração que a equipe poderá manter quando o servidor sair de um notebook e passar para o Kubernetes, uma VM ou outro ambiente de produção.
A mesma ideia aparece no fluxo de trabalho do assistente incluído no tunnel-client: como o assistente pode ler o contexto local do túnel exposto pelo tunnel-client, ele pode ajudar o desenvolvedor a analisar a configuração real, em vez de se basear em instruções genéricas: qual perfil está ativo, qual configuração foi gerada, se o servidor MCP local está acessível e em que etapa da inicialização o cliente do túnel se encontra. Isso torna a solução de problemas parte do ciclo de desenvolvimento, em vez de um processo separado de escalonamento.
Figura 3. O mesmo ciclo do tunnel-client funciona do notebook à produção.
Por que é importante ter um cliente de túnel de código aberto
O cliente do túnel é um software de código aberto executado pelo próprio cliente dentro dos limites de sua rede, junto aos servidores MCP privados. Isso permite que clientes e revisores de segurança inspecionem o código em execução em seu ambiente. Eles podem inspecionar o que o cliente do túnel faz, qual conexão de saída ele abre, como encaminha requisições MCP localmente e qual configuração controla seu alcance.
Essa transparência mantém o modelo de confiança alinhado à arquitetura: a OpenAI hospeda o serviço de túnel, mas o código executado dentro do ambiente do cliente é pequeno, pode ser revisado e está sob o controle do cliente.
Autenticação corporativa sem acesso amplo à rede
Servidores MCP privados raramente são apenas endpoints HTTP internos de acesso anônimo. Eles podem depender de OAuth, autoridades certificadoras privadas, proxies de saída ou certificados de cliente na conexão com o MCP. Para oferecer suporte a esses servidores, foi preciso incorporar as premissas das redes corporativas ao projeto do túnel, em vez de tratá-las como exceções que os clientes precisam contornar.
A restrição central é que o servidor MCP continua privado. A descoberta OAuth do servidor MCP percorre o caminho do túnel, permitindo que o produto hospedado descubra como se autenticar sem exigir que o servidor MCP aceite conexões da Internet pública. No lado do cliente, o cliente do túnel pode ser configurado para o ambiente local: pacotes personalizados de certificados de CA, configurações de proxy e mTLS no lado do MCP.
Também mantivemos os limites explícitos. O túnel não torna automaticamente todos os endpoints corporativos relacionados acessíveis pela OpenAI. Se um servidor de autorização for privado, ele ainda precisará estar acessível ao componente que executa o fluxo OAuth. Esse limite é intencional: o Túnel MCP seguro oferece um caminho restrito para ferramentas privadas configuradas, não uma ponte de rede de uso geral.
Além do MCP
O MCP é o formato principal para ferramentas de modelos, mas os primeiros testes alfa com clientes revelaram um problema relacionado: nem todo fluxo de trabalho privado do cliente já está implementado como um servidor MCP. Alguns fluxos de trabalho importantes são APIs REST existentes, protegidas pelo mesmo firewall. Se o Túnel MCP seguro resolvesse apenas o acesso ao MCP, as equipes ainda precisariam de um endpoint público separado, um provedor de túneis, um caminho via VPN ou um projeto de peering para essas APIs privadas relacionadas.
O Harpoon estende o mesmo modelo de conectividade restrita a destinos REST aprovados. Em vez de expor URLs arbitrárias, o cliente registra destinos identificados por rótulos no cliente do túnel. Os componentes do lado da OpenAI fazem chamadas a esses rótulos por meio do Túnel MCP seguro, e a requisição HTTP em si continua partindo de dentro do ambiente do cliente, junto ao serviço privado.
A restrição importante é que os rótulos não são uma ponte de rede de uso geral. As chamadas continuam limitadas pelo registro de destinos sob controle do cliente, pelos métodos permitidos, pelos limites de tamanho das respostas, pelos tempos limite, pelo comportamento de redirecionamento e pelos controles de acesso ao túnel. Isso oferece aos fluxos de trabalho aprovados da OpenAI um caminho controlado para as APIs privadas do cliente, sem exigir que ele abra o acesso de entrada à rede nem conceder à OpenAI uma identidade semelhante à de uma VPN.