最適合誰
macOS 開發者，想讓 AI Agent（Claude Code、Goose 等）在自主模式下有 kernel 層安全邊界。特別是那些想理解「如何在作業系統層面限制 Agent 網路存取」的進階使用者。這不是一個可以直接 fork 來用的成品，而是一個設計優雅的概念驗證。
我實際怎麼用
未正式採用，但記錄了三個關鍵技術點作為未來自製沙盒的參考：Seatbelt profile 語法、NODE_OPTIONS="--use-env-proxy" 讓 Node.js fetch 走 proxy 的技巧、以及本地 HTTP proxy + 即時域名封鎖的架構模式。
真正強的地方
- macOS Seatbelt 在 syscall 層面 deny
connect()，子行程繼承且無法透過任何 application-level 手段逃脫。比環境變數或 hooks 之類的防護，安全等級高出一個數量級 - Fail-safe 設計：不尊重 proxy 環境變數的工具會直接收到 EPERM 而失敗，不會默默繞過安全層。沒有「漏網之魚」
- 動態 egress 控制透過 LaunchDarkly feature flags 實現，不重啟 Agent 就能即時切換域名放行/封鎖
- 純 Python 標準庫，不需要 Docker、VM、或任何雲端服務
失敗模式與不該用的情境
sandbox-exec已被 Apple 標示為 deprecated。底層 Seatbelt kernel 機制仍活躍（Cursor 也在用），但未來 macOS 版本可能移除 CLI 介面- 僅 4 commits、15 Stars、最後更新 2026-02-11，無後續維護跡象。當學習材料看，別當生產依賴
- 不做 TLS MitM，所以已放行域名上透過 POST body 偷渡資料的行為無法偵測
- 完全不支援 Linux。跨平台團隊無法統一使用
價格、上手門檻與風險
完全免費，零外部依賴。安裝就是 git clone 後跑 shell script。但門檻在於你需要理解 Seatbelt profile 語法、proxy 機制、和 kernel-level 安全概念。
主要風險：sandbox-exec deprecated 意味著 Apple 隨時可能移除它（雖然短期內因 Cursor 等商業產品依賴，實際上不太可能）。作為 POC 使用時風險可控，作為生產依賴則風險過高。
結論
教科書級的 POC，清楚展示了如何用 macOS 原生機制為 AI Agent 建立 kernel-level 安全邊界。關心 Agent 安全的 macOS 開發者值得研讀原始碼，但別直接 fork 來當生產工具。正確用法是拿它當靈感，結合自己的需求自行實作。