DMBlog onepage/ OpenAI Developers/ Secure MCP Tunnel
Denys Kurylenko · OpenAI Developers · 2026-06-26

Secure MCP Tunnel：OpenAI 怎麼讓私有 MCP 伺服器不用公開上網

這篇 OpenAI Developers 文章談的不是再做一個「把內網打洞」的服務，而是把私有 MCP server 的連線方向整個反過來。客戶在自己環境裡跑一個小型、可檢查的 open-source client，由它主動透過 outbound HTTPS 對 OpenAI 建立通路，讓 ChatGPT、Codex 與其他 OpenAI 產品能正常走 MCP request path，同時不必把私有 server 暴露成公開端點。

Source: OpenAI Developers / 2026-06-26 Blog article Secure MCP Tunnel guide
Source type
OpenAI blog
Main transport
Outbound HTTPS
Initial shape
Long-poll
Adjacent scope
Harpoon REST
Wrong defaults

OpenAI 想解的是：私有工具最有價值，但最不該直接公開

文章先把現有做法講得很直接。若團隊想把內部 MCP server 接到雲端 AI 產品，常見方法只有三種：做公開 endpoint、找第三方 tunnel provider，或把網路邊界擴大到 VPN / peering 等級。問題不在於這三種做法做不到，而是它們都會把「只想接一個工具」這件事，變成更大的安全、採購或網路治理問題。

因此 Secure MCP Tunnel 的設計目標不是提供最大連通性，而是提供最小足夠連通性。換句話說，產品仍然能得到標準 MCP request / response 體驗，但 private address 只在客戶環境內被使用，OpenAI 產品端永遠不需要直接知道或直連那個內部位址。

01 / Public endpoint

最簡單，也最容易弱化邊界

把 server 直接掛上公開 URL 的代價，是原本設計成拒絕 inbound public traffic 的服務，現在反而要接受它。

02 / Third-party tunnel

方便，但多一個要審查的供應商

第三方 tunnel 可以很快打通，但企業團隊得把這家供應商拉進 security review、採購流程、runbook 與 metadata surface。

03 / VPN or peering

可達性太廣，超過 MCP 整合所需

VPN 與 peering 解的是整段網路互通，不是單一工具路徑。對只想接 MCP 的情境來說，通常太重。

Transport

第一版先選 long-poll，不是為了炫技，而是為了可運營

文章最值得注意的一點，是 OpenAI 並沒有先追求最花俏的 transport，而是故意選「operationally boring」的 shape。outbound HTTPS 對企業 firewall、proxy 與平台團隊比較熟；long-poll 也讓 client 只領取自己能處理的工作量，天然形成 backpressure，而不是鼓勵 tunnel 端無限制堆 buffer。

Step 01

產品送出標準 MCP JSON-RPC

ChatGPT、Codex 或其他 OpenAI 產品仍然用一般 MCP request / response 心智模型，不需要為私有 server 改寫整個 tool calling 方式。

Step 02

OpenAI hosted endpoint 代管 tunnel request path

產品對接的是 OpenAI 端的 tunnel endpoint，而不是客戶內部的 private address。這保留了產品端體驗，也把私有位址留在客戶邊界內。

Step 03

customer-run client 主動領取工作

真正去碰本地 MCP server 的，是客戶環境內的 tunnel client。它已經待在私有網路內，因此可以安全地把請求轉給核准目的地。

Step 04

同一路徑回送 final response 與 intermediate events

文章強調 tunnel 不只回 final response，也能轉送 server-sent events。這代表 MCP 的 streaming 與 notification flow 不是事後補丁，而是一開始就被納入 transport 設計。

這裡的關鍵不是「可以連」，而是「連線方向」

Secure MCP Tunnel 把 reachability inside out：不是 OpenAI 打進來，而是私有端先出去。這讓 private server 仍留在既有 network control 後面，不必接受 inbound public traffic，也不必擴大成更寬的網路互信。

Boundary

真正難的不是 tunnel 本身，而是把安全邊界講清楚

OpenAI 在文章裡一直重複一件事：這不是一般意義上的 network bridge。tunnel client 需要可檢查、行為刻意收窄，而且只允許明確設定的目的地。客戶能知道它打開了哪一條 outbound path、會轉發哪些請求、以及它到底能碰哪些 private service。

open-source client 是信任模型的一部分 client 跑在客戶邊界內，因此它必須是小型、可審查、customer-run 的軟體。這樣 security reviewer 才能確認它到底做了什麼，而不是把核心風險包在黑盒裡。
OAuth 可以走 tunnel path，但 private server 仍保持私有 文章提到 OAuth discovery 可以透過 tunnel path 讓 hosted product 知道怎麼驗證，而不用要求 MCP server 自己對公網開口。另一方面，若 authorization server 本身也是私有的，執行 OAuth flow 的那一端仍必須能到達它。
企業網路前提被當成產品需求，而不是例外 custom CA bundles、proxy settings 與 MCP hop 上的 mTLS 都被納入設計。這表示 OpenAI 把企業實際網路條件視為第一級需求，而不是叫客戶先把環境改成比較像公網。
Harpoon 把同一模型延伸到核准 REST target 有些重要內部流程根本還沒包成 MCP server。Harpoon 讓客戶在 tunnel client 上註冊 label 化的 REST target，OpenAI 端只能呼叫核准標籤、受方法、timeout、redirect 與回應大小限制約束，不會變成任意 URL 代理。
Practical read

這篇文章對團隊的實際含義：把「接內網工具」視為產品與治理問題

如果只看表面，這像是一篇技術公告；但對導入 agent tooling 的團隊來說，它其實是在重新定義 private tool integration 的預設做法。重點不是 tunnel 技術名詞，而是你能不能在不改變 private service 邊界的情況下，把內部工具帶進 hosted AI workflow。

先問最小足夠連通性是什麼若需求只是讓模型叫一組內部工具，不要直接跳到 VPN、peering 或公開入口；先看是否能用更窄的 request path 達成。
把 streaming、auth、ops 一起納入設計MCP integration 真正卡住的常常不是單次 request，而是串流、notification、OAuth、proxy、憑證與可觀測性。這篇文章的價值是把它們當成同一個系統來談。
審查 client，而不是只審查 endpoint當連線方向改成私有端主動出去，新的風險中心會落在 client 行為、目標允許清單與 tunnel identity。治理焦點也應跟著移動。
MCP 不是唯一目標格式Harpoon 這段透露得很明白：企業內部很多高價值能力還是舊 REST API。若平台只支援「已經是 MCP」的東西，導入成本會高很多。
Source

主要來源

本文依據 OpenAI Developers 文章與公開資源整理，保留 Secure MCP Tunnel、Harpoon、long-poll、OAuth 與 open-source tunnel client 的原始脈絡，再改寫成給產品、平台與安全團隊快速理解的一頁摘要。

Making private MCP servers reachable without making them public https://developers.openai.com/blog/connect-private-mcp-servers-to-openai-products Secure MCP Tunnel guide https://developers.openai.com/docs/guides/secure-mcp-tunnel tunnel-client on GitHub https://github.com/openai/tunnel-client