Secure MCP Tunnel 教程：让 ChatGPT 安全调用公司内网 MCP 服务

公司里想接 AI 工具，最卡人的地方往往不是模型能力。

而是安全部门一句话：

这个内部系统，不能暴露到公网。

这句话一出，很多 MCP 方案直接卡死。

MCP 本来是让大模型调用工具的协议。比如查 CRM、读工单、拉库存、跑内部脚本。问题来了：这些工具大多在公司内网里，ChatGPT 在外面，怎么连？

OpenAI 推出的 Secure MCP Tunnel（安全 MCP 隧道），就是专门补这个坑的。

它的思路很直接：

不让外部进内网，改成内网主动连出去。

这招看起来简单，但对企业接入 AI 很关键。因为它绕开了“开放公网入口”这件让安全团队头大的事。

一句话讲懂 Secure MCP Tunnel

Secure MCP Tunnel 可以让 ChatGPT 和 Codex 调用公司内网里的 MCP 服务器，同时尽量避免把内部服务暴露到公网。

你可以把它理解成：

公司内网里放一个小客户端，它主动和 OpenAI 建立加密连接。ChatGPT 要调用内网工具时，请求通过这条加密通道转进去，再把结果带回来。

是不是有点像 ngrok、Cloudflare Tunnel？

对，技术味道很像。

区别是，OpenAI 把它做进了自己的企业体系里，可以跟组织、workspace、权限、工具调用策略这些东西绑在一起。

这才是它真正有价值的地方。

它解决的到底是什么问题？

咱们拿一个真实场景说。

你在一家电商公司，内部有几个系统：

订单查询系统
售后工单系统
仓库库存系统
用户画像系统
内部知识库

客服团队想用 ChatGPT 辅助处理问题。

比如客服问：

帮我查一下用户 138xxxx 的订单状态，顺便看有没有未处理售后单。

如果 MCP 接好了，ChatGPT 可以自动调用订单 MCP、售后 MCP，把结果汇总成一段人话。

听着很爽，对吧？

安全团队马上会问：

订单系统要不要开放公网？
谁能调用这些工具？
请求内容会不会泄露？
返回的数据怎么管？
离职员工还能不能用？

没有 Secure MCP Tunnel 时，你可能要自己搞公网代理、VPN、网关、鉴权、审计。一套下来，人还没用上，项目已经开了三轮会。

Secure MCP Tunnel 的意义就在这：

给企业内网 MCP 提供一条更官方、更可控的接入路径。

工作原理：别让外面进来，让里面主动出去

传统接法通常是这样：

ChatGPT 想调用你的 MCP 服务器，你得让 MCP 服务器能被外部访问。

这很麻烦。

因为公司内网服务一旦开公网入口，就会带来一堆安全问题。

Secure MCP Tunnel 换了个方向：

内网主动发起连接，外部不需要直接打进来。

流程大概是这样：

ChatGPT / Codex
      ↓
OpenAI 隧道入口
      ↓ 加密通道
公司内网 tunnel-client
      ↓
内部 MCP 服务器

真正跑起来时，关键角色有三个：

ChatGPT / Codex：发起工具调用的一方
OpenAI 隧道入口：负责接收请求并转发
tunnel-client：装在公司内网的小程序，负责连接 OpenAI 和本地 MCP 服务

跑通流程：一次请求是怎么走的？

你可以按下面这个过程理解。

1. 在公司内网安装 tunnel-client

你需要在公司内网里放一个叫 tunnel-client 的小程序。

它能访问你的内部 MCP 服务器。

比如你的 MCP 服务跑在：

http://mcp-internal.company.local:8080

tunnel-client 不需要暴露到公网。

它只要能连到内部 MCP 服务，并且能访问 OpenAI 的 HTTPS 地址即可。

2. tunnel-client 主动连到 OpenAI

重点来了。

不是 OpenAI 从外面打进你的内网。

而是 tunnel-client 主动向 OpenAI 建立一条加密通道。

它走的是普通 HTTPS 出站流量。

这对企业网络很友好。很多公司默认禁止公网入站，但允许受控的 HTTPS 出站。

