限時優惠

OpenAI Hosted Sandboxes 網路存取怎麼配置?2026 Agent 安全部署指南

部落格 AI Agent
2026-09-22 約 9 分鐘閱讀

這篇文章針對準備把 OpenAI Agents API 從 Demo 推向穩定執行的開發者,說明 Hosted Sandboxes 的網路、依賴、工作目錄與憑據邊界。你會得到一套從無網路、有限出口到自託管的判斷方法,以及外部 API 接入、故障排查和上線前權限收縮步驟。

本文要點

  1. 獨立開發者:準備把程式碼執行型 Agent 從 Demo 推向可重複執行的任務。
  2. AI 應用工程師:需要安裝依賴、讀寫檔案,並呼叫業務 API。
  3. 平台工程師:負責沙箱、密鑰、網路出口、日誌與稽核邊界。
OpenAI Hosted Sandboxes 網路存取怎麼配置?2026 Agent 安全部署指南
OpenAI Hosted Sandboxes 網路存取怎麼配置?2026 Agent 安全部署指南

症狀:Agent 能讀寫檔案,卻在安裝套件、呼叫 API 或連線內部服務時失敗。 最快解法:先按「無網路」設計;只有任務確實需要時才開放有限出口,若涉及私有 API、資料庫或內部服務,優先改用受控閘道或自託管環境。

官方 Sandbox Agent 指南 已將程式碼執行、檔案處理與依賴設定列為核心工作流程,但這不代表每個 Hosted Sandbox 都應直接連上整個網際網路。本文把部署問題拆成四類任務:本地檔案計算、安裝依賴、公共 API 存取,以及私有服務操作,讓你在使用 OpenAI Hosted Sandboxes 網路配置 前先決定正確的安全邊界。

這篇文章適合三類讀者:

  • 獨立開發者:準備把程式碼執行型 Agent 從 Demo 推向可重複執行的任務。
  • AI 應用工程師:需要安裝依賴、讀寫檔案,並呼叫業務 API。
  • 平台工程師:負責沙箱、密鑰、網路出口、日誌與稽核邊界。

先判斷任務需要哪一種網路邊界

你不應從「怎樣把網路打開」開始,而要先問 Agent 是否真的需要對外連線。以 OpenAI Agents API 建立的程式碼執行工作,很多其實只需要輸入檔案、固定套件和輸出產物;這類任務若開放網路,反而增加下載惡意套件、外傳資料或讀取未授權內容的風險。

任務類型建議網路狀態主要限制適合的部署路徑
本地檔案計算、格式轉換保持無網路只掛載必要工作目錄Hosted Sandbox
安裝 Python、Node.js 或系統套件啟動階段有限出口固定套件來源與版本Hosted Sandbox 或自託管
呼叫公共 API、下載公開資料允許指定出口限制網域、方法與請求頻率Hosted Sandbox,先做連線驗證
操作企業 API、資料庫或內部 webhook不直接暴露內網使用受控後端代理自託管或受控閘道
長時間執行、需要持久工作區依需求配置明確處理工作區、日誌和復原自託管或雲端工作區

判斷可採用以下條件分支:

  • 若任務只處理已上傳檔案,選無網路沙箱;不要為了「方便除錯」先開放公共出口。
  • 若任務只需要安裝固定依賴或呼叫一個公共 API,選有限出口,並把允許的網域與請求用途寫進部署設定。
  • 若任務需要讀取企業內網、資料庫或內部檔案,回退到自託管環境,或讓沙箱只能呼叫一個不暴露內網的後端代理。
  • 若任務需要長期工作區、完整網路規則或特殊系統權限,不要勉強擴大 Hosted Sandbox 權限,改評估可完整管理的雲端工作區。

官方 Agents API 介紹 說明 Agent 可組合模型、工具和工作流程;這個能力邊界不等於你的業務 API、資料庫或宿主環境會自動被安全隔離。網路策略仍然要以當前 Hosted Sandbox 開發者文件實際支援的欄位和環境狀態為準。

