OpenAI Secure MCP Tunnel：企业私有系统接入 AI Agent 的安全通道
OpenAI 将 Secure MCP Tunnel 推到开发者文档与开源客户端中，给企业把私有 MCP 服务接入 ChatGPT、Codex、Responses API 和 AgentKit 提供了一个不暴露内网服务的路径。
背景：MCP 正从插件能力变成企业连接层
过去几个月，MCP 已经成为 AI Agent 连接工具、数据源和企业系统的重要协议。但现实落地时，很多 MCP 服务部署在内网、开发机、私有云或受访问控制保护的环境里，直接暴露公网端点通常无法通过安全评审。
OpenAI 的 Secure MCP Tunnel 给出了一个更接近企业网络习惯的方案：在能访问私有 MCP 服务的网络内部运行 tunnel-client，由客户端主动连到 OpenAI 托管的隧道端点，再把来自 ChatGPT、Codex、Responses API 或 AgentKit 的 MCP 请求转发到本地服务。
核心变化：不开放入站端口，也能调用私有 MCP
这次值得关注的不是“又多了一个连接器”，而是连接方式的变化。Secure MCP Tunnel 采用出站 HTTPS 路径，企业无需给 MCP 服务新增公网域名或入站防火墙规则；OpenAI 侧看到的是托管隧道端点，真正持有内部凭据和访问权限的仍是企业网络中的 MCP 服务和隧道客户端。
开源的 openai/tunnel-client 仓库还提到健康检查、就绪检查、指标和本地 UI 等运维能力，这意味着它面向的不是一次性演示，而是希望进入团队可观测、可排障的生产链路。
影响：企业 Agent 落地的阻力会变小
对企业来说，Agent 真正有价值的地方往往在私有数据、内部工单、代码仓库、财务系统和知识库。Secure MCP Tunnel 降低了“为了让 AI 能调用工具而把内部服务暴露出去”的阻力，也让安全团队能把审批重点放在隧道身份、权限边界、日志审计和本地 MCP 服务治理上。
这也会推动 MCP 服务从个人开发者的本地脚本，逐步变成企业内部可管理的能力目录。谁能调用、调用了什么、失败如何回滚，将成为后续 AI 平台团队需要补齐的治理问题。
适合哪些人关注
企业 AI 平台团队、内部工具平台负责人、DevOps/SRE、安全架构师、正在用 Codex 或 ChatGPT Enterprise 连接私有系统的团队，都值得跟进。对普通用户来说，这不是一个直接提升聊天体验的功能；但对企业部署 AI Agent 来说，它解决的是“能不能安全接上真实系统”的关键一步。
风险与观察点
隧道并不等于权限治理本身。企业仍需要明确 MCP 服务可访问的数据范围、工具调用审批、日志留存、异常请求阻断和密钥轮换机制。近期 OpenAI 社区也出现过工作区与组织关联失败的反馈，说明大规模推广时，管理台、组织映射和支持流程仍需要继续成熟。
