讓 AI Agent 執行指令之前，誰來決定它能讀哪些檔案？
重點先講：Anthropic Sandbox Runtime 能限制 AI Agent 的檔案讀寫和網路連線。它使用作業系統隔離機制，適合開發者測試；Windows 仍屬 Alpha，不能當成完整安全保證。
先掌握三件事：第一，檔案讀取與寫入是兩套不同規則；第二，網路預設拒絕未允許的連線；第三，Windows 的隔離機制仍有官方列出的限制。
資料截點：2026-10-25 18:00（台北時間）
本文依據 Anthropic 官方 GitHub 倉庫、README 與公開技術說明整理。本文未實機測試，文中指令與預期結果屬官方文件說明，不代表本站已驗證所有作業系統與版本。
Anthropic Sandbox Runtime 是什麼？解決了什麼問題？
Anthropic Sandbox Runtime，簡稱 srt，是一套開源的程序沙盒工具。它可以替 AI Agent、MCP Server、終端機指令與其他程序設定執行限制，控制哪些檔案能讀、哪些位置能寫，以及哪些網路目的地可以連線。
想像一個工作情境：你請 AI 幫忙修改網頁專案。它需要讀取原始碼、寫入修改結果，有時還要下載套件。但你的電腦同時存著其他專案、私人資料及登入憑證。
如果只在提示詞裡寫「不要讀取其他資料夾」，那仍然只是對模型的要求。當程序真的開始執行指令，是否能存取檔案，還取決於底層權限。
srt 的作用，就是利用作業系統提供的隔離機制，在程序執行時加入限制。官方定位是協助建立更安全的 AI Agent 執行環境，而且不必一律依賴完整容器。
不過，這套工具目前仍標示為 Beta Research Preview，API 和設定格式可能變更。它能減少某些操作風險，但沒有承諾隔離所有可能的攻擊方式。
Sandbox Runtime 的三大核心功能是什麼？
1. 限制檔案讀取與寫入
srt 可以控制程序能夠存取哪些目錄，並區分讀取與寫入權限。
這裡有一個很容易誤會的細節：官方文件的預設檔案規則，並不是所有讀取都禁止。預設情況下，讀取通常是允許的，管理者要另外設定拒絕區域；寫入則預設不開放，必須明確加入允許的路徑。
因此，把程序放進沙盒，不代表它天然讀不到其他資料夾。如果希望某個工作只能讀取指定專案，就得明確配置讀取限制，並考慮隱藏檔案、憑證資料夾及其他敏感位置。
官方提供 allowRead、denyRead、allowWrite、denyWrite 等設定。讀取與寫入的優先順序並不完全相同，不能假設同一套規則直接套用到兩者。
2. 限制網路連線
對能操作終端機的 AI Agent 來說，限制檔案權限還不夠。如果程序能任意向外連線，就可能把已取得的資料傳送出去。
Sandbox Runtime 採用網路允許清單的思路：沒有明確允許的目的地，預設禁止連線。HTTP、HTTPS 與部分其他 TCP 流量會經過代理機制，再依設定決定是否放行。
例如，某個測試工作只需要存取套件來源與指定文件網站，就不必讓程序自由連接所有網域。
但網路隔離的有效程度仍受到平台機制與官方已知限制影響。網域白名單也不能取代對網站回應內容的檢查。
3. 利用作業系統限制程序
srt 主要依賴各平台原生或系統層級的隔離能力：
| 平台 | 主要隔離方式 | 使用前應確認 |
|---|---|---|
| macOS | Seatbelt / sandbox-exec | 檔案規則、網路代理與本機通訊限制 |
| Linux | bubblewrap 與 network namespace | bubblewrap、socat、ripgrep 等依賴 |
| Windows | 獨立本機帳戶、受限權杖、ACL 與 WFP | Alpha 限制、管理員安裝程序與帳戶權限 |
這張表說明的是官方目前文件中的技術路線，不代表不同平台具有完全相同的安全強度。
Sandbox Runtime 怎麼安裝與開始使用？
以下是根據官方 README 整理的上手流程。需要基本終端機操作能力；完全沒有程式經驗的人，先理解權限設定，比直接安裝更重要。
步驟一：確認作業系統與必要工具
首先確認電腦有可用的 Node.js 與 npm。Linux 使用者還需要依發行版確認 bubblewrap、socat、ripgrep 等依賴。
Windows 使用者要特別注意：官方已提供 Alpha 支援，但安裝涉及建立本機沙盒帳戶及設定 Windows Filtering Platform 規則，與一般只安裝 JavaScript 套件的流程不同。
步驟二：安裝官方套件
官方 README 提供以下 npm 安裝指令：
npm install -g @anthropic-ai/sandbox-runtime這是安裝說明，並非本站已執行紀錄。安裝前應核對官方倉庫、套件名稱和目前的系統需求。
步驟三：先設定權限，再執行測試指令
完成安裝後，先參考官方設定範例，建立允許讀取、允許寫入與允許連線的範圍。測試資料應使用不含機密的專用目錄。
官方文件使用下列形式示範執行命令：
srt "curl anthropic.com"命令能不能連線，取決於實際網路政策。不能把官方範例中的成功結果當成所有安裝環境的預設行為。
步驟四：確認被禁止的操作真的遭到拒絕
測試沙盒時，只確認允許操作能成功並不夠。更重要的是確認禁止操作確實會失敗。
- 在測試目錄準備可公開的樣本檔案，確認允許讀取。
- 建立另一個測試用限制區域，確認禁止讀取與寫入。
- 確認白名單內的測試網域可以連線。
- 嘗試存取白名單以外的無害測試網域，確認連線被拒絕。
- 記錄測試使用的系統版本、套件版本與權限設定，方便升級後重新驗證。
這套驗收方式是依官方隔離模型整理的測試建議，並非 Anthropic 提供的正式安全認證程序。
Sandbox Runtime 和其他隔離方案有什麼差別？
選擇沙盒工具時，要先分清楚想限制的是哪一層：單一程序、整個容器，還是完整虛擬機器。
| 方案 | 主要用途 | 工具成本 | 適合情境 |
|---|---|---|---|
| Anthropic Sandbox Runtime | 針對程序設定檔案及網路限制 | 原始碼 Apache-2.0；執行與維運另計 | AI Agent、MCP Server、終端機工作 |
| NVIDIA OpenShell | AI Agent 執行環境與政策控制 | 專案授權依官方公告，基礎設施另計 | 需要整合 Agent 執行與安全政策 |
| Docker | 容器化應用程式及其執行環境 | 產品版本與商業授權依官網 | 已有容器部署流程的開發團隊 |
| 虛擬機器 | 建立獨立客體作業系統 | 依虛擬化產品、硬體及授權而異 | 需要更明確系統隔離邊界的測試 |
比較表依各方案的公開技術定位整理，未進行相同工作負載下的效能或安全性測試。因此不能推論哪一款一定比較安全、比較快。
若目前已經使用 Docker，且有成熟的容器政策與權限管理，沒有必要只因 srt 在 GitHub Trending 出現就全面更換。若工作是直接在本機啟動 AI Agent，則 srt 的程序級限制比較貼近問題本身。
Sandbox Runtime 有哪些優點與缺點？
優點
- 可對一般程序施加檔案與網路限制，不必每項工作都建立完整容器。
- 使用作業系統隔離機制，限制範圍不只停留在提示詞。
- 可將 AI Agent 和 MCP Server 的執行權限納入管理。
- 專案公開原始碼，有利於開發者自行閱讀實作與檢查限制。
缺點
- 仍為研究預覽版，設定格式與 API 可能變動。
- 預設讀取規則必須仔細檢查，不能誤認所有敏感位置都自動禁止。
- 各作業系統的隔離方式不同，部署與除錯成本不一致。
- Windows Alpha 有官方已知限制，不能視為已完成安全驗證。
- 權限清單需要持續維護；允許過多會削弱原本的隔離效果。
Windows 版有哪些特別需要留意的風險？
官方 Windows 實作使用獨立的 srt-sandbox 本機帳戶，並透過受限權杖、檔案 ACL 與 Windows Filtering Platform 控制操作。
安裝程序可能需要系統管理員權限，也會涉及本機帳戶與檔案存取授權。這類設定會影響系統層級的權限管理，與只執行一個一般 npm 套件的風險不同。
官方也特別提醒多使用者 Windows 電腦的權限情境。不同使用者、不同版本的執行程序，以及是否正確使用受限權杖，都可能影響原本希望達成的限制。
另外，某些由其他權杖或系統服務代為建立的連線，不一定會完整受到同一組網路過濾規則涵蓋。部分以 Schannel 為基礎的程式也可能出現相容性問題。
因此，在 Windows 上評估 srt 時，應先閱讀官方 Windows Known Limitations，使用非機密測試資料，並確認安裝、帳戶授權及復原方式。對於多人共用或存有重要憑證的正式工作環境，尤其不宜直接把 Alpha 當成安全保證。
Sandbox Runtime 免費嗎？使用成本怎麼計算？
Sandbox Runtime 的原始碼採 Apache-2.0 授權。這代表它可依授權條款使用與修改，但仍須遵守相關聲明及授權義務。
不要把原始碼開源直接理解為整套 AI 工作流程完全沒有成本。
實際成本要分開看：srt 本身的工具授權、所使用 AI 模型的訂閱或 API 費用、電腦或伺服器資源，以及建立和維護隔離政策的人力成本。
本文沒有取得可用來計算單次沙盒任務成本的官方統一費率，因此不提供虛構的每次執行價格。若使用第三方 AI 模型或雲端資源，須再以個別服務的現行定價確認。
誰適合使用 Sandbox Runtime？誰不適合？
適合：已經在開發 AI Agent、操作 MCP Server、需要讓程式執行有限檔案工作，而且有能力管理系統權限的工程師或團隊。
不適合：只用網頁版聊天機器人、不讓 AI 執行本機程序、沒有能力檢查系統層級安全設定，或期待安裝後就獲得完整安全保護的使用者。
對內容創作者來說，如果 AI 只是協助撰寫文字，現階段未必需要額外建立程序沙盒。若開始讓 AI 自動讀寫專案、執行程式、整理大量資料，權限邊界才會成為必須明確處理的問題。
有哪些 Sandbox Runtime 的替代方案？
如果想研究另一套專門面向 AI Agent 的隔離架構，可以參考 NVIDIA OpenShell。本站已有相關技術介紹，適合比較兩種方案的定位。
如果團隊本來就使用容器部署，則可從 Docker 的既有安全設定開始檢查。對隔離要求更高、需要專門客體作業系統的測試，可評估虛擬機器。
這些方案也都需要正確設定。Docker 或虛擬機器本身，不會自動消除錯誤掛載、權限配置不當、憑證外洩或不可信輸入等風險。
常見問題 FAQ
Sandbox Runtime 是 Claude Code 專用嗎？
不是。官方表示它源自 Claude Code 的安全需求，但也可以作為獨立 CLI 或程式庫，限制其他程序、Agent 及 MCP Server。
安裝 Sandbox Runtime 就能防止 AI 讀取密碼嗎？
不能直接這樣保證。安全程度取決於檔案讀取限制、憑證位置、作業系統機制，以及是否存在官方已知限制。尤其要注意預設允許讀取的範圍。
Sandbox Runtime 一定要搭配 Docker 嗎？
不一定。官方設計目標之一就是不要求完整容器環境，改用不同作業系統的隔離機制。但 Linux 仍需特定系統依賴。
Windows 能使用 Sandbox Runtime 嗎？
官方已提供 Windows Alpha 支援。正式使用前必須核對目前版本、安裝需求與 Known Limitations，尤其是多使用者、權杖及網路連線限制。
Sandbox Runtime 有開源授權嗎？
有。GitHub 倉庫標示 Apache-2.0，授權條件以專案 LICENSE 原文為準。
結論：Sandbox Runtime 值得研究嗎？
如果已經讓 AI Agent 開始執行本機指令，我認為 Sandbox Runtime 最值得研究的是它對權限的處理方式：哪些檔案可以讀、哪些位置可以改，以及程式能與誰通訊。
這些問題比單純要求模型「小心操作」具體得多，也比較容易設計驗收測試。
但對正式環境而言，是否採用仍取決於作業系統、團隊維護能力和風險容忍程度。Windows Alpha 尤其需要保守評估。
真正應該檢查的是：當 AI 做出不被允許的動作時，底層系統能不能確實拒絕。這才是沙盒設定有沒有達到預期的判準。
延伸閱讀
資料來源
- Anthropic Sandbox Runtime 官方 GitHub 倉庫
- 官方 README：功能、安裝、權限模型及平台限制
- 官方 LICENSE：Apache-2.0 授權
- 官方 package.json：套件與開發資訊
- 官方 docs：技術說明文件
- 官方 Releases：版本發布紀錄
- GitHub REST API：公開倉庫資料
- NVIDIA OpenShell 官方倉庫：替代方案
- Docker 官方文件：容器安全模型
GitHub 星數補充：2026-10-25 07:19（台北時間）素材日報記錄 6,460 顆星。此為當日早班素材快照，不代表 18:00 即時數值，且星數不構成安全性或軟體品質認證。
免責聲明：本文為開源軟體資訊與技術教育內容，不構成資訊安全保證。安裝涉及系統權限的工具前，應閱讀官方最新文件，使用獨立測試環境並備妥復原措施。本文沒有執行安裝或滲透測試。
利益揭露：本文未包含交易所邀請連結或付費推廣連結。
發佈留言