注意: 社群討論中的「即將支援網路白名單」或未正式公布的安全保證,不可當成目前已發布能力。設定完成後,必須用可觀察的 DNS、TLS、HTTP 回應和檔案存取結果驗證。

工作目錄與依賴配置會如何影響 Agent

網路配置不是獨立開關。工作目錄、啟動命令、套件管理器和輸入檔案位置互相牽制;其中任何一項未固定,Agent 都可能在看似成功的環境中產生不可重現的結果。

第一,工作目錄應只包含當前任務需要的檔案。不要把宿主環境的家目錄、整個專案母目錄或含有設定檔的路徑直接掛載給模型。輸入檔、暫存檔和最終產物最好分開,並明確規定 Agent 可以寫入的位置。

第二,Python、Node.js 和系統套件應在環境啟動階段安裝。把版本、來源和安裝順序寫入 setup commands 或等效初始化流程,避免模型依當下錯誤訊息臨時選擇另一個版本。官方 Sandbox Agents 文件 可作為確認 Agent 與沙箱整合方式的基礎,但具體套件來源仍應由你的部署流程鎖定。

第三,必須用最小任務驗證「真的可用」,而不是只看安裝命令回傳成功。建議依序執行:

  1. 建立乾淨的 Hosted Sandbox,確認環境狀態為可用。
  2. 檢查工作目錄,只列出預期的檔案和資料夾。
  3. 執行 Python、Node.js 版本查詢,以及一個最小匯入測試。
  4. 讀取一個測試檔、寫入暫存位置,再驗證輸出檔內容。
  5. 在需要外部連線時,測試指定網域的 DNS、TLS 和最小 HTTP 請求。
  6. 重新建立相同環境,確認依賴和結果不依賴上一個工作階段殘留內容。
配置項目應在啟動階段固定的內容觀察證據
工作目錄輸入、暫存、輸出路徑目錄清單與檔案權限
Python 依賴套件名稱、版本、來源安裝輸出與匯入測試
Node.js 依賴package manifest、鎖定檔安裝結果與最小執行
系統依賴必要命令、套件來源命令版本與退出狀態
網路出口允許網域、連接埠、用途DNS、TLS、HTTP 回應
任務產物可下載檔案和清理規則雜湊、檔案清單和下載紀錄

如果一個套件只能在任務中途下載,先問它是否真的屬於執行時需求;若答案是肯定的,應把它移到可審查的初始化流程。否則,每一次模型重試都可能得到不同版本或不同錯誤。

外部 API、資料庫與私有服務應分層接入

公共 API、企業內網、資料庫和 webhook 不是同一種風險。公共 API 主要涉及出口限制、憑據和回應內容;資料庫還涉及查詢權限、資料列範圍和長期連線;webhook 則可能把 Agent 產生的內容送入不可逆的業務流程。

較穩妥的架構是:

  1. Agent 只呼叫一個受控後端代理。
  2. 代理驗證任務身分、允許的方法和目標資源。
  3. 代理在伺服器端取得短期憑據,不把長期 API Key 傳入提示詞或工作目錄。
  4. 代理只回傳任務需要的欄位,並遮罩敏感資料。
  5. 代理記錄請求、回應狀態、操作者和任務識別碼,讓平台工程師可以追查。

對公共 API,可以採用限定網域與路徑的出口;對企業服務,則不要以「沙箱能連到內網」作為安全設計。資料庫帳戶應只允許必要的唯讀查詢,寫入操作最好改成需要人工確認或由固定後端函式執行。webhook 也應使用一次性或短時效簽章,避免模型取得可以重複觸發業務流程的長期密鑰。

接入方式沙箱可見內容建議憑據方式不應採用的做法
公共 API必要回應欄位短期 Token、網域限制把長期 Key 寫入提示詞
企業 API代理回傳的最小資料後端代取憑據直接暴露內網路由
資料庫固定查詢結果唯讀、最小資料範圍讓 Agent 取得完整連線字串
webhook代理產生的請求短效簽章、方法限制直接把管理權杖放入檔案
檔案服務任務所需檔案受限物件識別碼掛載整個共享硬碟

