Secure MCP Tunnels da OpenAI: Como Funcionam (Guia de 2026)

Em 27 de maio de 2026, a OpenAI lançou o Secure MCP Tunnel. A promessa é pequena e específica: mantenha seu servidor MCP privado e ainda permita que os produtos da OpenAI o chamem. O guia oficial e o repositório do cliente estão citados na íntegra na seção de fontes ao final deste artigo, para que você possa ler a documentação primária após o passo a passo.

1. TL;DR

Use o Secure MCP Tunnel quando você tiver um servidor MCP em um laptop, uma VM, um cluster Kubernetes ou uma rede privada, e quiser que o ChatGPT, Codex, a Responses API ou o AgentKit o utilizem sem torná-lo público. Você executa um pequeno daemon chamado tunnel-client ao lado do servidor. Ele se conecta à OpenAI via HTTPS, faz long-polling por trabalho, encaminha cada solicitação para seu servidor e posta a resposta de volta. Sem portas de entrada, sem URL pública, sem ngrok.

Ignore se o seu servidor MCP já estiver publicamente seguro (apenas use a ferramenta MCP hospedada normal com uma server_url), ou se você não estiver disposto a rotear o tráfego MCP através de um endpoint hospedado pela OpenAI. E leia a seção de segurança duas vezes: o túnel remove exposição de rede e de credenciais, não risco de prompt-injection ou tool-poisoning. Esses são problemas diferentes.

2. O que é

Aqui está a definição retirada diretamente da documentação, que vale a pena citar na íntegra porque os mecanismos de busca de IA a extraem diretamente:

“Secure MCP Tunnel permite conectar servidores MCP privados a produtos da OpenAI compatíveis sem abrir portas de firewall de entrada ou expor esses servidores à internet pública.”

E o túnel em si, um nível abaixo: “Um MCP tunnel é uma conexão apenas de saída de um host dentro da sua rede para um endpoint MCP hospedado pela OpenAI.” Essa única palavra — outbound-only — é todo o design. Sua rede nunca aceita uma conexão da OpenAI. Ela apenas as realiza.

MCP (Model Context Protocol) é o padrão aberto que permite que um modelo de IA chame ferramentas externas via JSON-RPC. Uma ferramenta MCP hospedada normalmente precisa de um server_url — os próprios exemplos da OpenAI apontam para coisas como https://mcp.stripe.com. O Secure MCP Tunnel remove esse requisito. O servidor pode permanecer em localhost.

3. Por que ele existe

Antes disso, conectar um servidor MCP privado a um modelo hospedado significava uma de três escolhas desconfortáveis. Cada uma possui um modo de falha que uma equipe de segurança bloqueará.

1. Exponha-o publicamente. Coloque o servidor MCP em uma URL pública com TLS e autenticação. Agora você possui uma nova superfície de ataque voltada para a internet, e servidores MCP expostos acidentalmente são um problema real documentado.
2. Crie um túnel com ngrok ou Cloudflare Tunnel. Funciona, mas é um reverse proxy de propósito geral. Quick tunnels “não foram projetados como limites de segurança” — CORS aberto por padrão, sem filtragem de caminho, sem reconhecimento de MCP.
3. Abra uma regra de firewall de entrada. A opção que sua equipe de segurança menos aprova, e a única que uma máquina de desenvolvedor não pode oferecer de forma alguma.

A resposta do Secure MCP Tunnel é inverter a conexão. A documentação deixa claro: o acesso via tunnel “segue o contexto existente da organização e do workspace em vez de introduzir um caminho de entrada público separado.” Você não está criando uma nova porta de entrada. Você está permitindo que um daemon que você controla saia pela porta que você já possui.

4. Modelo Mental: As Peças Nomeadas

Cinco peças compõem todo o recurso. Aprenda esses nomes e a documentação será lida de uma só vez.

