什么是 MCP Tunnels？让 AI Agent 安全访问企业内部系统的核心技术全解析

30秒快速回答： MCP Tunnels（MCP 隧道）是一种把连接方向颠倒过来的企业级网络技术：运行在云端的 AI Agent 想调用你公司私有网络里的 MCP 服务器时，不再需要对外开端口、暴露公网 IP、拉 VPN 或走防火墙审批，而是由内网里一个小隧道程序主动向外拨号，建立一条加密的 outbound-only（仅出站）长连接，AI 的请求沿着这条隧道进来、再原路返回。2026 年 5 月，Anthropic 与 OpenAI 先后推出各自的 MCP Tunnel 方案（前者 research preview，后者 Secure MCP Tunnel 已 GA），标志着”AI 连接企业核心系统”这条最难走的路，第一次有了标准答案。

核心价值一句话： 你的 MCP 服务器永远不需要被公网摸到，AI Agent 却能安全地用它干活——企业的数据边界没破，AI 的接入需求也满足了。

为什么 AI 一直进不了企业内网？

理想场景很简单：让 Claude、ChatGPT 这类云端 Agent 直接调用你内网的 Jira、Salesforce、数据库、工单系统。但现实里它被卡在了一道墙前面——你的 MCP 服务器在防火墙后面，云端 Agent 根本够不着。

2023-2025 年大家只能在这几种方案里硬选，各有各的痛：

方案	做法	致命问题
公网暴露	把 MCP Server 绑到公网	2026 年初已有 8000+ 个 MCP 服务器因绑定 `0.0.0.0:8080` 且无鉴权被意外暴露，安全团队一票否决
VPN	让云端 Agent 拨入内网	无法给”一个 AI 会话”精细化授权，密钥管理混乱
反向代理/端口映射	在防火墙上开入站规则	安全、网络、合规三方审批，周期以”周”为单位，动不动排到明年
私有化部署	把 Agent 也搬进内网	失去了托管 Agent 的维护便利，多数团队没有这个条件

核心矛盾在于：企业安全团队的原则是”默认拒绝开入站端口”，而传统方案全都要求破坏这条原则。MCP Tunnels 的答案是把问题绕开——既然”进不来”是因为对方要往里进，那就让里面的人主动出去迎接。

它到底怎么工作的？outbound-only 架构图解

MCP Tunnels 的核心设计只有一句话：连接方向反转。整个栈分三段：

托管 AI Agent（云端）
        │  ① Agent 发起工具调用
        ▼
Provider 隧道边缘（云厂商侧 Edge）
        │  ② outer mTLS 加密
        ▼  ③ 沿已建立的 outbound 长连接下发
┌───────────────────────── 企业网络边界 ─────────────────────────┐
        │  ④ 内网隧道组件接收（cloudflared / tunnel-client）
        ▼
        │  ⑤ Proxy 终止内层 TLS（证书：企业自持）并校验来源 IP
        ▼
        私有 MCP Server（Jira/Salesforce/数据库…，全程不出内网）
        │  ⑥ 响应沿原路返回

部署在内网的有两个关键组件：

tunnel 连接器（Anthropic 用 cloudflared，OpenAI 用 tunnel-client）：只做一件事——向外拨号，建立一条长期保持的 outbound HTTPS 连接。对企业防火墙来说，这跟内网主机访问外网网页没有任何区别，443 出站本就是默认放行的，所以无需任何防火墙变更。
Proxy 代理（Anthropic 的 mcp-proxy）：终止内层 TLS，校验上游来源 IP 是否在允许范围内，再按主机名把请求路由到对应的内部 MCP 服务器。

对开发者来说，接入体验和普通 MCP 完全一致：在控制台里创建一个隧道、选一个内部 MCP 服务器、挂到 Agent 会话上，就能直接调用工具了。

三层安全模型：为什么连传输商都读不到你的数据

很多人会下意识担心：”隧道走了第三方网络（Cloudflare），数据不就被它看到了吗？” MCP Tunnels 用三层互相独立的纵深防御回答了这个问题：

