MCP 已经成了 Agent 连接外部工具和数据的一种常见方式。对个人开发者来说MCP Server 可能只是本地跑起来的一个小服务但到了企业环境里真正有用的 MCP Server 往往都在更封闭的位置企业内网、私有 service mesh、开发者本机、Kubernetes 集群、VM或者只能被内部系统访问的业务环境里。这时问题就变得很具体怎么让 AI Agent 调用这些MCPServer同时又不把内部服务暴露到**公网**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 返回。图 1OpenAI 产品把 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。图 2MCP 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 接入 OpenAIOAuth 登录、授权或 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 APIOpenAI 原文最后还提到一个扩展能力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 系统来说连接只是第一步。更重要的是这条连接要足够窄、足够明确、足够可检查并且能够被企业现有的权限和运维体系接住。