OpenAI 的 工具文件 可用來確認工具如何被 Agent 呼叫,但工具定義本身不會替你的業務權限模型作決策。你仍需在工具背後的服務層實作驗證、限流、欄位過濾與稽核。

FAQ:網路、依賴與密鑰的常見判斷

OpenAI Hosted Sandboxes 預設可以直接存取網際網路嗎?

不要把網際網路連線視為理所當然的預設能力。你應先依目前官方 Sandbox 文件確認環境的網路欄位與限制;在未驗證前,將 Agent 按無網路設計,只用本地檔案與已配置依賴完成測試,確實需要外部服務時再開放最小出口。

Hosted Sandbox 如何安裝 Python、Node.js 和系統依賴?

把固定版本的 Python 套件、npm 套件和必要系統套件放在環境啟動階段的 setup commands 或等效初始化流程中,並以一個最小匯入、版本查詢與實際執行測試驗證。不要讓模型在任務中自行決定套件來源或版本。

Agent 沙箱呼叫外部 API 時,應該採用哪種網路架構?

公共 API 可以透過受限出口使用,但企業內網、資料庫與 webhook 不應直接暴露給沙箱。較穩妥的做法是由受控後端代理轉發請求,採用短期憑據、允許的方法與路徑清單,並把回應資料限制在該任務真正需要的範圍。

OpenAI Hosted Sandboxes 如何避免洩露 API Key?

不要把 API Key 放進提示詞、輸入檔、工作目錄或模型可讀的日誌。改由受控服務在伺服器端注入短期憑據,限制權限、來源與有效時間;同時遮罩命令輸出、錯誤事件和下載產物中的敏感欄位,並定期檢查 Agent 是否能讀取不相關檔案。

Hosted Sandbox 網路存取失敗時,應該先檢查哪些地方?

先確認環境是否成功建立,再查看目標主機、DNS、TLS 和出口限制,接著分離依賴安裝錯誤與遠端服務故障。每次排查都應保留環境狀態、命令輸出、錯誤事件、輸入檔案版本與重試結果,避免把 Agent 的錯誤判斷誤認為網路配置問題。

Hosted Sandbox 網路失敗要按照證據排查

網路錯誤不應只交給 Agent 自己重試。你要先把問題分成環境建立、連線拒絕、DNS 或 TLS、依賴安裝,以及任務超時,再按順序保存證據。

症狀優先檢查可接受的證據常見誤判
環境建立失敗初始化設定、工作目錄、依賴命令建立事件與完整輸出以為是模型沒有遵循指令
連線被拒絕出口規則、目標連接埠、服務狀態目標、連接埠與錯誤時間只重試而不確認服務是否可用
DNS 失敗網域名稱、解析環境、拼字DNS 結果與環境識別把不存在的網域當成網路封鎖
TLS 錯誤憑證鏈、系統時間、代理設定TLS 錯誤輸出與目標憑證直接關閉憑證驗證
套件安裝失敗來源、版本、系統依賴安裝日誌與套件鎖定檔把不相容版本換成任意最新版
任務超時外部服務、檔案大小、重試策略時間線、輸入版本、請求狀態認定 Agent 一定陷入迴圈

排查時應保存環境狀態、錯誤事件、命令輸出、輸入檔案版本和產物雜湊。若同一請求在沙箱外也失敗,問題更可能是外部服務或憑據;若只有沙箱失敗,再檢查出口、DNS、TLS 和工作目錄。這種分層能把配置錯誤、服務故障與 Agent 誤判分開。

官方 Sandbox Clients 文件 可用於核對客戶端和沙箱互動方式;當 OpenAI 更新環境建立、網路欄位或自託管接入方式時,應重新核對介面名稱,不要沿用舊版範例。

經驗: 若錯誤日誌包含完整 URL、Authorization 標頭、環境變數或檔案內容,先停止擴大重試,立即遮罩並輪換憑據。可觀測性不能以洩露秘密為代價。

上線前收縮權限並保留可追查紀錄