安全层	机制	防住什么
外层 mTLS + IP 校验	Provider 与传输网络之间双向证书认证 + IP 白名单	未授权客户端混进隧道
内层 TLS（证书企业自持）	加密到企业内网 Proxy 才终止，证书和私钥只在你手里	传输网络（如 Cloudflare）和中间人读取请求/响应载荷
每个 MCP Server 的 OAuth	隧道流量到达服务器后仍需过鉴权	越过隧道鉴权、直接冒用工具

关键点：Provider 只有在你注册了 CA 证书之后才会发起首次连接；而证书私钥始终由企业掌控，所以就算流量从 Cloudflare 网络穿过，它对载荷内容也是”看不见的”。这套设计与零信任的”按需最小暴露”原则天然契合。

怎么快速跑起来？两大阵营的示例

Anthropic 路线（适合 Claude Managed Agents / Messages API），核心三步：控制台建隧道拿 Domain+Token → 用 OpenSSL 生成自持 CA 证书并上传 → 写 docker-compose.yml 一键起：

export TUNNEL_DOMAIN=abcd1234.tunnel.anthropic.com
export TUNNEL_TOKEN='eyJ...'   # 控制台生成，务必保密

# 生成企业自持的 CA 与服务器证书
openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout data/ca.key -out data/ca.crt -days 3650 \
  -subj "/CN=mcp-tunnel-ca" \
  -addext "basicConstraints=critical,CA:TRUE"

# docker compose 内起三个服务：mcp-proxy + cloudflared + 你的 MCP Server
docker compose up -d

OpenAI 路线（Secure MCP Tunnel，已 GA，适合 ChatGPT/Codex/Responses API），用 tunnel-client 命令行：

export CONTROL_PLANE_TUNNEL_ID="tunnel_0123456789abcdef"
export CONTROL_PLANE_API_KEY="sk-..."   # 用 runtime 专用 key，别和 admin key 混用

# 指向一个内网 stdio MCP 服务器
tunnel-client init --sample sample_mcp_stdio_local \
  --profile local-jira --tunnel-id "$CONTROL_PLANE_TUNNEL_ID" \
  --mcp-command "python /opt/mcp-servers/jira-server.py"

tunnel-client doctor --profile local-jira --explain   # 上线前自检
tunnel-client run --profile local-jira                # 启动守护进程

落地前必须避开的 4 个坑

隧道解决了”连接”，不代表解决了”安全”，以下几点是企业落地时最常见的误判：

隧道 ≠ 授权：隧道只管把请求送达，不会替你鉴权。官方文档明确写着”隧道不向 MCP 服务器做认证”——每个上游服务器仍必须配 OAuth/令牌，否则纵深防御少了一层。
密钥角色必须分离：长期运行的守护进程用 runtime key，建隧道/管理操作才用 admin key，两者各留一份、按需轮换。复用高权限密钥会成倍放大泄露的爆炸半径。
把它当运行时基础设施，而不是一次性配置：部署后要接健康检查（/healthz、/readyz、/metrics）、配重启策略、建立证书与密钥的轮换流程，别一锤子买卖。
隧道主机的权限要收敛：tunnel-client 所在主机的网络可达范围，就是 Agent 能摸到的边界。给它配最低权限账号，而不是一把”万能钥匙”。

总结与延伸

要点回顾：

MCP Tunnels = outbound-only 隧道，让云端 Agent 安全调用内网 MCP 服务器，无需开入站端口、无需公网暴露；
架构核心是连接方向反转：内网主动向外拨号，防火墙零改动；
安全性靠三层模型：外层 mTLS + 内层自持证书 + 每服务器 OAuth；
2026 年 5 月 Anthropic、OpenAI 双双入局，模式已行业收敛；
落地关键：隧道只解决连接、不解决鉴权，密钥分离与运行时可观测缺一不可。

延伸阅读： 什么是 MCP 协议？一文读懂 AI 的 USB 接口标准 · 怎么搭建 MCP Server？从零构建 AI 工具的 USB-C 接口 · MCP 协议 2026 版有什么新变化？一文读懂史上最大修订 · 什么是零信任 AI Agent？系统级安全架构全解析