OpenAI 推出安全 MCP 隧道：讓 ChatGPT 接進企業內網

OpenAI 正式推出 Secure MCP Tunnel，讓企業的私有 MCP 伺服器得以接通 ChatGPT、Responses API 等 OpenAI 產品，且全程不需對外開放任何防火牆連線埠。
（前情提要：串聯萬物的 MCP 加上 Web3，能成下一波 AI 百倍敘事嗎？）
（背景補充：Cloudflare 推出 Mesh 取代 VPN：讓 AI 代理安全存取你的內網、免費提供 50 節點）

企業匯入 AI 最大的恐懼之一是「要讓 AI 用得到內部系統，就得先把系統暴露到外網」。OpenAI 的新功能，填補了這個痛點。

OpenAI 在最新官方開發者檔案中說明了 Secure MCP Tunnel 的運作方式：企業的私有 MCP 伺服器可以接通 ChatGPT、Codex、Responses API 與 AgentKit，卻完全不需要對外開放任何 inbound 連線埠。

簡單來說就是，AI 能讀你家的資料，但你家的門從來沒開啟過。OpenAI 共同創辦人 Greg Brockman 將這功能定義為「bring-your-own MCP servers（自帶 MCP 伺服器）」。

一條只出不進的隧道

MCP（Model Context Protocol），是讓 AI 呼叫外部工具與資料的標準協定。白話說就是 AI 的「萬用插座」，透過 MCP，模型才能從外部資料庫撈資料、觸發企業內部工具、執行跨系統操作。

但問題出在這裡：傳統架構要讓外部服務連進企業內網，就得開 inbound port（對外開放的連線埠），意思是在防火牆上打洞。這是資安單位最不願意做的事。

舉一個具體的場景：一家銀行想讓 ChatGPT 能夠查詢內部客戶帳戶資料庫，讓行員直接用自然語言問「這位客戶過去六個月的轉帳紀錄」，AI 即時回答。或者一家醫院希望讓 Codex 讀取病歷系統，協助醫師快速整理患者用藥史。

問題是，這些資料不能上公網，銀行受金管法規約束，醫院受個資法保護。過去只有兩條路可走：要嘛把內部資料庫開放到外網讓 AI 直接連（資安部門直接否決），要嘛自建一整套笨重的中間層來搬運資料（開發成本高，維護更麻煩）。OpenAI 的 MCP 隧道給了第三條路：AI 能進來取資料，但內網不對外開門。

這條路之所以能通過企業資安審查，關鍵在於它的架構符合零信任原則（zero-trust）。簡單來說就是，預設誰都不信任、每個連線都必須驗證身份才能通話。對金融與醫療這類受嚴格監管的產業而言，「防火牆不開洞」不只是方便，而是合規的前提條件，許多資安政策明確禁止對外開放 inbound 連線埠，任何繞過這條規定的架構都無法透過 IT 審計。

OpenAI 的解法是一支叫 tunnel-client 的工具，部署在企業內網中、能直接連到私有 MCP 伺服器的位置。它只做一件事：對 OpenAI 建立一條 outbound-only（只從內部主動往外連、不對外開門）的 HTTPS 通道，再透過 long-poll（主動輪詢，簡單來說就是定期去問「有沒有新任務」）持續拉取排隊中的 MCP 工作請求，在本地轉發給私有伺服器，最後把回應從同一條隧道送回 OpenAI。

整個過程，私有 MCP 伺服器的位址未離開企業內網邊界。就算要串流中途結果，隧道也能轉發 server-sent events（伺服器推送事件）。安全模型採 outbound-only 架構，搭配 runtime API key 認證，並支援 mTLS（雙向憑證驗證，雙方都要出示身份才能通話），可走 mtls.api.openai.com 的 control-plane 通道，MCP 端本身也能加上 mTLS。企業環境需要的 outbound proxy、自訂 CA bundle、客戶端憑證，全部支援。

開發者只需要從 Platform 隧道設定取得 tunnel_id，搭配具備對應權限的 runtime API key，再用開源的 tunnel-client 工具，就能透過 stdio 或 HTTP 把任何私有 MCP 伺服器接進 OpenAI 的產品生態。