O fluxo de dados é um loop de polling, não um socket persistente que a OpenAI mantém aberto na sua rede. Leia de cima para baixo:

        OpenAI cloud                         Your network (trust boundary)
 ┌─────────────────────────┐          ┌──────────────────────────────────────┐
 │ ChatGPT / Codex /        │          │                                        │
 │ Responses API / AgentKit │          │   tunnel-client (daemon)               │
 │           │              │          │        │            │                  │
 │           v              │          │        │            v                  │
 │  OpenAI-hosted tunnel    │  <====== │  (1) outbound HTTPS long-poll          │
 │  endpoint  (queues work) │          │      GET /v1/tunnel/{id}/poll          │
 │           │              │  ======> │  (2) queued JSON-RPC request           │
 │           ^              │          │        │                               │
 │           │              │          │        v                               │
 │  (4) response returns    │  <====== │  (3) forward to private MCP server     │
 │      to the product      │          │      (stdio command or HTTP URL)       │
 └─────────────────────────┘          │        │                               │
                                       │        v                               │
                                       │   Private MCP server (localhost / VPC) │
                                       └──────────────────────────────────────┘
   The MCP server never has a public listener. Every arrow your network draws
   is OUTBOUND. OpenAI never initiates a connection into your boundary.

Conclusão opinativa: o design de polling é o ponto principal. Um daemon que apenas realiza conexões de saída é algo que um firewall e um revisor de segurança podem realmente analisar. Um socket de entrada persistente, não.

5. Exemplo de ponta a ponta mais simples

Este é o quickstart canônico da documentação, na íntegra. Ele pressupõe que você já criou um túnel nas configurações de túnel da Platform e possui seu tunnel_id. Ele aponta o túnel para um stdio local Servidor MCP — um script Python iniciado por um comando.

export CONTROL_PLANE_API_KEY="sk-..."

tunnel-client init \
  --sample sample_mcp_stdio_local \
  --profile local-stdio \
  --tunnel-id tunnel_0123456789abcdef0123456789abcdef \
  --mcp-command "python /path/to/server.py"

tunnel-client doctor --profile local-stdio --explain
tunnel-client run --profile local-stdio

Três comandos realizam o trabalho. init escreve um perfil nomeado a partir de um exemplo. doctor --explain verifica o perfil e informa a você o motivo de qualquer problema de integridade antes que você dependa dele. run inicia o loop de polling do daemon. Mantenha-o run ativo enquanto você cria e testa o connector — a documentação é explícita ao dizer que “a descoberta de connector e as chamadas de ferramentas MCP dependem do cliente em execução.”

Se o seu servidor MCP utiliza HTTP em vez de stdio, alterne uma flag — use --mcp-server-url no lugar de --mcp-command:

tunnel-client init \
  --sample sample_mcp_stdio_local \
  --profile local-http \
  --tunnel-id tunnel_0123456789abcdef0123456789abcdef \
  --mcp-server-url https://mcp.internal.example.com/mcp

Em seguida, confirme se o daemon está realmente íntegro antes de tocar no ChatGPT. tunnel-client expõe endpoints de operador e uma UI de administração loopback exatamente para isso:

curl -fsS http://127.0.0.1:8080/healthz   # process is up
curl -fsS http://127.0.0.1:8080/readyz    # connected and polling
open    http://127.0.0.1:8080/ui          # local admin UI (loopback-only)

6. Análise detalhada de cada componente

6.1 O ciclo de vida da requisição

A documentação descreve o loop em cinco etapas. Um produto envia uma requisição MCP para o endpoint hospedado pela OpenAI. O endpoint a coloca na fila. tunnel-client faz long-polling para trabalho em fila, encaminha cada requisição JSON-RPC para seu servidor MCP privado e posta a resposta de volta através do mesmo túnel. Quando um connector solicita resultados via streaming, o caminho pode encaminhar eventos intermediários enviados pelo servidor (server-sent events), para que as ferramentas de streaming continuem funcionando. O ponto de iniciação da rede sempre permanece dentro do seu limite.

Conclusão opinativa: “long-poll, então encaminhe apenas o que você consegue processar” oferece um controle de fluxo (backpressure) natural. Seu servidor nunca é atingido por uma enxurrada de requisições da OpenAI — o cliente busca o trabalho no seu próprio ritmo.

6.2 tunnel-client e perfis