这也是反向隧道方案常见的优势。

3. ChatGPT 发起 MCP 工具调用

当用户在 ChatGPT 里提出一个需要内部工具处理的问题，比如：

查一下客户 A 最近 30 天的退款记录。

ChatGPT 判断需要调用某个 MCP 工具。

请求会先到 OpenAI 这一侧的隧道入口。

它不会直接访问你的内网地址。

4. 请求通过隧道转给内网客户端

OpenAI 隧道入口收到请求后，会把请求通过那条已建立的加密通道送到 tunnel-client。

tunnel-client 一直在线等活儿。

收到请求后，它会把请求转发给本地 MCP 服务器。

5. MCP 服务器处理请求并返回结果

内部 MCP 服务器收到请求后，正常处理。

比如查数据库、调内部 API、读取业务系统。

处理完后，结果会返回给 tunnel-client。

6. 结果沿原路返回 ChatGPT

tunnel-client 再通过加密通道把结果送回 OpenAI。

ChatGPT 拿到结果后，组织成用户能看懂的回答。

整个过程里，内网 MCP 服务不用开公网入口。

这就是核心价值。

适合哪些场景？

Secure MCP Tunnel 特别适合下面这些情况。

内部系统不允许公网暴露

比如财务、法务、人事、CRM、ERP、工单系统。

这些系统动不动就涉及客户数据、合同、员工信息。

直接开公网？安全团队大概率当场摇头。

用隧道方式，内网服务可以继续待在内网里。

想让 Codex 调用内部研发工具

研发团队也很需要这个。

比如让 Codex 访问：

内部代码搜索服务
构建系统
测试报告平台
私有文档库
缺陷管理系统

想象一下，你让 Codex 查某个接口最近失败的测试，再结合代码改动给排查建议。

这比单纯让它看本地代码强多了。

企业已经在做 MCP 工具化

很多企业已经写了一批 MCP Server。

尴尬的是，工具写好了，接到 ChatGPT 这一步卡住了。

Secure MCP Tunnel 就是把“能调用工具”和“能安全调用内网工具”之间那段路补上。

和 ngrok、Cloudflare Tunnel 有什么区别？

从技术味道看，大家都属于反向隧道。

大概都是：

内网客户端主动连出去 → 云端入口接请求 → 请求转回内网服务

区别在集成层面。

ngrok、Cloudflare Tunnel 更像通用隧道工具。

Secure MCP Tunnel 更贴近 OpenAI 的 MCP 调用场景。

它的优势可能会体现在：

和 ChatGPT / Codex 的工具调用链路更顺
可以接入 OpenAI 组织和 workspace 权限
更方便做企业级访问控制
更适合 MCP Server 的注册、调用和治理
减少自己拼网关、鉴权、审计的工作量

一句话：

通用隧道解决“怎么连进去”，Secure MCP Tunnel 更偏向解决“怎么让 OpenAI 安全地调企业 MCP”。

你可以怎么落地？

如果你是企业里的技术负责人，可以按这个路线推进。

梳理要接入的 MCP 服务

先别急着全接。

挑一个低风险、高价值的场景试点。

比如：

查询内部知识库
查询工单状态
查询非敏感库存信息
查询测试报告

别一上来就接薪资系统、合同系统、客户隐私库。

那不是试点，那是给自己找会开。

明确调用权限

谁能用这个 MCP？

客服能不能查订单？

销售能不能查客户画像？

研发能不能查线上日志？

这些权限要提前定好。

建议按 workspace、团队、角色来划分。

别搞成“大家都能调所有工具”。

这在企业里很危险。

控制返回数据

MCP Server 返回给模型的数据要克制。

不要一股脑把整张表、整份合同、完整用户档案丢出去。

更好的做法是：

只返回完成任务需要的字段
对敏感字段做脱敏
对大结果做分页或摘要
对高风险操作加人工确认

比如查订单时，返回订单状态、物流节点、售后状态就够了。

身份证号、完整地址、支付流水没必要出现。

做好审计日志

