我們打造安全 MCP 通道，是因為團隊最重視的 MCP 伺服器，往往也是他們最不希望暴露在網際網路上的伺服器。
我們想分享如何因應這項限制：讓私有伺服器維持私有，同時為 ChatGPT、Codex 和其他 OpenAI 產品提供正常的 MCP 請求路徑。
Model Context Protocol 讓 AI 系統更容易連接外部工具與資料。然而，許多最有價值的 MCP 伺服器都在企業網路、私有服務網格、開發人員的筆記型電腦，以及其他刻意阻擋公用網路傳入流量的環境中執行。為了將這些伺服器連接到託管式 AI 產品，團隊往往必須建立公開端點、部署額外的代理基礎架構，或在敏感的連線路徑中引入新的網路服務業者。
安全 MCP 通道提供更簡單的做法： 客戶在私有環境內執行一個小型用戶端，由它主動建立連往 OpenAI 的對外 HTTPS 連線。這個用戶端會：
- 接收 MCP 請求
- 將請求轉送至已核准的本機伺服器
- 透過同一條連線傳回回應與通知。
OpenAI 產品可以使用標準的 MCP 請求與回應模型，而底層伺服器仍受客戶現有的網路控管保護。
要讓這套機制可靠且安全地運作，就必須同時解決幾項工程問題：維持伺服器的私有網路邊界、支援 MCP 的串流與身分驗證流程，以及提供團隊能自行檢視與操作的用戶端。本文將逐一說明這些設計決策。
我們依循幾項原則設計通道：僅由內部向外建立連線、明確設定目的地、相容於 MCP 串流與通知，以及提供由客戶執行、團隊可自行檢視與操作的用戶端。
這些設計讓私有工具與資料能輕鬆連接至 OpenAI 產品，而不必將私有 MCP 伺服器變成公開服務。
不合適的預設做法
目前，團隊通常透過三種方式之一，讓外部能連線至私有服務：開放公開端點、執行第三方通道，或透過 VPN 或對等互連擴展網路。
- 公開端點讓存取變得容易，代價是削弱網路邊界。
- 第三方通道供應商可以迅速讓私有伺服器變得可連線，但也在連線路徑中增加了一家必須審查、簽約、維運其服務並予以信任的供應商。對企業團隊來說，這不是小事：這套系統原本是為了讓私有工具保持私有，現在卻必須將通道供應商納入安全性審查、採購流程、維運手冊，以及中繼資料的暴露範圍。
- VPN 與網路對等互連透過建立大範圍的網路連線來解決連線問題，但對範圍有限的 MCP 整合而言，這往往過於繁複。
安全 MCP 通道採取更聚焦的做法。客戶不必搬移 MCP 伺服器、擴大網路邊界，或引入另一家連線服務供應商；安全 MCP 通道會在私有伺服器旁部署一個小型、可供檢視的開源用戶端，由這個用戶端主動建立並控制與 OpenAI 的連線。
安全 MCP 通道反轉了建立連線的方向：由私有環境這一端主動發起。OpenAI 產品將 MCP 請求傳送至 OpenAI 託管的通道端點。通道服務會將工作排入特定通道的佇列，再由客戶在私有 MCP 伺服器旁執行的用戶端，透過對外 HTTPS 連線取回。用戶端在本機轉送請求，並循同一路徑傳回回應。
這讓 OpenAI 產品擁有正常的 MCP 請求路徑，不需要私有伺服器接受公用網路的傳入流量，也不必建立更大範圍的網路連線。
圖 1：安全 MCP 通道的請求生命週期。
為何先採用長輪詢？
我們刻意從一種維運上平淡無奇的傳輸方式著手。對外 HTTPS 連線早已是企業防火牆、代理環境和平台團隊熟悉的機制。長輪詢讓通道用戶端只索取自己能處理的工作量，讓用戶端佇列自然形成背壓控制點，避免無限制地緩衝資料。
這個選擇也讓實際推出的架構容易理解：
- 產品將 MCP JSON-RPC 傳送至 OpenAI 託管的端點。
- 通道服務會讓該請求保持開啟或以串流方式處理，直到客戶執行的用戶端傳回最終回應
- 若請求要求串流結果，通道可以轉送過程中的伺服器傳送事件。
如此一來，產品便擁有正常的 MCP 請求／回應路徑，而 MCP 伺服器及其位址仍維持私有。請求、回應和中間事件都透過 OpenAI 託管的通道端點轉送。
維持明確的安全邊界
通道不是用來消除網路邊界，而是讓邊界更加明確。客戶執行的通道用戶端向通道控制平面進行身分驗證，產品端使用 OpenAI 託管的通道端點，而私有 MCP 位址僅在客戶環境內使用。通道存取權繫結至客戶既有的 OpenAI 組織與工作區上下文，以及已設定的通道身分，不會另成一條擁有獨立存取模型的網路路徑。
這項設計不只是選對網路連線方向。由於通道用戶端在客戶環境內執行，其行為必須可供檢視，且作用範圍必須刻意限縮：客戶應能了解正在執行哪些程式碼、用戶端開啟了哪條對外路徑，以及允許連線至哪些私有服務。
圖 2：MCP 伺服器仍位於客戶的網路邊界內。
讓 MCP 開發如同在本機一樣順手
我們希望通道用戶端用起來像開發工具，而不是一項網路工程。開發人員應能在筆記型電腦上執行 MCP 伺服器、在旁邊啟動通道用戶端，並將伺服器連接至 ChatGPT 或 Codex，不必建立公開端點，也不必等待 VPN、防火牆規則或對等互連的變更。
當伺服器從筆記型電腦移至 Kubernetes、虛擬機器或其他由客戶掌控的環境時，同樣的流程應能沿用。重點是操作概念維持不變：在私有 MCP 伺服器附近執行用戶端，確認用戶端能連線至伺服器，再讓用戶端主動建立通往 OpenAI 的路徑。健康狀態檢查、就緒狀態、日誌和本機管理介面，都是為了讓開發人員在出問題時能檢視這個流程，而不是讓通道變成一項維運工程。
這樣的開發體驗也延伸至 Codex 本身。通道用戶端隨附 Codex 外掛程式，將設定過程化為引導式工作流程，開發人員不必事先學會 tunnel-client 的每個旗標、設定檔和控制平面細節。目標不是建立只能在本機臨時使用的捷徑：外掛程式應產生可沿用的組態結構，讓團隊在伺服器從筆記型電腦移至 Kubernetes、虛擬機器或其他正式環境時，仍能繼續使用。
tunnel-client 隨附的助理工作流程也體現相同理念：助理可以讀取 tunnel-client 提供的本機通道上下文，因此能根據實際設定協助開發人員分析，而非只提供通用指示。這包括目前啟用哪個設定檔、產生了什麼組態、本機 MCP 伺服器是否可連線，以及通道用戶端目前處於啟動流程的哪個階段。 如此一來，疑難排解就成為開發流程的一部分，不必另外循管道逐級求助。
圖 3：從筆記型電腦到正式環境，都能使用相同的 tunnel-client 流程。
為什麼通道用戶端開源很重要
通道用戶端是由客戶執行的開源軟體，位於客戶的網路邊界內，與私有 MCP 伺服器相鄰。這讓客戶與安全性審查人員能檢視在其環境中執行的程式碼。他們可以查看用戶端執行哪些操作、開啟什麼對外連線、如何在本機轉送 MCP 請求，以及哪些組態控制它能連線的範圍。
這種透明度讓信任模型與架構保持一致：OpenAI 託管通道服務，而在客戶環境內執行的程式碼則精簡、可供審查，且由客戶掌控。
無須廣泛網路存取的企業身分驗證
私有 MCP 伺服器很少只是允許匿名存取的內部 HTTP 端點。它們可能依賴 OAuth、私有憑證授權單位、對外代理伺服器，或在連接 MCP 伺服器的這一段使用用戶端憑證。為了支援這些伺服器，我們必須將企業網路的既有條件納入通道設計，而不是視為必須由客戶自行克服的例外情況。
關鍵限制是 MCP 伺服器必須保持私有。MCP 伺服器的 OAuth 探索會經由通道路徑進行，讓託管式產品得知如何進行身分驗證，而不需要 MCP 伺服器在公用網際網路上接聽連線。在客戶這一端，通道用戶端可配合本機環境設定，包括自訂 CA 憑證組合、代理設定，以及 MCP 端的 mTLS。
我們也維持了明確的邊界。通道不會自動讓 OpenAI 能連線至所有相關企業端點。如果授權伺服器位於私有環境，執行 OAuth 流程的元件仍必須能連線至該伺服器。這是刻意保留的邊界：安全 MCP 通道為已設定的私有工具提供範圍有限的連線路徑，而不是通用的網路橋接。
不只支援 MCP
MCP 是模型工具的主要介接形式，但與客戶進行早期 Alpha 測試時，我們發現了一個密切相關的問題：並非所有客戶的私有工作流程都已封裝為 MCP 伺服器。有些重要工作流程是同一防火牆邊界內的既有 REST API。如果安全 MCP 通道只解決 MCP 的連線問題，團隊仍須為這些相關的私有 API 另設公開端點、採用通道供應商、建立 VPN 路徑，或進行對等互連工程。
Harpoon 將相同的有限範圍連線模型延伸至已核准的 REST 目標。客戶不會開放任意 URL，而是在通道用戶端上註冊帶有標籤的目標。OpenAI 端的呼叫者透過安全 MCP 通道呼叫這些標籤，而實際的 HTTP 請求仍由客戶環境內、靠近私有服務的位置發出。
重要的限制是，這些標籤不是通用的網路橋接。呼叫仍受客戶掌控的目標註冊、允許的方法、回應大小限制、逾時設定、重新導向行為和通道存取控制約束。這讓已核准的 OpenAI 工作流程能循受控路徑存取客戶的私有 API，不必要求客戶開放外部傳入的網路存取，也不會給予 OpenAI 類似 VPN 的身分。