tunnel-client é um binário em Go, de código aberto sob openai/tunnel-client. The docs are firm about distribution: get it from the Platform download link or the latest public release, and “keep your runbook pointed at the latest-release URL instead of hard-coding a specific release URL.” It is not on npm or PyPI. A profile é uma configuração nomeada (o local-stdio acima), permitindo que um host execute vários túneis com configurações diferentes. Você também pode controlar tudo por meio de variáveis de ambiente e flags, com a precedência flags > env vars > YAML > defaults.

Recomendação: use profiles, não uma lista interminável de flags. Um diretório profiles/ versionado com segredos referenciados como env:VARNAME ou file:/path é a diferença entre um deploy reproduzível e algo descartável que você não consegue reconstruir.

6.3 Onde executar

Execute o tunnel-client no mesmo limite de confiança que já consegue acessar o servidor MCP. A documentação cita três padrões:

• Sidecar no Kubernetes — execute-o ao lado do servidor MCP no mesmo Pod e conecte-se via localhost.
• Deployment dedicado no Kubernetes — execute-o separadamente quando o servidor já estiver acessível por meio de um Service privado.
• VM ou serviço systemd — execute-o em um host que consiga alcançar o servidor por rede privada.

Recomendação: o sidecar é o padrão mais limpo. Mesmo Pod, localhost hop, um ciclo de vida. Recorra ao deployment dedicado apenas quando várias cargas de trabalho compartilharem um mesmo serviço MCP.

6.4 Permissões e identidade

O acesso ao tunnel utiliza o contexto da sua organização e workspace existentes. Três átomos de permissão controlam esse acesso, mapeando-se para funções reais:

A API key de runtime que o tunnel-client executa precisa de Read + Use. Uma identidade de gerenciamento separada precisa de Read + Manage para criar ou editar metadados de tunnel. Mantenha-os separados — o daemon nunca deve possuir direitos de criação/exclusão.

Conclusão prática: o princípio do privilégio mínimo já está integrado, então utilize-o. O daemon de longa duração recebe Use, enquanto um humano ou job de CI recebe Manage, e os dois nunca compartilham a mesma chave.

6.5 Harpoon: chamadas HTTP em allowlist

Além do MCP, tunnel-client envia um servidor MCP integrado chamado Harpoon que expõe um pequeno conjunto de endpoints REST privados por rótulo, com tamanhos de solicitação e resposta limitados. Ele serve para acessar alguns serviços internos sem torná-los públicos. A documentação é clara: “O Harpoon não é um proxy de uso geral: os chamadores não podem escolher hosts arbitrários, e as solicitações são limitadas aos destinos e métodos configurados pelo cliente.”

Conclusão: O Harpoon é um bisturi, não uma VPN. Se você sentir necessidade de usá-lo para acessar “qualquer coisa interna”, você superou a ferramenta e deve expor um servidor MCP adequado.

6.6 OAuth através do tunnel

Se o seu servidor MCP usa OAuth, há um detalhe que lhe custará uma tarde inteira se você não prestar atenção. A descoberta de OAuth (discovery) pode passar pelo tunnel-client tunnel, e o tunnel preserva os metadados do servidor de autorização upstream para fluxos voltados ao navegador. Mas, nas palavras da própria documentação: “O servidor de autorização em si não é automaticamente tunelado. Se ele estiver inacessível a partir da internet pública e do host, o fluxo de OAuth ainda pode falhar, mesmo que o servidor MCP esteja acessível.”

Conclusão: faça o tunnel do servidor MCP, mas certifique-se de que o servidor de autorização OAuth esteja acessível a partir de onde o navegador e o cliente são executados. Um servidor MCP acessível com um servidor de autenticação inacessível resulta em uma falha silenciosa e confusa.

7. O que entendemos errado

Quatro suposições nos prejudicaram na primeira execução. Elas são exatamente as coisas que a frase de marketing faz você acreditar.

Supusemos que “privado” significava que os dados nunca chegariam à OpenAI. Não significa isso. O endereço do seu servidor e as credenciais permanecem locais, mas os payloads de solicitação e resposta do MCP ainda transitam pelo endpoint hospedado da OpenAI, exatamente como qualquer outra chamada de ferramenta hospedada. O tunnel oculta onde seu servidor está localizado; ele não mantém o tráfego da ferramenta fora da plataforma da OpenAI. Se um payload é sensível demais para ser enviado a um modelo hospedado, um tunnel não muda isso.

