MCP 伺服器應以範圍限定的檔案系統掛載、最小權限的祕密、明確的網路政策、每個代理程式的工作區邊界以及日誌來執行，確保工具存取不會在不知不覺中擴張代理程式的信任邊界。當 MCP 伺服器可以讀取檔案、產生子程序、安裝套件、呼叫內部 API，或為長時間執行的代理程式工作階段保存狀態時，沙箱就非常有用。困難的點不是決定 MCP 需要隔離，而是決定每個工具應圍繞哪個邊界、哪些資料能跨越該邊界，以及哪些行動仍需人工審查。
為何 MCP 改變代理程式的信任邊界
模型上下文協定（Model Context Protocol）為 AI 應用提供一種通用的方式，將模型與工具、提示和資源連接起來。這讓整合更簡潔，但也使每個 MCP 伺服器成為一個政策邊界。如果某個伺服器暴露了 read_file、run_command、query_database 或 deploy_preview，代理程式就能要求執行超出模型上下文視窗範圍的行動。
MCP 規格中描述了幾個對沙箱設計很重要的安全期望：使用者應瞭解並同意所暴露的工具；主機應在工具呼叫前取得同意；工具描述未經驗證則不可信任；敏感資料應透過適當的存取控制來保護。這些是應用層面的控制。沙箱則在這些控制之下新增執行階段控制，限制 MCP 伺服器行程能觸及的範圍，即使代理程式、工具描述或提示鏈結發出了錯誤請求。
請從三個層次思考信任邊界：
| 層次 | 控制項目 | 常見失敗模式 |
|---|---|---|
| 主機或 MCP 用戶端 | 哪些伺服器已連線、哪些工具呼叫已獲核准 | 一個廣泛的工具被核准一次，然後在更敏感的環境中被重複使用 |
| MCP 伺服器 | 工具實作、認證、輸入驗證、資源存取 | 工具讀取比預期更多的檔案、發送更多資料、或執行更多指令 |
| 沙箱執行階段 | 檔案系統、行程、網路、祕密、生命週期與日誌 | 伺服器行程因為太接近正式環境資源而繼承了主機存取權 |
目標不是讓每個 MCP 伺服器都以同樣方式被視為不可信任。日曆查詢工具、本機程式碼執行工具和部署工具的風險設定檔不同。目標是讓每個伺服器的執行階段存取範圍不超出其所執行任務的範圍。
優先隔離哪些項目
從那些可以改變外部狀態、接觸敏感資料或執行程式碼的 MCP 伺服器開始。這些伺服器最可能將普通的提示錯誤轉變為更大範圍的事件。
應優先考慮沙箱化的候選項目包括：
- 可執行 shell 指令、Python、Node.js、編譯器、測試或筆記本的程式碼執行工具。
- 可讀寫儲存庫、使用者上傳檔案、掛載資料集、憑證檔案或產生構件（artifact）的檔案系統工具。
- 可保存 cookie、工作階段狀態、下載檔案或螢幕截圖的瀏覽器與電腦使用工具。
- 可查詢客戶記錄、分析匯出、工單或私人文件的資料連接器。
- 可建立分支、發布預覽、輪換設定或修改基礎設施的部署與 CI 工具。
- 可從套件註冊表、Git 遠端端點或任意 URL 取得程式碼的套件與相依性工具。
風險較低的 MCP 伺服器仍可能需要控制。一個唯讀的公開文件搜尋伺服器可能不需要每次請求都開一個微虛擬機，但仍應有允許清單的網路路徑、日誌和速率限制。隔離應根據工具的實際爆炸半徑來決定，而不是貼上「MCP 伺服器」的標籤。
MCP 伺服器應在何處執行
常見的放置模式有三種。沒有一種是放諸四海皆準的。
| 放置方式 | 使用時機 | 注意事項 |
|---|---|---|
| 與代理程式工作區同一個沙箱 | 伺服器與代理程式目前的檔案、shell 指令、瀏覽工作階段或產生的構件緊密耦合 | 伺服器與代理程式共享狀態，因此若掛載和祕密未設定範圍，受感染的工具可以看到相同的工作區 |
| 每個 MCP 伺服器或工具群組獨立沙箱 | 工具需要與代理程式工作區有更強的隔離、處理不同的憑證，或執行高風險操作 | 跨沙箱檔案傳輸和延遲會成為產品設計的一部分 |
| 沙箱外部，透過範圍限定的 API | 工具是一個穩定的正式服務，有自己的認證、授權、日誌和速率限制 | API 必須狹窄；不要僅因為 API 位於沙箱外部就暴露一個廣泛的內部管理表面 |
在開發代理程式時，將伺服器放在同一個沙箱中執行較為方便。MCP 伺服器可以看到儲存庫、執行測試、檢查構件並回傳結果，無需跨環境移動檔案。這種方式最適合工作區本身就是可拋棄式且只包含代理程式應使用的檔案。
當工具需要不同的政策時，獨立沙箱會更好。例如，套件分析的 MCP 伺服器可能需要網際網路存取以查詢公開註冊表，而主開發代理程式則不應有此權限。瀏覽器 MCP 伺服器可能需要測試帳號的 cookie，而程式碼執行伺服器絕不應看到這些 cookie。
外部服務則適合那些根本不算「執行階段工具」的工具。帳單查詢、功能旗標讀取或問題追蹤搜尋，作為具有伺服器端授權的一般後端 API，可能比作為代理程式運算環境中的自由形式伺服器更安全。
檔案系統掛載與每個代理程式的工作區
檔案系統存取是 MCP 便利性常變成意外權限的地方。一個需要讀取 ./src 的伺服器不應繼承開發者的家目錄。一個寫入產生圖表的工具不應能覆寫部署設定。
使用明確的工作區邊界：
- 為每個代理程式執行作業提供自己的工作區目錄。
- 僅掛載該任務所需的儲存庫、上傳資料夾、資料集或構件目錄。
- 偏好唯讀掛載用於原始素材，讀寫掛載僅用於輸出。
- 將產生的輸出與受信任的原始檔案分開。
- 避免掛載憑證資料夾，例如
.ssh、雲端設定目錄、瀏覽器設定檔或本機套件管理員的認證檔案。 - 在不同使用者、租戶或任務之間重設或快照工作區。
MCP 的「根（root）」機制可以幫助用戶端告知伺服器應操作的檔案系統位置，但根並非完整的安全邊界。應將其視為用戶端與伺服器之間的協調機制。執行階段仍需要檔案系統層級的限制，且伺服器應驗證路徑，以避免請求透過符號連結、相對路徑或封存解壓縮技巧逃離預期的工作區。
一個實用的模式是按角色劃分工作區存取權限：
| 目錄 | 存取權限 | 用途 |
|---|---|---|
/workspace/input |
唯讀 | 使用者上傳、種子儲存庫、基準測試固定資料或測試資料 |
/workspace/output |
讀寫 | 產生的檔案、報告、修補檔、圖表或螢幕截圖 |
/workspace/tmp |
讀寫、可捨棄 | 建置快取、套件安裝快取、暫存檔案 |
/workspace/secrets |
盡量避免檔案掛載 | 若無法避免，掛載一個有嚴格生命週期和遮罩處理的範圍限定祕密檔案 |
確切的路徑名稱並不重要，原則才是。
祕密與環境變數
祕密通常比檔案更容易洩漏，因為它們會透過環境變數、日誌、堆疊追蹤、套件腳本、shell 歷史、瀏覽器工作階段和工具回應傳播。當 MCP 伺服器需要憑證時，請給予能完成工具動作的最狹窄憑證。
為不同的 MCP 伺服器使用不同的憑證。GitHub 問題搜尋伺服器可能只需要唯讀的問題存取權。PR 撰寫伺服器可能需要分支寫入權限。除非權限模型真的需要，否則部署伺服器不應共用這兩種權杖。
良好的 MCP 伺服器祕密處理方式如下：
- 在沙箱或行程啟動時注入祕密，而不是透過提示。
- 在提供者支援的情況下使用短期或可撤銷的權杖。
- 按工具、租戶、環境和動作來界定憑證範圍。
- 在 stdout、stderr、結構化工具回應和追蹤日誌中遮罩祕密。
- 不要將原始環境變數回傳給模型。
- 不要讓代理程式決定載入哪個祕密。
- 輪替高風險伺服器使用的憑證，並在懷疑有提示注入暴露時進行輪替。
避免一個常見的反模式：將一個萬用環境檔案掛載到每個代理程式工作階段。這讓本機開發更容易，卻讓正式環境審查更困難。如果工具不需要某個祕密，它就不應該能夠讀取它。
網路對外連線與傳輸選擇
MCP 支援本機和遠端傳輸模式。規格說明了用於本機行程通訊的 stdio，以及用於伺服器對用戶端 HTTP 通訊的 Streamable HTTP。較舊的 SSE 設計在生態系統中仍然存在，但新的整合應查閱當前的 MCP 文件和所選的 SDK，再決定依賴哪種傳輸方式。
傳輸選擇和沙箱網路政策解決的是不同問題：
| 問題 | 傳輸方式回答 | 網路政策回答 |
|---|---|---|
| MCP 用戶端如何與伺服器通訊？ | stdio、基於 HTTP 的傳輸或其他支援模式 | 不適用 |
| 伺服器可以呼叫哪些外部主機？ | 本身不足以回答 | 允許清單、拒絕清單、代理、DNS 政策或無對外連線 |
| 伺服器能否擷取套件或網頁？ | 本身不足以回答 | 註冊表允許清單、URL 允許清單、快取和日誌 |
| 其他行程能否觸及此伺服器？ | 綁定和認證細節 | 入站防火牆和沙箱網路邊界 |
對於本機 stdio 伺服器，風險通常來自繼承的主機存取權。伺服器可能以主機應用程式的子行程執行，並看到本機檔案、環境變數和網路路由。如果該伺服器執行程式碼或讀取敏感檔案，請將其移入沙箱化行程，或將整個主機-工作者配對放到可拋棄式工作區中執行。
對於基於 HTTP 的 MCP 伺服器，風險轉向認證、網路暴露和跨租戶隔離。使用伺服器端授權、TLS、相關的來源檢查機制以及每個用戶端的憑證。不要將遠端 MCP 伺服器暴露在廣泛的內部網路上，而沒有明確的政策規定誰可以呼叫哪些工具。
對於網路對外連線，預設拒絕比預設開放更容易推理。如果工具需要套件安裝，允許該套件註冊表或拉取通過快取。如果需要網路研究，則透過一個會記錄請求網域並阻擋內部中繼資料端點的代理進行路由。如果需要內部 API，則暴露一個狹窄的 API，而不是整個私有網路。
套件安裝、子程序與長期執行狀態
許多有用的 MCP 工具需要子程序。開發代理程式執行測試。資料代理程式安裝函式庫。瀏覽器代理程式啟動瀏覽器。建置代理程式呼叫編譯器。子程序支援本身不是問題，看不見的子程序支援才是。
在允許套件安裝或 shell 執行之前，先定義：
- 哪些指令允許、拒絕或需要核准才能執行。
- 套件管理員能否存取公開網際網路。
- 相依性版本是否必須鎖定或基於 lockfile。
- 建置快取和已安裝套件存放的位置。
- 背景行程可以執行多久。
- 清理後保留哪些輸出檔案。
- 代理程式能否啟動網路監聽器。
長時間執行的 MCP 伺服器會引出第二個問題：狀態漂移。一個存活數小時的伺服器可能會累積檔案、憑證、瀏覽器 cookie、shell 歷史、相依性變更和背景作業。這些狀態對於多步驟工作流程可能很有用，但它們必須屬於正確的代理程式、使用者和任務。
使用生命週期控制：
| 控制項 | 重要性 |
|---|---|
| 每個代理程式的沙箱 ID | 防止一個代理程式的工具狀態變成另一個代理程式的上下文 |
| 閒置逾時 | 清理被遺棄的工具工作階段 |
| 暫停與恢復政策 | 支援長時間作業，無需讓不必要的運算保持活動 |
| 快照或範本政策 | 從已知基準啟動可重複的環境 |
| 明確的拆卸 | 作業完成後移除檔案、終止行程並釋放憑證 |
如果某個工具產生了持久性的構件，只將這些構件複製出沙箱。除非產品明確需要完整的工作階段重播，否則不要保留整個工作區。
日誌、清理與人工審查
MCP 工具日誌應能回答安全性和除錯問題，而不會變成一個新的祕密儲存庫。有用的日誌包括工具名稱、呼叫者身份、沙箱 ID、工作區 ID、指令類別、讀取或寫入的檔案、接觸的外部網域、安裝的套件名稱、退出狀態和構件路徑。
預設情況下，不要記錄原始提示、原始客戶資料、權杖、完整檔案內容或完整指令輸出。將敏感的追蹤資訊放在更嚴格的存取控制和保留政策之後。
某些 MCP 動作即使在沙箱內也應保持人工審查：
- 發布或部署到正式環境。
- 發送電子郵件、聊天、工單、發票或面向客戶的訊息。
- 修改存取控制、帳單、使用者資料或基礎設施設定。
- 外洩大型檔案、私有儲存庫、資料庫匯出或類似憑證的字串。
- 在工作區政策之外執行指令。
- 以寫入權限呼叫內部 API。
沙箱應能縮小爆炸半徑。不應將其作為從敏感業務動作中移除審查的理由。
Novita Agent Sandbox 如何融入
Novita Agent Sandbox 專為需要隔離執行階段的代理程式工作負載而設計，適用於程式碼執行、檔案、行程、瀏覽器風格工作流程和長期執行的工作階段。它適合用於 MCP 架構中那些工具伺服器需要可拋棄式工作區，而非直接存取開發者筆電、正式主機或共享 CI 機器的情況。
將其作為伺服器的執行階段邊界，這些伺服器需要：
- 執行產生的程式碼或指令。
- 處理暫存檔案和產生的構件。
- 在多步驟任務中保持每個代理程式的工作區狀態。
- 執行背景工作，讓代理程式稍後可以檢查。
- 將代理程式的實驗與應用主機分開。
產品邊界需要明確：MCP 伺服器仍然是你的應用程式碼。你仍然需要設計工具權限、憑證範圍、網路政策、核准流程、日誌綱要與清理行為。沙箱提供了強制執行這些決策的隔離環境。
關於產品特定的設定，請使用當前的 Novita 文件，而不是從較舊的教學中複製過時的片段。概念上，其形狀如下：
for each agent task:
create sandbox from approved template
mount only the task workspace
inject only tool-specific secrets
start the MCP server inside the sandbox or connect to a sandbox-backed tool API
route tool calls through approval and policy checks
collect logs and approved artifacts
stop, reset, or pause the sandbox according to the task lifecycle
這使文章層級的指引保持穩定，同時將確切的 SDK 呼叫留給最新的文件和你的平台程式碼。
實施檢查清單
在將 MCP 伺服器連接到自主或半自主代理程式之前，請使用此檢查清單：
| 領域 | 需要回答的問題 |
|---|---|
| 工具範圍 | 伺服器暴露了哪些工具，哪些工具會改變外部狀態？ |
| 放置位置 | 伺服器應在代理程式沙箱中、獨立沙箱中，還是沙箱外部透過狹窄 API 執行？ |
| 檔案系統 | 哪些目錄被掛載，它們是唯讀還是讀寫，如何阻止路徑逃逸？ |
| 祕密 | 哪些憑證被注入，它們的範圍如何界定，它們可能出現在日誌或輸出中的何處？ |
| 網路 | 對外連線是預設拒絕、透過代理路由，還是按網域、註冊表和內部 API 允許清單？ |
| 子程序 | 允許哪些指令、套件管理員、背景工作和監聽器？ |
| 狀態 | 如何處理每個代理程式的工作區、快照、閒置逾時、暫停/恢復行為和清理？ |
| 日誌 | 能否重建工具呼叫、檔案變更、外部網域和構件，而不儲存祕密？ |
| 人工審查 | 哪些工具呼叫在執行、匯出、部署或面向客戶行動前需要核准？ |
| 測試 | 是否測試過提示注入、符號連結/路徑遍歷、大型輸出、清理失敗以及被拒絕的對外連線路徑？ |
MCP 讓工具整合更簡單。沙箱化則防止這種整合變成模型權限的無聲擴張。正確的設計通常是混合的：有些伺服器放在同一個代理程式工作區，有些放在獨立沙箱，有些則放在沙箱外，透過具有嚴格授權的 API 存取。選擇與工具的資料、祕密、子程序和網路需求相符的放置方式。
常見問題
每個 MCP 伺服器都應該在沙箱中執行嗎？
不需要。優先處理那些執行程式碼、讀寫檔案、使用祕密、呼叫私有服務、啟動瀏覽器、安裝套件或改變外部狀態的伺服器。風險較低的唯讀伺服器可能仍需要認證、日誌和網路控制，但它們可能不需要每次請求都有一個專用沙箱。
stdio 比 HTTP 更安全嗎？
不一定。Stdio 對本機伺服器很簡單，但伺服器可能繼承本機檔案系統、環境和網路存取權。基於 HTTP 的伺服器需要更強的認證和暴露控制。安全的選擇取決於行程在哪裡執行以及它收到了哪些執行階段權限。
MCP 的「根」可以取代檔案系統沙箱化嗎？
不能。根有助於在用戶端和伺服器之間溝通預期的工作區位置，但它們不是完整的執行階段邊界。請使用路徑驗證和沙箱層級的檔案系統控制，確保伺服器保持在預期的工作區內。
沙箱化 MCP 工具的祕密應存放在哪裡？
只注入工具所需的憑證，理想情況下是作為短期環境變數或範圍限定的執行階段祕密。不要掛載廣泛的開發者憑證資料夾，也不要透過提示傳遞祕密。將它們從日誌和工具回應中遮罩。
何時 MCP 工具需要人工核准？
需要對正式環境部署、面向客戶的訊息、帳單或存取控制變更、大量資料匯出、基礎設施寫入，以及任何超出正常工作區政策的指令或網路行動要求核准。
