OpenAI正式推出Secure MCP Tunnel，让企业的私有MCP服务器得以连接ChatGPT、Responses API等产品，且全程无需对外开放任何防火墙端口。这一功能直接戳中企业导入AI的最大痛点：既要让AI访问内部系统，又不能让系统暴露在外网。
MCP隧道：AI能读内网数据，但门没开
MCP（Model Context Protocol）是AI调用外部工具和数据的标准协议，相当于AI的“万能插座”。通过MCP，模型才能从外部数据库拉取数据、触发企业内部工具、执行跨系统操作。但传统架构下，要让外部服务连进企业内网，必须开放inbound端口——在防火墙上打洞，这是安全团队最忌讳的事。
举个具体场景：一家银行想让ChatGPT查询内部客户账户数据库，行员直接问“这位客户过去六个月的转账记录”，AI即时回答。或者���家医院希望让Codex读取病历系统，帮助医生快速整理患者用药史。问题在于，这些数据不能上公网：银行受金融法规约束，医院受个资法保护。过去只有两条路：要么开放内网让AI直连（安全部门直接否决），要么自建一套笨重的中间层搬运数据（开发成本高，维护更麻烦）。OpenAI的MCP隧道给出了第三条路：AI能进来取数据，但内网不对外开门。
这条路能通过企业安全审查，关键在于架构符合零信任原则（zero-trust）。默认谁也不信任，每个连接都必须验证身份才能通信。对金融和医疗这类严格监管的行业，“防火墙不开洞”不只是方便，更是合规的前提条件。
技术细节：outbound-only隧道与双向认证
OpenAI的方案是一支叫tunnel-client的工具，部署在企业内网、能直接连到私有MCP服务器的位置。它只做一件事：对OpenAI建立一条outbound-only（只从内部主动往外连、不对内开放）的HTTPS通道，再通过long-poll（主动轮询，定期询问“有没有新任务”）持续拉取排队中的MCP工作请求，在本地转发给私有服务器，最后把响应从同一隧道送回OpenAI。
整个过程，私有MCP服务器的地址始终未离开企业内网边界。即使要串流中途结果，隧道也能转发server-sent events。安全模型采用outer-only架构，搭配runtime API key认证，并支持mTLS（双向证书验证，双方都要出示身份才能通信）。企业环境所需的outbound proxy、自定义CA bundle、客户端证书，全部支持。
开发者只需从Platform隧道设置获取tunnel_id，搭配对应权限的runtime API key，再用开源的tunnel-client工具，就能通过stdio或HTTP把任何私有MCP服务器接入OpenAI的产品生态。
Anthropic和Cloudflare押注同一战场
Anthropic之前也推出了自己的MCP tunnels，并附带self-hosted sandboxes（自建沙盒，让AI agent在企业自己控制的环境里执行），主打锁定AI agent基础设施的安全层。更早之前，Cloudflare推出Mesh，目的也是取代VPN、让AI代理安全访问企业内网。从基础设施厂商到模型厂商，整个行业都在解决同一道题：“怎么让AI安全接入企业的核心系统。”
这道题的商业逻辑很直接。企业客户不会把AI当搜索引擎用，他们需要的是能读内部CRM、能查私有数据库、能触发审批流程的AI。但一旦要接入内网，安全就成了第一个否决者。谁能说服安全主管点头，谁就能拿下企业合同。MCP隧道解决的，正是安全主管手里的那张否决票。