Supusemos que era o “ngrok da OpenAI.” Ele é mais restrito propositalmente. O ngrok encaminha tráfego arbitrário para uma porta. O tunnel encaminha JSON-RPC do MCP para seu servidor MCP, além de HTTP estritamente permitido via Harpoon. Essa restrição é um recurso, não uma funcionalidade ausente.

Nós fomos procurar por npm install. Não existe um. tunnel-client é um binário baixado ou uma build Go openai/tunnel-client. Perdemos dez minutos assumindo que um pacote existia porque todos os outros SDKs da OpenAI possuem um.

Assumimos que um tunnel torna toda a configuração “segura.” Ele protege o caminho da rede. Ele não faz nada contra uma chamada de ferramenta maliciosa ou

8. Padrões Errados vs. Certos

9. Erros Comuns (Extraídos da Documentação)

Estes pontos vêm diretamente das notas oficiais de solução de problemas e configuração, com a causa raiz ao lado do sintoma.

• Tunnel não visível no ChatGPT. Causa raiz: o tunnel não está associado ao workspace de destino, ou o operador do conector não possui a permissão Tunnels Use. Corrija o escopo do workspace e a permissão.
• A descoberta do conector ou as chamadas de ferramenta falham. Causa raiz: tunnel-client run parado. A descoberta e as chamadas dependem do cliente em execução. Reinicie-o e execute novamente doctor --explain.
• Você pode visualizar um tunnel, mas não pode editá-lo. Causa raiz: o operador possui Tunnels Read, mas não Manage. Conceda a permissão Manage à identidade que edita os metadados.
• O OAuth falha mesmo com o servidor MCP acessível. Causa raiz: o servidor de autorização não está via tunnel e está inacessível a partir da internet pública e do host do cliente. Torne o servidor de autenticação acessível.
• As solicitações através do tunnel falham intermitentemente. Causa raiz: o cliente não está conectado. Se tunnel-client estiver reconectando, as solicitações falharão até que ele retorne. Monitore /readyz e /metrics.

10. Notas sobre Desempenho, Escalabilidade e Custo

Números honestos primeiro: a OpenAI não publica números de latência ou throughput específicos de tunnel, e não há um preço documentado para tunnel. O que a documentação e o repositório fornecem são os controles que moldam o comportamento.

• Tempo de long-poll. O cliente faz long-polls em busca de trabalho; a janela de polling e o limite de requisições em trânsito são configuráveis. Ajuste-os para equilibrar conexões ociosas com a latência de resposta.
• TTL da conexão. A janela de conexão MCP é limitada (o padrão do repositório é da ordem de minutos). Uma ferramenta que execute por mais tempo que a janela deve transmitir o progresso ou finalizar a tempo, caso contrário, será encerrada.
• Backpressure é gratuito. Como o cliente busca o trabalho em vez de receber pushes, um servidor MCP lento reduz sua própria entrada em vez de colapsar sob carga. Você escala executando mais clientes ou um servidor mais robusto, não absorvendo uma enxurrada de requisições.
• Custo. Para a ferramenta MCP hospedada em geral, a OpenAI diz que você paga apenas pelos tokens usados na importação de definições de ferramentas ou na realização de chamadas de ferramentas, sem taxa extra por chamada. Uma cobrança específica de tunnel não está especificada na documentação — verifique nas configurações da Platform antes de assumir que é gratuito em escala.

11. Para quem é isso (e para quem não é)

12. Sinal da Comunidade

O anúncio veio da conta de desenvolvedor da OpenAI e foi amplificado por Greg Brockman, descrevendo-o como “traga seus próprios servidores MCP.”

A arquitetura não é exclusiva da OpenAI. A Anthropic lançou um padrão de túnel MCP funcionalmente similar semanas antes, e a modelo de segurança — mover as credenciais para o perímetro significa que um agente

Vale a pena citar a voz contrária. A principal crítica nessa thread resume o trade-off claramente:

“Você não é dono do loop. Você é dono da fronteira. Se essa troca será vantajosa para você depende de quanto você confia [no fornecedor] para executar o loop e de quanto vendor lock-in você consegue tolerar.”
— r/mcp, sobre o padrão de arquitetura de túnel

Outros na mesma thread levantaram a pergunta óbvia: “o que impede que o certificado local seja vazado/roubado?” e observaram que mover o risco de tokens para o uptime do fornecedor é apenas uma transferência, não uma eliminação. São pontos justos. Um túnel é uma troca: menos exposição de rede, mais dependência de um plano de controle hospedado pela OpenAI.

13. O Veredito: Vale a pena usar?

14. O panorama geral

O Secure MCP Tunnel é um movimento dentro de uma mudança maior: os principais fornecedores de modelos estão correndo para tornar suas ferramentas privadas utilizáveis por seus agentes hospedados sem que você exponha nada. A Anthropic fez isso. A OpenAI fez isso. O padrão compartilhado — apenas de saída, credenciais no perímetro, loop executado pelo fornecedor — está se tornando o formato empresarial padrão para conectividade de agentes. Espere que o Google e outros lancem a mesma primitiva sob nomes diferentes.

Para os próximos passos práticos, nosso Guia de Configuração de Servidores MCP cobre a conexão de servidores tutorial Construa seu Próprio Servidor MCP mostra como escrever o servidor que você colocaria atrás de um túnel, e o guia do SDK Python para Agentes da OpenAI explica o

15. Perguntas Frequentes

16. Glossário

• MCP: Model Context Protocol, o padrão aberto para permitir que modelos chamem ferramentas externas via JSON-RPC.
• Servidor MCP: um processo que expõe ferramentas, recursos e prompts para um cliente MCP.
• Secure MCP Tunnel: recurso da OpenAI para conectar um servidor MCP privado aos seus produtos sem um listener público.
• tunnel-client: o daemon executado pelo cliente que faz polling na OpenAI e encaminha solicitações para o seu servidor MCP.
• Endpoint de túnel hospedado pela OpenAI: o edge público que os produtos OpenAI chamam; ele enfileira o trabalho para o seu túnel.
• tunnel_id: a identidade do túnel, formato tunnel_ mais 32 caracteres hexadecimais.
• chave de API de runtime: a credencial que o tunnel-client usa; requer Tunnels Read + Use.
• outbound-only: o tráfego é sempre iniciado de dentro da sua rede; a OpenAI nunca inicia a conexão de fora.
• long-poll: o cliente mantém uma requisição HTTP aberta aguardando trabalho na fila, em vez de receber um push.
• transporte stdio: um servidor MCP iniciado por um comando e com o qual se comunica via entrada/saída padrão.
• Harpoon: um servidor MCP embutido no tunnel-client para chamadas HTTP privadas restritas a uma lista de permissões.
• mTLS: TLS mútuo, onde tanto o cliente quanto o servidor apresentam certificados; opcional para o plano de controle e o lado do MCP.
• conector: o objeto do lado do ChatGPT que aponta para uma fonte de ferramenta, incluindo um tunnel.
• Ferramenta MCP hospedada na Responses API: o mcp tool type that lets the API call an MCP server, normally via a public server_url.

17. Todas as Fontes e Links

Fontes Primárias

• OpenAI: Guia de túnel MCP seguro
• openai/tunnel-client no GitHub
• OpenAI: MCP e Conectores (ferramenta MCP hospedada)
• Especificação de autorização MCP (OAuth 2.1)

Comunidade

• @OpenAIDevs: Tweet de lançamento do túnel MCP seguro
• r/mcp: a arquitetura de túnel e a crítica ao lock-in
• r/OpenAI: Reação ao suporte MCP no ChatGPT

Contexto de Web & Segurança

• Invariant Labs: Ataques de envenenamento de ferramentas MCP
• Cloudflare: servidores MCP remotos (tunneling de prior-art)
• Solo.io: falhas de segurança em servidores MCP

Links Internos

• Guia de Configuração de Servidores MCP
• Crie seu próprio servidor MCP
• Diretório dos principais servidores MCP
• Guia do SDK Python para Agentes da OpenAI