Túneis MCP do Claude: Acesso Privado ao MCP para Agentes

Anthropic anunciou túneis MCP para Agentes Gerenciados Claude em 19 de maio de 2026, juntamente com sandboxes auto-hospedados. A ideia importante é estreita, mas útil: os agentes Claude podem acessar servidores do Protocolo de Contexto do Modelo que vivem dentro de uma rede privada sem exigir que esses servidores exponham endpoints públicos.

A funcionalidade ainda é uma prévia de pesquisa. Isso é importante. Este não é um produto de rede de disponibilidade geral, e não é algo que se possa descrever como comprovado em produção a partir de um pequeno experimento local. Os documentos da Anthropic dizem que o acesso deve ser solicitado, a funcionalidade é fornecida sem garantias de continuidade, e o transporte depende do Cloudflare como um provedor terceirizado.

A Effloow Lab executou um PoC de sandbox local para a parte que pode ser testada com segurança sem credenciais: um servidor semelhante ao MCP de loopback, um gateway que roteia por nome de host e uma verificação de negação por padrão para hosts desconhecidos. A nota de evidência está em data/lab-runs/claude-mcp-tunnels-research-preview-developer-guide-2026.md.

Limite: A Effloow Lab não criou um túnel Anthropic ao vivo, chamou Agentes Gerenciados Claude, usou uma chave de API da Anthropic, testou o transporte do Cloudflare, validou certificados TLS ou mediu latência, tempo de atividade, custo ou segurança. O PoC valida a forma de roteamento, não o serviço hospedado.

Por Que Isso Importa

O MCP facilitou a padronização das integrações de agentes, mas também criou um problema de implantação. Um servidor MCP interno útil muitas vezes precisa acessar sistemas privados: ferramentas de ticket, armazéns de dados, catálogos de serviços, repositórios de código-fonte, runbooks, registros de cobrança, notas de clientes ou APIs internas. Publicar esses servidores na internet pública apenas para que um agente hospedado possa chamá-los é um padrão ruim.

Os túneis MCP são a resposta da Anthropic para essa lacuna. O anúncio oficial diz que um gateway leve funciona dentro da sua rede e faz uma única conexão de saída. O agente pode então acessar servidores MCP privados através do túnel sem regras de firewall de entrada ou endpoints públicos.

Isso muda a conversa sobre implantação. Em vez de perguntar se cada ferramenta interna pode ser tornada pública o suficiente para um agente, as equipes podem perguntar quais servidores MCP privados merecem uma rota controlada, quais ferramentas devem ser habilitadas, quais escopos OAuth devem se aplicar e quais logs devem existir antes que um fluxo de trabalho entre em operação.

É também por isso que os túneis MCP devem ser avaliados com sandboxes auto-hospedados, mas não confundidos com eles. Sandboxes auto-hospedados decidem onde a execução da ferramenta do agente ocorre. Os túneis MCP decidem como Claude acessa servidores MCP privados. Os documentos da Anthropic dizem que estes são independentes: uma sessão hospedada pela Anthropic pode usar um túnel, e uma sessão auto-hospedada pode usar servidores MCP públicos ou tunelados.

O Que a Anthropic Realmente Lançou

O anúncio da Anthropic em 19 de maio introduziu duas atualizações voltadas para empresas para Agentes Gerenciados:

• Sandboxes auto-hospedados, disponíveis em beta público, para executar a execução de ferramentas em infraestrutura controlada pelo cliente ou por um provedor suportado.
• Túneis MCP, disponíveis em prévia de pesquisa, para conectar Agentes Gerenciados e a API de Mensagens a servidores MCP privados.

A visão geral do túnel MCP diz que a pilha de implantação tem dois componentes dentro da rede do cliente:

• cloudflared, que inicia conectividade somente de saída para a borda do túnel.
• Um componente proxy da Anthropic, que valida IPs de upstream e roteia solicitações para o servidor MCP upstream correto com base no nome do host.

Cada servidor MCP exposto recebe um nome de host sob o domínio do túnel, como docs.<seu-dominio-do-tunel>. Uma vez que o túnel tenha um certificado ativo e a pilha esteja conectada, os servidores MCP roteados podem ser usados a partir de Agentes Gerenciados Claude ou da API de Mensagens através do conector MCP.