企业场景里，审计很重要。

建议记录：

谁发起了调用
调用了哪个 MCP 工具
请求参数是什么
返回了哪些关键数据
调用时间和结果状态

出了问题能追踪，合规检查也有材料。

不要等出事了再补日志。

那时候补不回来。

示例：客服查询订单的调用链路

假设你有一个内部 MCP 工具：get_order_status。

它能根据订单号查询订单状态。

用户在 ChatGPT 里问：

帮我查一下订单 202501010888 现在到哪了，客户催得很急。

调用链路会变成：

ChatGPT 判断需要查订单
        ↓
调用 get_order_status
        ↓
请求进入 OpenAI Secure MCP Tunnel
        ↓
通过加密通道到内网 tunnel-client
        ↓
tunnel-client 转发给内部订单 MCP Server
        ↓
订单系统返回物流状态
        ↓
结果回到 ChatGPT
        ↓
ChatGPT 生成客服可直接复制的回复

最后客服可能拿到这样的回答：

订单 202501010888 已从华东仓发出，目前到达杭州转运中心，预计今天 18:00 前完成派送。建议回复客户：您的订单已经到达本地转运中心，预计今天送达，我们会继续帮您关注物流状态。

这才是 AI 工具真正进入工作流的样子。

不是炫技，是能直接省时间。

避坑清单：别把安全隧道用成安全事故

Secure MCP Tunnel 解决的是连接问题，不代表你可以放飞自我。

下面这些坑要避开。

❌ 别把所有 MCP 一口气全接上

先接低风险工具。

跑通流程、权限、审计，再逐步扩展。

❌ 别让 MCP Server 返回过多数据

模型只需要完成任务所需的信息。

别把数据库查询结果整页塞回来。

返回越多，风险越高。

❌ 别忽略用户权限

同一个工具，不同角色看到的数据也该不同。

客服查订单，可能只能看物流和售后。

财务查订单，才需要看支付和发票。

❌ 别忘了人工确认

查询类工具风险相对低。

写入类工具要谨慎。

比如：

修改订单地址
关闭工单
发放优惠券
删除数据
执行部署

这些动作最好加确认步骤。

AI 可以建议，人来拍板。

❌ 别把 tunnel-client 当成普通脚本随便放

tunnel-client 很关键。

它连接着 OpenAI 和公司内网 MCP。

建议放在受控环境里运行，并配合：

最小权限账号
固定网络出口
日志监控
进程守护
凭证轮换

别丢在某台没人管的测试机上。

三个月后谁也不知道它还在跑什么。

对企业意味着什么？

Secure MCP Tunnel 补的是企业级 MCP 的“最后一段路”。

MCP 解决了大模型怎么调用工具。

Secure MCP Tunnel 解决了公司内部工具怎么被安全调用。

这两件事合起来，ChatGPT 和 Codex 才能真正进入企业内部工作流。

不是只帮你写几段文案。

而是能查系统、读数据、跑流程、辅助决策。

当然，前提是权限、审计、脱敏、确认机制都得跟上。

工具越强，边界越要清楚。

建议的试点路线

如果你准备在公司里试，建议这样来：

选一个低风险 MCP，比如知识库查询
在内网部署 tunnel-client
连接内部 MCP Server
配好 workspace 和用户权限
限制 MCP 返回字段
记录调用日志
小范围让真实用户试用
根据反馈再接入订单、工单、研发工具

别追求一天接完所有系统。

企业 AI 落地，最怕“一把梭”。

小步快跑，边用边收口，才稳。

结语

Secure MCP Tunnel 的价值不在“隧道”两个字。

真正重要的是，它让企业内部系统有机会安全地接入 ChatGPT 和 Codex。

以前大家卡在这句话上：

内网工具不能暴露，AI 又调不到。

现在有了更顺的解法：

内网主动连出去，请求加密转回来，权限和 workspace 一起管。

对准备做企业 AI 工具化的团队来说，这个功能值得重点关注。尤其是你已经在写 MCP Server，或者正准备把内部系统接进 ChatGPT，这条路会少踩很多坑。