MCP 伺服器應使用限定的檔案系統掛載、最小權限機密、明確的網路策略、每個 AI 智能體的工作區邊界以及日誌來執行，以使工具存取不會悄然擴展智能體的信任邊界。當 MCP 伺服器可以讀取檔案、產生子程序、安裝套件、呼叫內部 API，或在長時間執行的 AI 智能體工作階段中保存狀態時，沙盒就非常有用。困難的部分不是決定 MCP 需要隔離，而是決定每個工具的邊界應放在哪裡、哪些資料跨越該邊界，以及哪些動作仍需要人工審核。
為什麼 MCP 改變了 AI 智能體的信任邊界
模型上下文協定（Model Context Protocol）為 AI 應用程式提供了一種通用方式來連接模型與工具、提示和資源。這讓整合變得更乾淨，但也使每個 MCP 伺服器成為一個策略邊界。如果一個伺服器公開了 read_file、run_command、query_database 或 deploy_preview，那麼 AI 智能體現在可以請求超出模型上下文視窗範圍的動作。
MCP 規範描述了幾個與沙盒設計相關的安全期望：使用者應了解並同意暴露的工具，主機應在工具調用前徵得同意，工具描述在未經驗證的情況下不可信，敏感資料應透過適當的存取控制進行保護。這些規則屬於應用層控制。沙盒則在其之下增加了執行階段控制，即使 AI 智能體、工具描述或提示鏈提出了錯誤請求，也能限制 MCP 伺服器程序可以觸及的範圍。
從三個層次思考信任邊界：
| 層次 | 控制什麼 | 常見失敗模式 |
|---|---|---|
| 主機或 MCP 用戶端 | 哪些伺服器已連接以及哪些工具呼叫已批准 | 一個廣泛的工具被批准一次，然後在更敏感的上下文中被重複使用 |
| MCP 伺服器 | 工具實作、身分驗證、輸入驗證、資源存取 | 一個工具讀取了比預期更多的檔案、發送了更多資料或執行了更多指令 |
| 沙盒執行階段 | 檔案系統、程序、網路、機密、生命週期和日誌 | 伺服器程序繼承了主機的存取權限，因為它在離生產資源太近的地方執行 |
目標不是讓每個 MCP 伺服器都以相同的方式被視為不可信。一個日曆查詢工具、一個在地端執行程式碼的工具和一個部署工具具有不同的風險設定檔。目標是讓每個伺服器的執行階段存取權限不超出其執行工作的範圍。
優先隔離什麼
從那些可以改變外部狀態、觸及敏感資料或執行程式碼的 MCP 伺服器開始。這些伺服器最有可能將一個普通的提示錯誤轉變為更大的事故。
需要沙盒化的高優先級候選包括：
- 執行 shell 指令、Python、Node.js、編譯器、測試或筆記本的程式碼執行工具。
- 讀寫儲存庫、使用者上傳、掛載資料集、憑證檔案或生成構件的檔案系統工具。
- 保存 cookie、工作階段狀態、下載檔案或螢幕截圖的瀏覽器和電腦使用工具。
- 可以查詢客戶記錄、分析匯出、工單或私人文件的資料連接器。
- 可以建立分支、發布預覽、輪換配置或修改基礎設施的部署和 CI 工具。
- 可以從註冊表、Git 遠端或任意 URL 取得程式碼的套件和相依性工具。
較低風險的 MCP 伺服器仍然值得加上控制。一個唯讀的公開文件搜尋伺服器可能不需要每個請求都有一個微型 VM，但它仍應有允許清單的網路路徑、日誌和速率限制。隔離應遵循工具的實際爆炸半徑，而不是「MCP 伺服器」這個標籤。
MCP 伺服器應在何處執行
有三種常見的部署模式，沒有一種是普遍正確的。
| 部署位置 | 使用時機 | 注意事項 |
|---|---|---|
| 與 AI 智能體工作區相同的沙盒 | 伺服器與 AI 智能體目前的檔案、shell 指令、瀏覽器工作階段或生成的構件緊密耦合 | 伺服器和 AI 智能體共享狀態，因此除非掛載和機密設定了範圍，否則受損的工具可以看到相同的工作區 |
| 每個 MCP 伺服器或工具群組的獨立沙盒 | 工具需要與 AI 智能體工作區更強的隔離、處理不同的憑證，或執行更高風險的操作 | 跨沙盒檔案傳輸和延遲會成為產品設計的一部分 |
| 在沙盒外，透過限定的 API | 工具是一個穩定的生產服務，有自己的身分驗證、授權、日誌記錄和速率限制 | API 必須狹窄；不要僅僅因為它位於沙盒之外就暴露一個廣泛的內部管理介面 |
在相同的沙盒中執行伺服器對編碼 AI 智能體來說很方便。MCP 伺服器可以看見儲存庫、執行測試、檢查構件並返回結果，而無需在不同環境之間移動檔案。當工作區本身已經是 disposable（可拋棄）且只包含 AI 智能體應使用的檔案時，這種方式效果最好。
當工具需要不同的策略時，獨立沙盒更好。例如，一個套件分析 MCP 伺服器可能需要網際網路存取公開註冊表，而主要編碼 AI 智能體則不應有此需求。一個瀏覽器 MCP 伺服器可能需要用於測試帳號的 cookie，而程式碼執行伺服器永遠不應看到這些 cookie。
外部服務適合那些實際上並非「執行階段工具」的工具。帳務查詢、功能旗標讀取或問題追蹤器搜尋，作為具有伺服器端授權的正常後端 API，可能比在 AI 智能體的計算環境內作為自由形式的伺服器更安全。
檔案系統掛載與每個 AI 智能體的工作區
檔案系統存取是 MCP 的便利性常變成意外權限的地方。一個需要讀取 ./src 的伺服器不應繼承開發者的家目錄。一個寫入生成圖表的工具不應能覆寫部署配置。
使用明確的工作區邊界：
- 為每個 AI 智能體執行分配一個獨立的工作區目錄。
- 僅掛載任務所需的儲存庫、上傳資料夾、資料集或構件目錄。
- 對於原始資料優先使用唯讀掛載，唯輸出目錄才使用讀寫掛載。
- 將生成的輸出與受信任的原始檔案分開。
- 避免掛載憑證資料夾，例如
.ssh、雲端配置目錄、瀏覽器設定檔或本地套件管理員的認證檔案。 - 在不同使用者、租戶或作業之間重設或快照工作區。
MCP roots 可以幫助用戶端溝通伺服器應操作的檔案系統位置，但 roots 本身並非完整的邊界。將它們視為用戶端與伺服器之間的協調機制。執行階段仍需要檔案系統層級的限制，且伺服器應驗證路徑，以防止請求透過符號連結、相對路徑或歸檔解壓縮技巧逃離預期的工作區。
一個實用的模式是依角色拆分工作區存取：
| 目錄 | 存取權限 | 用途 |
|---|---|---|
/workspace/input |
唯讀 | 使用者上傳、種子儲存庫、基準測試 fixture 或測試資料 |
/workspace/output |
讀寫 | 生成的檔案、報告、修補程式、圖表或螢幕截圖 |
/workspace/tmp |
讀寫，可拋棄 | 建置快取、套件安裝快取、暫存檔案 |
/workspace/secrets |
盡可能避免使用檔案掛載 | 如果無法避免，請掛載一個限制範圍的機密檔案，並嚴格限制生命週期和編輯 |
具體路徑不重要，原則才重要。
機密與環境變數
機密通常比檔案更容易外洩，因為它們會透過環境變數、日誌、堆疊追蹤、套件腳本、shell 歷史、瀏覽器工作階段和工具回應傳播。當 MCP 伺服器需要憑證時，請賦予它能夠完成工具動作的最小範圍憑證。
為不同的 MCP 伺服器使用不同的憑證。一個 GitHub 問題搜尋伺服器可能只需要唯讀的問題存取權限。一個 PR 撰寫伺服器可能需要分支寫入權限。一個部署伺服器不應共享任一個 Token，除非權限模型確實需要。
良好的 MCP 伺服器機密處理方式如下：
- 在沙盒或程序啟動時注入機密，而非透過提示。
- 當提供者支援時，使用短期或可撤銷的 Token。
- 按工具、租戶、環境和動作限定憑證範圍。
- 從 stdout、stderr、結構化工具回應和追蹤日誌中遮罩機密。
- 不要將原始環境變數返回給模型。
- 不要讓 AI 智能體決定載入哪個機密。
- 輪換高風險伺服器使用的憑證，並在疑似提示注入暴露後進行輪換。
避免一個常見的反模式：一個通用的環境檔案掛載到每個 AI 智能體工作階段。這讓本地開發更容易，但讓生產審查更困難。如果一個工具不需要某個機密，它就不應能夠讀取它。
網路出口與傳輸選擇
MCP 支援本地端與遠端傳輸模式。規範描述了用於本地端程序通訊的 stdio，以及用於伺服器與用戶端之間透過 HTTP 通訊的 Streamable HTTP。較舊的 SSE 為基礎的設計在生態系統中仍然存在，但新的整合應在依賴特定傳輸方式前，查看最新的 MCP 文件和所選的 SDK。
傳輸選擇與沙盒網路策略解決不同的問題：
| 問題 | 傳輸方式回答 | 網路策略回答 |
|---|---|---|
| MCP 用戶端如何與伺服器通訊？ | stdio、基於 HTTP 的傳輸或其他支援的模式 | 不適用 |
| 伺服器可以呼叫哪些外部主機？ | 本身不足 | 允許清單、拒絕清單、代理、DNS 策略或無出口 |
| 伺服器能否擷取套件或網頁？ | 本身不足 | 註冊表允許清單、URL 允許清單、快取和日誌記錄 |
| 其他程序能否觸及伺服器？ | 繫結和身分驗證細節 | 入站防火牆和沙盒網路邊界 |
對於本地端 stdio 伺服器，風險通常是繼承了主機的存取權限。伺服器可能作為主機應用程式的子程序執行，並看到本地端檔案、環境變數和網路路由。如果該伺服器執行程式碼或讀取敏感檔案，請將其移至沙盒化程序，或將整個主機-工作配對執行在一個可拋棄的工作區內。
對於基於 HTTP 的 MCP 伺服器，風險轉向身分驗證、網路暴露和跨租戶隔離。使用伺服器端授權、TLS、相關的來源檢查以及每個用戶端的憑證。不要在沒有明確策略的情況下，在廣泛的內部網路上暴露一個遠端 MCP 伺服器，允許誰呼叫哪些工具。
對於網路出口，預設拒絕比預設開放更容易推理。如果一個工具需要套件安裝，請允許套件註冊表或拉取式快取。如果它需要網路研究，請透過一個記錄請求網域並封鎖內部中繼資料端點的代理進行路由。如果它需要內部 API，請暴露一個狹窄的 API，而不是整個私有網路。
套件安裝、子程序與長時間執行的狀態
許多有用的 MCP 工具需要子程序。編碼 AI 智能體會執行測試。資料 AI 智能體會安裝函式庫。瀏覽器 AI 智能體會啟動瀏覽器。建置 AI 智能體會呼叫編譯器。子程序支援本身不是問題，看不見的子程序支援才是問題。
在允許套件安裝或 shell 執行之前，請定義：
- 哪些指令是允許的、拒絕的或需要審批的。
- 套件管理員是否可以存取公開網際網路。
- 相依性版本是否需要鎖定或基於鎖定檔案。
- 建置快取和已安裝的套件存放在哪裡。
- 背景程序可以執行多長時間。
- 清理後保留哪些輸出檔案。
- AI 智能體是否可以啟動網路監聽器。
長時間執行的 MCP 伺服器引入了第二個問題：狀態漂移。一個存活數小時的伺服器可能會積累檔案、憑證、瀏覽器 cookie、shell 歷史、相依性變更和背景作業。這種狀態對於多步驟工作流程可能很有用，但它必須屬於正確的 AI 智能體、使用者和任務。
使用生命週期控制：
| 控制項 | 重要性 |
|---|---|
| 每個 AI 智能體的沙盒 ID | 防止一個 AI 智能體的工具狀態成為另一個 AI 智能體的上下文 |
| 閒置逾時 | 清理廢棄的工具工作階段 |
| 暫停與恢復策略 | 支援長時間作業，而不讓不必要的計算保持活動 |
| 快照或範本策略 | 從已知基準啟動可重複的環境 |
| 明確的拆卸 | 在作業完成後移除檔案、終止程序並釋放憑證 |
如果一個工具產生了持久構件，僅將這些構件複製出沙盒。不要保留整個工作區，除非產品明確需要完整的工作階段重播。
日誌記錄、清理與人工審核
MCP 工具日誌應回答安全性和除錯問題，而不變成一個新的機密儲存庫。有用的日誌包括工具名稱、呼叫者身分、沙盒 ID、工作區 ID、指令類別、讀取或寫入的檔案、聯絡的外部域名、安裝的套件名稱、退出狀態和構件路徑。
預設不要在日誌中記錄原始提示、原始客戶資料、Token、完整檔案內容或完整指令輸出。將敏感追蹤內容保留在更嚴格的存取控制和保留策略之後。
即使在沙盒內，某些 MCP 動作仍應保留人工審核：
- 發布或部署到生產環境。
- 發送電子郵件、聊天、工單、發票或面向客戶的訊息。
- 修改存取控制、帳務、使用者資料或基礎設施配置。
- 匯出大型檔案、私有儲存庫、資料庫匯出或類似憑證的字串。
- 在工作區策略之外執行指令。
- 使用寫入權限呼叫內部 API。
沙盒應減少爆炸半徑。它不應成為從敏感業務動作中移除審核的理由。
Novita Agent Sandbox 如何適用
Novita Agent Sandbox 是為需要程式碼執行、檔案、程序、瀏覽器風格工作流程和長時間執行工作階段的隔離執行階段的 AI 智能體工作負載而設計。它可以適用於 MCP 架構，其中工具伺服器需要一個可拋棄的工作區，而不是直接存取開發者筆記型電腦、生產主機或共享的 CI 機器。
將其用作需要以下條件的伺服器的執行階段邊界：
- 執行生成的程式碼或指令。
- 處理暫存檔案和生成的構件。
- 在多步驟任務中保持每個 AI 智能體的工作區狀態。
- 執行 AI 智能體稍後可以檢查的背景工作。
- 將 AI 智能體的實驗與應用程式主機分離。
保持產品邊界清晰：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 伺服器連接到自主或半自主 AI 智能體之前，請使用此檢查清單：
| 領域 | 需要回答的問題 |
|---|---|
| 工具範圍 | 伺服器公開了哪些工具，哪些工具會改變外部狀態？ |
| 部署位置 | 伺服器應該在 AI 智能體沙盒內、獨立的沙盒內，還是在沙盒外透過狹窄的 API？ |
| 檔案系統 | 哪些目錄被掛載，它們是唯讀還是讀寫，以及如何阻止路徑跳脫？ |
| 機密 | 注入了哪些憑證，如何限定它們的範圍，以及它們可能出現在日誌或輸出中的哪裡？ |
| 網路 | 出口是預設拒絕、經由代理路由，還是按域名、註冊表和內部 API 列入允許清單？ |
| 子程序 | 允許哪些指令、套件管理員、背景作業和監聽器？ |
| 狀態 | 如何處理每個 AI 智能體的工作區、快照、閒置逾時、暫停/恢復行為和清理？ |
| 日誌 | 您能否在不儲存機密的情況下重建工具呼叫、檔案變更、外部域名和構件？ |
| 人工審核 | 哪些工具呼叫在執行、匯出、部署或面向客戶的動作之前需要審批？ |
| 測試 | 您是否測試過提示注入、符號連結/路徑遍歷、大型輸出、清理失敗和被拒絕的出口路徑？ |
MCP 讓工具整合變得更容易。沙盒化可防止這種整合變成模型權限的悄然擴展。正確的設計通常是混合的：一些伺服器在相同的 AI 智能體工作區內，一些在獨立的沙盒中，還有一些在沙盒外，透過具有嚴格授權的 API。選擇與工具的資料、機密、子程序和網路需求相匹配的部署位置。
常見問題
是否每個 MCP 伺服器都應該在沙盒中執行？
不是。優先處理執行程式碼、讀寫檔案、使用機密、呼叫私有服務、啟動瀏覽器、安裝套件或改變外部狀態的伺服器。較低風險的唯讀伺服器可能仍需要身分驗證、日誌記錄和網路控制，但它們可能不需要每個請求都有專用沙盒。
對於 MCP 伺服器，stdio 比 HTTP 更安全嗎？
不一定。Stdio 對於本地端伺服器可能很簡單，但伺服器可能繼承本地端的檔案系統、環境和網路存取。基於 HTTP 的伺服器需要更強的身分驗證和暴露控制。更安全的選擇取決於程序的執行位置以及它獲得的執行階段權限。
MCP roots 可以取代檔案系統沙盒化嗎？
不能。Roots 有助於溝通用戶端與伺服器之間預期的工作區位置，但它們不是完整的執行階段邊界。使用路徑驗證和沙盒層級的檔案系統控制，以將伺服器保持在預期的工作區內。
沙盒化 MCP 工具的機密應儲存在哪裡？
僅注入工具需要的憑證，最好是作為短期環境變數或限定範圍的執行階段機密。不要掛載廣泛的開發者憑證資料夾，也不要透過提示傳遞機密。將它們從日誌和工具回應中遮罩。
MCP 工具何時需要人工審批？
對於生產部署、面向客戶的訊息、帳務或存取控制變更、大量資料匯出、基礎設施寫入，以及任何在工作區常規策略之外的指令或網路動作，都需要審批。