A forma da API de Mensagens é familiar se você já usa servidores MCP remotos: passe uma URL de servidor em mcp_servers, referencie-a com um mcp_toolset, e inclua o cabeçalho beta atual do conector MCP. A diferença é que o host pertence ao seu domínio de túnel em vez de um endpoint MCP público.

PoC de Sandbox da Effloow Lab

O PoC da sandbox usou Node.js v25.9.0 em /tmp/effloow-claude-mcp-tunnel-poc. Ele criou:

• Um servidor HTTP semelhante ao MCP privado em 127.0.0.1.
• Um gateway em 127.0.0.1.
• Um nome de host permitido, echo.local-tunnel.test.
• Um nome de host bloqueado, admin.local-tunnel.test.

O cliente local chamou o gateway três vezes. O host permitido pôde listar ferramentas e chamar a ferramenta determinística hello. O host bloqueado recebeu 403.

tools_list_status=200
tools_list_body={"jsonrpc":"2.0","id":1,"result":{"tools":[{"name":"hello","description":"Retorna uma saudação determinística"}]}}
tool_call_status=200
tool_call_body={"jsonrpc":"2.0","id":2,"result":{"content":[{"type":"text","text":"hello private-mcp"}]}}
blocked_status=403
blocked_body={"error":"host_not_allowed","host":"admin.local-tunnel.test"}

Duas falhas foram úteis. Primeiro, o script JavaScript gerado falhou porque uma string de template aninhada não foi escapada. Em segundo lugar, o cliente fetch do Node manteve o cabeçalho Host de loopback, então o gateway negou cada solicitação até que o cliente mudasse para http.request com um cabeçalho Host explícito. Ambas as falhas estão registradas na nota do laboratório porque correspondem à verdadeira lição operacional: o roteamento do túnel não é mágica; nomes de hosts, cabeçalhos e tabelas de rotas devem se alinhar exatamente.

O resultado é modesto, mas relevante. O PoC local mostra por que a tabela de rotas do proxy é importante, por que nomes de hosts desconhecidos devem falhar de forma restritiva e por que um desenvolvedor deve testar um servidor MCP com um nome de host realista antes de culpar Claude ou o modelo.

A Arquitetura Na Prática

Para uma implantação real de túnel MCP, pense em camadas:

Agente Gerenciado Claude ou API de Mensagens
  -> configuração do conector MCP
  -> nome do host do túnel
  -> transporte de túnel de saída
  -> tabela de rotas do proxy
  -> servidor MCP privado
  -> sistema interno downstream

O modelo não deve ser a fronteira de segurança. O túnel também não deve ser a única fronteira de segurança. A orientação de segurança da Anthropic diz que cada servidor MCP deve exigir OAuth, os intervalos de IP de upstream devem ser restritos, as credenciais devem ser rotacionadas, os logs devem ser monitorados e os servidores MCP devem expor apenas as ferramentas e dados necessários para seu propósito.

Esse último ponto é fácil de pular. Se um servidor MCP interno expõe search_docs, create_ticket, delete_customer e run_sql através de um único endpoint amplo, um túnel o torna acessível, mas não automaticamente seguro. Um padrão melhor é dividir os servidores MCP por tarefa e risco:

• docs-readonly para recuperação de base de conhecimento.
• tickets-draft para criar tickets em rascunho, mas não fechar incidentes.
• billing-audit para ler o histórico da conta, mas não mudar o estado de pagamento.
• deploy-status para metadados de implantação sem ferramentas de mutação de produção.

Os documentos do conector MCP dos Agentes Gerenciados também suportam configuração de ferramentas. Por padrão, todas as ferramentas expostas por um servidor estão habilitadas, mas você pode desabilitar o padrão e habilitar explicitamente apenas ferramentas específicas. Para fluxos de trabalho de produção, a lista de permissões deve ser o caminho normal.

Caminho de Configuração Para Desenvolvedores

O quickstart da Anthropic usa Docker Compose com credenciais manuais. A pilha documentada contém uma