MCP 已经成了 Agent 连接外部工具和数据的一种常见方式。
对个人开发者来说，MCP Server 可能只是本地跑起来的一个小服务；但到了企业环境里，真正有用的 MCP Server 往往都在更封闭的位置：企业内网、私有 service mesh、开发者本机、Kubernetes 集群、VM，或者只能被内部系统访问的业务环境里。
这时，问题就变得很具体：怎么让 AI Agent 调用这些 MCP Server，同时又不把内部服务暴露到**公网**？
OpenAI 最近发布的 Secure MCP Tunnel，解决的就是这个问题。它的目标很具体：让 ChatGPT、Codex、Responses API 等 OpenAI 产品，可以调用私有 MCP Server；同时，MCP Server 继续留在客户原有的网络边界内，不需要开放公网入口。
私有 MCP Server 的接入难题
在没有专门方案时，要让外部 AI 产品访问一个私有服务，通常有几种做法。
一种是直接开放公网 endpoint。这样接入最简单，但也意味着原本只在内网里的服务，需要面向公网接受请求。对企业来说，这通常会引入额外的安全审查、认证设计、日志审计和运维压力。
另一种是使用第三方 tunnel 工具。它能快速把本地或内网服务暴露出去，但也会在连接链路里引入新的供应商。安全团队需要审查这个 tunnel 工具本身，运维团队也要把它纳入监控、故障排查和权限管理。
还有一种是 VPN 或网络 peering。它比较像是传统企业网络方案，但对 MCP 这种相对窄的工具调用场景来说，成本显得过重。为了让 Agent 调用几个工具，扩展一整条网络通路，容易把一个集成问题变成网络工程问题。
Secure MCP Tunnel 的基本思路
Secure MCP Tunnel 的核心做法，是把连接方向反过来。
传统思路是让外部产品主动访问内部服务；Secure MCP Tunnel 则让客户自己的环境先主动连出去。
具体来说，客户在能访问私有 MCP Server 的环境里运行一个 tunnel-client。这个 client 会通过 outbound HTTPS 连接 OpenAI。之后，OpenAI 产品发出的 MCP 请求会先到 OpenAI 托管的 tunnel endpoint，再由客户侧的 tunnel-client 通过 long-polling 拉取请求，转发给本地或内网 MCP Server，最后把响应沿同一条 tunnel 返回。
图 1：OpenAI 产品把 MCP 请求发到 OpenAI-hosted tunnel endpoint；客户侧 tunnel-client 主动拉取任务，转发给私有 MCP Server，再把响应返回。
在这个链路中，私有 MCP Server 不需要开放公网监听，也不需要新增入站防火墙规则。客户只需要保证 tunnel-client 能在内部网络里访问到 MCP Server，后续请求就可以通过 tunnel 路径完成转发。这样一来，OpenAI 产品就获得了一条标准 MCP 请求路径，而客户环境里的 MCP Server 仍然留在原来的私有网络里。
outbound-only 的好处
Secure MCP Tunnel 最关键的设计点，是 outbound-only。
Tunnel-client 运行在客户自己的网络里，主动通过 HTTPS 连接 OpenAI。企业防火墙、代理和平台团队会更熟悉这种出站连接模型。相比开放公网入口，这种方式更容易进入已有的网络审批和运维体系。
OpenAI 原文还提到，它们一开始选择了 long-polling 这种相对朴素的传输方式。原因也很工程化：outbound HTTPS 容易被企业网络接受；long-polling 可以让 client 按照自身处理能力拉取任务，天然形成一个背压点，避免请求无限堆积。对于需要流式结果的场景，tunnel 路径也可以转发中间的 server-sent events。
私有侧先连出去，OpenAI 产品通过 tunnel endpoint 排队，客户侧 client 再把任务取回来执行。
这个模型对企业内部安全团队会更友好。它让“谁在连接谁”“连接从哪里发起”“请求最终落到哪里”的链路变得清晰。
安全边界没有消失
Secure MCP Tunnel 容易被误解成一种“内网穿透”。从 OpenAI 的设计描述看，它其实是一条受控的 MCP 调用路径。
它没有把客户网络整体接给 OpenAI，也没有让 OpenAI 获得一个类似 VPN 的身份。被转发的只是配置过的 MCP 请求。私有 MCP Server 的地址只在客户环境内部使用，OpenAI 产品访问的是 OpenAI-hosted tunnel endpoint。
图 2：MCP Server 仍然留在客户环境中；tunnel-client 通过出站 HTTPS 连接 OpenAI，客户环境不需要为 MCP Server 开放公网入口。
这里我们可以把安全边界拆成三部分：
第一层是网络边界。MCP Server 仍然在客户环境里，访问它的是同一环境中的
tunnel-client。外部产品不会直接拿到私有 MCP Server 的地址。第二层是运行边界。
Tunnel-client是客户自己运行的组件，部署在客户控制的环境里。OpenAI 原文强调，它是开源、客户运行、可检查的 client。安全团队可以看它打开了什么出站连接、怎么转发请求、允许访问哪些本地服务。第三层是权限边界。OpenAI 文档里把 tunnel 权限和 ChatGPT developer mode 权限分开。创建或编辑 tunnel 需要 Tunnels Read + Manage；运行
tunnel-client或在 connector 设置里选择 tunnel，则需要 Tunnels Read + Use。Tunnel 还可以关联到一个或多个 Platform organization 或 ChatGPT workspace，用来控制哪些 OpenAI 上下文能够发现和使用它。
也就是说，Secure MCP Tunnel 处理的不只是网络连接问题，也把组织、工作区、权限和配置关系放进了接入模型里。
从本地开发到生产环境
这套方案还有一个比较实用之处，本地开发和生产部署使用了同一种心智模型。
用户可以先在自己的电脑上跑一个 MCP Server，再启动 tunnel-client，把它接到 ChatGPT 或 Codex 测试。后续要迁移 MCP Server 到 Kubernetes、VM 或私有网络的话，整体运行模式类似——把 tunnel-client 放在能访问 MCP Server 的地方，让它主动连到 OpenAI。
图 3：无论 MCP Server 在本机、Kubernetes 还是 VM / 私有网络中，核心模式都是让 tunnel-client 靠近私有 MCP Server，再通过 outbound path 接入 OpenAI 产品。
这个设计很有用，因为我们接入不少企业工具时，早期验证一般会卡在网络配置上：本地能跑，ChatGPT 或 Codex 调不到；内网能访问，公网产品进不来；测试环境能通，生产环境又要重新改一套配置。
Secure MCP Tunnel 把这个过程收敛成了一个稳定的流程：先运行 MCP Server，再启动 tunnel-client，确认 client 能访问本地或内网中的 MCP Server，最后让 OpenAI 产品通过 tunnel endpoint 发起调用。
OpenAI 文档里也提到，可以通过 health check、readiness、metrics 和本地 admin UI，确认 tunnel-client 是否正常运行、是否连上 OpenAI，以及是否能访问本地或内网中的 MCP Server。
部署到生产环境时，tunnel-client 也有几种常见运行方式。如果 MCP Server 已经运行在 Kubernetes 里，可以把 tunnel-client 放在同一个 Pod 中，作为 sidecar 辅助容器运行，让它就近访问 MCP Server。也可以把 tunnel-client 作为独立的 Kubernetes Deployment 单独运行，再通过集群网络或内网地址访问 MCP Server。对于 VM 环境，也可以把它配置成 systemd service，作为一个常驻后台服务运行。
企业认证和 OAuth 边界
企业里的 MCP Server 很少只是一个匿名 HTTP 服务。它可能依赖 OAuth、私有 CA、出站代理、客户端证书，或者 MCP 侧的 mTLS。
Secure MCP Tunnel 把这些企业网络条件也纳入了设计。Tunnel-client 可以在客户环境里配置 custom CA bundle、proxy settings、control-plane client certificates，以及 MCP-side mTLS。
在 OAuth 这部分，还需要注意一个边界。OpenAI 文档提到，MCP Server 的 OAuth discovery 可以通过 tunnel 路径完成，因此 MCP Server 本身仍然可以留在私有网络里。但授权服务器不会自动跟着这条 tunnel 暴露出去。也就是说，如果负责执行 OAuth 流程的组件无法访问授权服务器，即使 MCP Server 已经通过 tunnel 接入 OpenAI，OAuth 登录、授权或 token 获取流程仍然可能失败。
因此，Secure MCP Tunnel 解决的是 MCP Server 的私有接入问题，并不会自动打通它背后的所有企业系统。它只为配置过的私有 MCP Server 提供一条受控访问路径。至于认证服务、授权页面、企业身份系统能不能被执行 OAuth 流程的组件访问，还需要企业在自己的网络和身份体系里单独处理。
日志和审计边界
日志边界也是企业接入时容易忽略的一部分。
Secure MCP Tunnel 会把 tunnel 传输日志和应用层产品日志分开处理。tunnel metadata 的变化会进入 API Platform 的审计日志，包括 tunnel.created、tunnel.updated、tunnel.deleted 这类事件；但 tunnel 传输路径本身，并不等同于 ChatGPT Compliance Platform 里的应用事件日志。
因此，企业在设计 MCP Server 接入时，不能只确认这条链路是否能连通，还需要把审计范围一起纳入设计。要考虑 Agent 实际调用了哪个 MCP 工具，调用发生在哪个 workspace 或 organization 下，应用层是否记录了 invocation log，认证流程是否留下 app auth log，以及 tunnel 的创建、修改和删除是否进入平台审计。
当 MCP Server 接给 Agent 以后，企业真正需要管理的是一整条调用链：从模型侧、产品侧，到 tunnel 侧、客户环境侧，再到 MCP Server 自己的权限、日志和审计记录。
Harpoon：把思路扩展到 REST API
OpenAI 原文最后还提到一个扩展能力：Harpoon。
并不是所有企业内部能力都被封装成 MCP Server。很多私有工作流仍然以 REST API 的形式存在，而且这些 API 往往部署在防火墙后，只允许内部系统访问。Harpoon 解决的就是这类场景：它作为 tunnel-client 里的一个嵌入式 MCP Server，可以把少量经过配置的私有 REST endpoint，按 label 暴露给支持的 agent 或 API flow。
不过，Harpoon 的重点依然是访问可控。
调用方不能随意指定 host，也不能把 Harpoon 当成一个通用代理来使用。每个请求都会受到客户配置的约束，包括 target label、允许的 HTTP 方法、响应大小、超时时间、重定向行为，以及对应的 tunnel 权限。
因此，Harpoon 可以看作 Secure MCP Tunnel 思路的一种延伸。当企业内部能力还没有 MCP 化时，它也能为少量私有 REST API 提供一条更窄、更明确、也更容易审计的访问路径。
Agent 安全接入私有工具
MCP 让 Agent 更容易地连接工具和数据，但进入企业场景后，真正需要处理的已经不只是协议接入。
企业还需要明确：哪些工具可以被 Agent 调用，调用请求从哪里来，内部服务是否需要暴露公网，谁有权限创建和使用这条连接，以及 OAuth、证书、代理、mTLS、日志和审计应该如何处理。
Secure MCP Tunnel 给出的思路，是让客户环境里的 tunnel-client 主动连接 OpenAI，把私有 MCP Server 留在原有网络边界内，再通过组织、工作区、tunnel 权限和本地配置来收紧访问范围。
对于生产环境里的 Agent 系统来说，连接只是第一步。更重要的是，这条连接要足够窄、足够明确、足够可检查，并且能够被企业现有的权限和运维体系接住。
