本地 MCP Server 已能在你的電腦上呼叫工具，但一放到公網就開始出現未授權請求、憑證散落和錯誤難以追查的問題。
最快解法：先定義資源與信任邊界，再以隔離環境部署 Streamable HTTP，完成 OAuth 2.1、HTTPS、權杖受眾驗證、日誌脫敏及失敗驗收，不能只把本地程序轉成一個公開網址。
這篇文章適合三類讀者：已完成本地 STDIO MCP Server、準備遠端共享的開發者；需要提供統一 Agent 工具入口的平台工程師；以及負責 MCP 授權、審計和執行隔離的安全人員。
最後更新於 2026 年 7 月 29 日；活動資料核實自 Linux Foundation 官方活動頁，協議與安全要求核實自 MCP 官方規範、授權文件及安全最佳實踐。 AGNTCon + MCPCon Europe 已確認於 2026 年 9 月 17 至 18 日 在阿姆斯特丹舉行，官方日程包含 MCP 挑戰、工具介面及 Agent 基礎設施議題；以下部署要求仍以當前官方規範為準，不把會議議題當成已發布的協議承諾。(events.linuxfoundation.org)
先分清 STDIO 與遠端 HTTP 的安全邊界
本地 STDIO MCP Server 通常由客戶端啟動為子程序，透過標準輸入與標準輸出交換 JSON-RPC 訊息；服務並不需要自行面向整個網路。遠端 HTTP 則由獨立伺服器處理多個連線，客戶端透過 HTTP POST、GET 及可選的事件串流溝通，信任邊界已從「同一台電腦上的客戶端」擴展到身份、網域、網路及下游服務。(modelcontextprotocol.io)
| 決策維度 | 本地 STDIO | 遠端 Streamable HTTP |
|---|---|---|
| 啟動方式 | 客戶端啟動子程序 | 伺服器獨立執行 |
| 主要暴露面 | 本機程序、環境變數、檔案權限 | HTTPS、來源標頭、授權端點、公開網路 |
| 憑證取得 | 通常由本地環境提供 | 需要明確處理使用者權杖與下游憑證 |
| 適合情境 | 個人開發、單機工具、內部測試 | 團隊共享、集中審計、跨環境 Agent |
| 上線前最低要求 | 限制檔案與網路權限 | TLS、授權、權杖驗證、隔離、撤銷及錯誤測試 |
MCP 官方文件指出，HTTP 傳輸應遵循授權規範；STDIO 則不應照搬這套 HTTP 授權流程，而是以環境取得憑證。這不是「STDIO 不需要安全」，而是兩種傳輸的邊界不同：本地服務要避免被其他程序濫用，遠端服務則要把每個請求視為不可信輸入。(modelcontextprotocol.io)
遠端化時最容易低估的成本有三項：
- 工具權限擴大：本地工具可能可以讀取專案目錄、寫入檔案或執行命令；一旦共享，原本隱含的本人同意不再成立。
- 下游憑證變成集中風險：伺服器若持有第三方 API 憑證，任何錯誤的工具路由、日誌或權杖轉送，都可能造成橫向存取。
- 錯誤與審計更複雜：未授權、權限不足、權杖過期、下游逾時及工具本身失敗，必須能分開診斷，卻不能把內部路徑或秘密寫進紀錄。
先完成資源盤點，再決定可以遠端化什麼
在寫 Dockerfile、反向代理或啟動指令之前，先做一張工具清單。每個工具至少記錄以下欄位：
- 工具名稱及用途。
- 會讀取的資料來源與資料分類。
- 是否會寫檔、刪檔、發送訊息或觸發外部交易。
- 所需的最小 OAuth scope。
- 是否必須由使用者在每次操作前明確同意。
- 發生錯誤時可以回傳給 Agent 的最少資訊。
把工具分成「只讀」、「可變更」及「高風險寫入」三組。只讀不等於低風險，例如讀取客戶資料、原始碼或內部工單，仍可能造成敏感資料外洩；可變更工具則應設計明確的確認步驟、資源範圍與冪等行為。
| 服務層 | 建議預設 | 遠端部署前的判斷 |
|---|---|---|
| 公開說明、健康檢查 | 可公開或低權限 | 不得回傳環境變數、路徑或內部版本細節 |
| 私人資料查詢 | 要求使用者授權 | scope 僅包含必要讀取範圍，並記錄操作者 |
| 檔案寫入、部署、刪除 | 預設拒絕 | 需要明確同意、目標範圍及回滾方式 |
| 下游 API 呼叫 | 使用伺服器自己的憑證 | 不可把客戶端權杖原樣轉送到下游 |
如果某個本地工具依賴「使用者目前登入的桌面狀態」、本機檔案選擇器或未定義的環境變數，先不要把它標記為可生產遠端化。你需要先改寫依賴注入方式，讓輸入、權限和失敗結果都能被伺服器明確控制。
首次部署時建立可重建的隔離基線
遠端 MCP Server 不應以 root 或其他特權帳號執行。你可以按以下順序建立第一個隔離環境：
- 建立專用執行帳號：不允許互動式登入，只授予啟動服務、讀取必要目錄及寫入暫存目錄的權限。
- 限制檔案系統：只掛載必要的專案、快取及設定目錄；將憑證目錄設為不可被工具直接讀取，改由受控的秘密管理機制注入。
- 限制網路出口：只允許連到必需的身份服務、下游 API 及套件來源；不要因為初期除錯方便，就開放所有目的地。
- 固定應用依賴：記錄語言版本、套件鎖定檔、系統套件、啟動參數及環境變數名稱。秘密值只記錄來源，不記錄內容。
- 分離測試與生產：測試環境使用獨立 OAuth Client、獨立下游憑證及測試資料，不能讓驗收請求直接觸及生產資源。
MCP 安全最佳實踐建議，執行環境應以最小預設權限限制檔案系統、網路及其他系統資源；即使是本地服務，也應避免讓任意程序透過 HTTP 介面使用它。(modelcontextprotocol.io)
這一步的真正產出不是「容器可以啟動」，而是一份可重建基線：換一台伺服器、重新部署或回滾版本時，你知道哪些是應用依賴，哪些是系統依賴，哪些設定必須重新產生。
按官方流程接上 HTTPS 與 OAuth 2.1
對跨使用者或跨團隊的遠端 MCP Server，採用標準授權流程比自製 API Key 邏輯更容易被客戶端、審計工具和日後的規範更新接納。MCP 官方授權規範要求 HTTP 型實作提供受保護資源中繼資料，並以 OAuth 2.1 安全措施處理授權伺服器；客戶端應能從 401 Unauthorized 的 WWW-Authenticate 或 well-known 位置發現授權資訊。(modelcontextprotocol.io)
實作時按這個順序檢查：
- 為 MCP 端點配置有效 HTTPS；生產環境不要接受一般 HTTP OAuth 網址。
- 為伺服器定義穩定的資源識別 URI，並在授權請求與權杖請求中使用
resource參數。 - 提供 Protected Resource Metadata，讓客戶端知道授權伺服器、scope 及相關端點。
- 採用 Authorization Code Flow 與 PKCE，並驗證
state、精確回呼 URI 及S256code challenge。 - 每次 HTTP 請求都以
Authorization: Bearer傳送權杖，禁止把權杖放入查詢字串。 - 在處理工具呼叫前驗證簽發者、有效期、scope 及受眾；受眾不是本 MCP Server 的權杖應直接拒絕。
- 如果 MCP Server 要呼叫下游 API，另行取得下游所需的權杖，不能把客戶端送來的權杖直接轉送。
Token passthrough 是最需要在程式碼審查中明確禁止的反模式。MCP 官方安全文件指出，未驗證受眾便把權杖轉送至下游，會繞過速率限制、請求驗證及審計控制，並形成 confused deputy 風險。(modelcontextprotocol.io)
分開儲存憑證，讓日誌可追查但不可還原秘密
至少把以下三類資料分開管理：
- 客戶端權杖：代表使用者授權，應有明確到期、撤銷及重新授權流程。
- MCP Server 的 OAuth Client Secret：只供伺服器端使用，不應送到瀏覽器或寫入前端設定。
- 下游 API 憑證：代表服務本身或特定服務帳號，scope、輪替週期及撤銷責任都與客戶端權杖不同。
日誌可以保留請求 ID、操作者識別碼的雜湊、工具名稱、資源識別、結果類別、延遲及下游狀態碼，但不要保留 Authorization 標頭、完整查詢參數、回呼中的 code、refresh token、API Key 或工具輸入中的秘密欄位。若工具輸入可能含個人資料，應採欄位級遮罩，而不是只刪除整段請求。
MCP 官方除錯文件也提醒，本地 STDIO Server 不應把一般訊息寫入 stdout，否則可能干擾協議訊息；日誌應使用 stderr 或適當的客戶端通知機制。這個限制在你把本地程式改成 HTTP 服務時仍值得保留：協議通道與診斷通道必須分開。(modelcontextprotocol.io)
接入客戶端並設計四類失敗行為
不要先用「成功連線」作為驗收標準。先建立一組最小測試矩陣，再讓真正的 AI Agent 接入：
- 未帶權杖：應回傳
401，同時提供可供客戶端探索授權位置的資訊；回應不能透露伺服器內部設定。 - 權杖已過期或簽章無效：仍回傳
401，不應把下游服務的詳細錯誤直接傳回。 - scope 不足：回傳
403或規範要求的權限錯誤，並清楚指出所需權限類型，但不暴露額外資料。 - 下游失敗：保留請求 ID 與內部診斷紀錄，對 Agent 回傳穩定的錯誤類別，避免洩露內部網域、檔案路徑或堆疊追蹤。
接入客戶端時，先用低權限測試帳戶，確認它只看得到允許的工具和資源；再測試權杖撤銷、重新授權、網路中斷及重試。若客戶端把任何字串都當作可執行工具結果，還要檢查服務端是否會把下游錯誤、未過濾內容或提示注入直接交給模型。
上線驗收與持續維護按時間表執行
你可以把最後驗收拆成五個時間點，而不是一次性打勾：
| 時間點 | 必查項目 | 不合格時的處理 |
|---|---|---|
| 設計完成 | 工具、資料、寫入操作、scope、同意要求 | 退回資源盤點，不進入部署 |
| 首次啟動 | 非特權帳號、檔案掛載、網路出口、秘密注入 | 停止公開端點，修正隔離基線 |
| 客戶端接入 | 401、403、過期權杖、PKCE、回呼 URI |
只允許測試帳戶，不接生產資料 |
| 上線前 | 權杖受眾、token passthrough、日誌脫敏、撤銷 | 阻擋發布，完成安全測試 |
| 長期維護 | 依賴更新、規範更新、備份、回滾、輪替 | 先在獨立環境重測，不假設向後相容 |
MCP 官方傳輸文件要求 Streamable HTTP 伺服器驗證所有連線的 Origin，無效來源應拒絕；本地執行時則應綁定 localhost，而不是任意網路介面。即使你的服務位於反向代理後方，也要確認代理沒有把來源驗證、HTTPS 或身份資訊錯誤地剝除。(modelcontextprotocol.io)
規範或 SDK 更新後，不要只跑一次健康檢查。至少重新執行授權探索、PKCE、權杖受眾、scope 最小化、撤銷、錯誤回應及回滾測試。官方 Go SDK 的發行紀錄顯示，協議版本與 HTTP 狀態模型可能持續演進；因此「舊客戶端目前能連線」不能被當成「下一版仍然安全且相容」的證明。(github.com)
常見部署問題的實務答案
本地 MCP Server 怎樣部署到遠端伺服器？
先保留原本工具邏輯，抽出啟動、設定、憑證和檔案存取邊界，再把通訊層改為 Streamable HTTP。部署時使用非特權帳號與受限檔案系統，透過 HTTPS 暴露單一 MCP 端點，並以獨立測試帳戶驗證授權與錯誤回應。若工具仍依賴本地桌面狀態或任意檔案路徑，應先重構，而不是直接公開端口。
遠端 MCP Server 必須使用 OAuth 2.1 嗎？
不是所有 MCP 實作都必須使用同一種授權方式，但 HTTP 型遠端服務應依 MCP 授權規範處理 OAuth 2.1、安全傳輸、受保護資源中繼資料、PKCE 及權杖受眾驗證。只有在非常受控的內部環境中，其他身份機制才可能合理；即使如此，也不能省略 HTTPS、最小權限和撤銷能力。
MCP Server 如何防止憑證洩露？
把使用者權杖、OAuth Client Secret 和下游 API 憑證分開，禁止寫入程式碼、查詢字串及一般日誌。伺服器要驗證權杖確實發給自己，並為下游重新取得適用的憑證；同時限制檔案、網路及執行權限。若發生外洩，應能立即撤銷、輪替並從紀錄中追查受影響的工具呼叫。
MCP STDIO 和 HTTP 部署有什麼不同？
STDIO 主要依賴本機客戶端與子程序邊界，憑證通常由本地環境提供；HTTP 則需要面對獨立伺服器、多個客戶端、公開端點及跨網路威脅。除了改變傳輸方式，你還必須新增 HTTPS、Origin 驗證、OAuth 探索、PKCE、權杖受眾檢查、日誌脫敏及撤銷測試，否則只是把本地信任假設搬到更大的暴露面。
如果你目前的方案是把一台 Windows、Linux 或一般雲端主機直接開放端口，常見缺點是本地工具權限沒有重新切分、下游憑證與使用者身份混在一起、重建和回滾依賴人工操作，而且當 MCP 規範或 SDK 更新時，很難快速重跑完整驗收。對需要臨時算力、隔離測試環境或短期遠端開發的團隊，租用 Macstripe 的 Mac 環境通常比長期維護一台未經整理的通用主機更容易控制；但若你需要長期穩定重負載、固定硬體介面或完全自管的網路邊界，自購 Mac 或既有企業基礎設施仍可能更合適。
你可以先參考 Macstripe 的幫助中心，按照本文的資源盤點、授權、隔離和失敗測試逐項審計現有 MCP Server；確認邊界後，再透過 Macstripe 的配置與訂單頁安排遠端環境，將部署和安全加固分成可回滾的階段，而不是直接把未驗收的本地服務推上公網。
常見問題
本地 MCP Server 要怎樣搬到遠端伺服器？
不要直接把原本由桌面客戶端啟動的 STDIO 程式放到公網。先盤點工具、資料與寫入操作，再把服務包入非特權執行環境，改用受 HTTPS 保護的 Streamable HTTP 端點，接上授權、憑證分離、日誌脫敏及失敗測試，最後才讓 AI Agent 使用。
遠端 MCP Server 一定要使用 OAuth 2.1 嗎？
MCP 授權規範針對 HTTP 傳輸提供 OAuth 2.1 及受保護資源中繼資料流程；HTTP 實作應依規範完成。STDIO 則通常由本地客戶端啟動，憑證可從環境取得，不應硬套 HTTP 授權流程。若服務跨使用者、跨團隊或處理敏感資料，採用標準 OAuth 流程通常是較可維護的選擇。
MCP Server 怎樣避免 API 憑證外洩？
把客戶端權杖、MCP Server 的下游 API 憑證及 OAuth Client Secret 分開儲存，避免放在程式碼、查詢字串或一般日誌中。MCP Server 必須驗證權杖的受眾，不可把客戶端收到的權杖原樣轉送至下游服務，並要為撤銷、輪替及外洩後重發預留流程。
MCP STDIO 和 HTTP 部署主要差在哪裡？
STDIO 是客戶端在本機啟動子程序，邊界通常由作業系統程序與環境變數提供；HTTP 則是獨立服務，必須處理 TLS、來源驗證、授權探索、權杖受眾、跨網路暴露及多客戶端隔離。把 STDIO 的安全假設直接搬到 HTTP，通常會漏掉最關鍵的身份與傳輸控制。