從 Demo 走向雲端 AI Agent 生產環境時,至少要驗證以下邊界:

  • 網路出口只允許任務必要的網域、方法和連接埠。
  • 工作目錄不包含宿主環境、其他使用者或未相關專案的檔案。
  • 套件來源和版本可重建,不由模型在執行中任意變更。
  • API Key 不出現在提示詞、輸入檔、命令輸出、錯誤事件或下載產物。
  • Agent 嘗試讀取無關路徑時會被拒絕,並產生可追查事件。
  • 產物下載前會掃描敏感欄位,下載後能對應到任務識別碼與輸入版本。
  • 任務失敗時可以重新建立乾淨環境,而不是依賴上一個工作階段的殘留狀態。

你可以先建立一個「越權測試」:讓 Agent 嘗試列出工作目錄以外的路徑、讀取不存在的環境變數,以及向未列入允許清單的網域發出請求。預期結果不是「模型說自己做不到」,而是作業系統、沙箱或代理服務實際拒絕,並留下可查詢的錯誤事件。

如果你的工作需要完整自訂網路、長期工作區、固定遠端連線方式或持續執行的背景服務,雲端 Mac 或其他遠端開發環境可能比 Hosted Sandbox 更合適。這類方案的代價是你必須自行負責修補、帳戶隔離、網路規則、密鑰輪換與長期稽核;但它能提供 Hosted Sandbox 未必提供的自訂程度。你可以先參考 kvmboot 的說明中心 了解遠端環境管理方式,必要時再透過 kvmboot 聯絡頁面確認適合的工作區路徑。

依任務選擇 Hosted Sandbox、自託管或雲端工作區

任務Hosted Sandbox自託管環境雲端工作區
結構化資料清洗優先選用,保持無網路當需要內部資料庫時使用當需長期保存工作檔時使用
程式碼建置與測試適合固定依賴和短任務適合特殊系統套件適合持久專案與互動除錯
網頁抓取只在出口和目標規則清楚時使用適合自訂代理和排程適合需要瀏覽器狀態保存時使用
內部系統操作不建議直接打開內網優先使用受控網段適合完整網路和帳戶隔離需求
長任務 Agent先確認狀態、產物和逾時行為適合自行管理復原機制適合需要持久工作區的流程

部署前可以用以下清單作最後決策:

  1. 任務是否可以在完全無網路下完成?
  2. 若需要網路,能否只允許指定網域和請求用途?
  3. 私有 API、資料庫或 webhook 是否經過受控後端代理?
  4. 所有套件是否已在啟動階段固定來源與版本?
  5. 工作目錄是否只包含必要檔案?
  6. 憑據是否完全避開提示詞、檔案和模型可讀日誌?
  7. 網路錯誤、環境狀態和輸入版本是否會被保存?
  8. 任務失敗後能否用乾淨環境重現,而不是依靠人工猜測?
  9. 若需要長期工作區或完整網路控制,是否已評估自託管或雲端工作區?

若你目前的方案是直接把 API Key 放進提示詞、把整個專案掛載給 Agent,再用開放網路處理所有錯誤,真正的缺點不只是風險較高,也包括結果難以重現、權限邊界不清,以及出錯後無法分辨是沙箱、外部服務還是模型判斷造成。相較之下,租用 kvmboot 的雲端 Mac 或遠端工作區,可在需要完整自訂網路、持久工作目錄和遠端開發工具時提供更可控的環境;但若你只是執行短期、無網路的檔案任務,Hosted Sandbox 仍可能是更精簡的選擇。你可以先閱讀 kvmboot 的服務介紹,再按照本文的網路與憑據清單,判斷目前應維持托管沙箱,還是遷移到可自行管理的雲端工作區。

為您的 Agent 打造可控的遠端 Mac 執行環境

需要更完整的網路與系統控制權?使用 kvmboot 遠端 Mac,將 Agent 工作負載放在獨立的 macOS 環境中執行。

查看方案 · 首頁

MCP Server 部署位置:雲端、VPS 與本機的網路出口取捨 · AI Agent 檔案隔離:從路徑白名單到沙箱的安全實務 · 最小權限網路出口:預簽名 URL、短時憑據與 Runner 完整性校驗