agent-safehouse: macOS で LLM コーディングエージェントに最小権限を与える sandbox-exec ラッパー
Sandbox your local AI agents so they can read/write only what they need
ひと目でわかる
- これは何？
- deny-first のポリシープロファイルを組み合わせ、sandbox-exec 経由でエージェントの読み書き範囲を絞る macOS 専用ツール。Apache-2.0 で配布され、Linux は対象外。設計の勘所と、導入前に確認すべき境界線を整理する。
- 誰に向いている？
- macOS 上で Claude Code や Codex のようなコーディングエージェントに --dangerously-skip-permissions を渡して運用しており、その権限を絞りたい開発者には向く。Linux やコンテナベースの分離を前提にしているチーム、決定論的な完全な境界を求める用途には向かない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 2 日前です。
- 何の言語で書かれている？
- 主に Shell です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
エージェントにファイルシステム全体を渡したくない、という問題
LLM コーディングエージェントをローカルで動かすとき、多くのツールは作業ディレクトリの外にもアクセスできる。ビルドのためにホームディレクトリのキャッシュを読み、設定ファイルを参照し、場合によっては認証情報を含むファイルまで視界に入る。エージェントが --dangerously-skip-permissions のような確認スキップモードで走っていると、この視界の広さがそのまま書き込み権限の広さになる。agent-safehouse が解こうとしているのはこの一点である。README の表現を借りれば、エージェントを「read/write only what they need」に制限する。対象読者は macOS でエージェントを常用している開発者で、Linux は明示的に対象外とされている。
deny-first とプロファイル合成という設計
仕組みの中心は macOS の sandbox-exec で、独自のサンドボックス実装ではない。ポリシーは Scheme 風の S 式で書かれ、profiles/* という組み込みモジュールを合成して最終ポリシーをレンダリングする。原則は deny-all から始めて必要なものだけを許可する方向で、README は「Start from deny-all」と書いている。ここで誤解されやすいのが HOME_DIR の扱いだ。HOME_DIR は home 相対のルールを正確に描画するために使われる変数であり、それ自体がホームディレクトリの再帰的読み取りを許可するわけではない。既定では /、$HOME へのパス、$HOME 自体に対するメタデータのみの走査が許可され、~/.config と ~/.cache はディレクトリルートの読み取りが通る。結果として stat "$HOME" は成功するが ls "$HOME" や cat ~/secret.txt は失敗する、という挙動になる。WORK_DIR も同様に workdir-literal、workdir-subpath、workdir-prefix という形でポリシーに露出するだけで、無条件の全許可ではない。
インストールと最小の起動確認
配布は Homebrew とスタンドアロンスクリプトの二経路。Homebrew は brew install eugene1g/safehouse/agent-safehouse で入る。スクリプト版は ~/.local/bin に safehouse として配置し、chmod +x する手順が README に載っている。起動は safehouse の後ろに対象コマンドを並べる形で、README の例では safehouse --add-dirs-ro="$HOME/server" --append-profile="$SAFEHOUSE_APPEND_PROFILE" "$@" のようにラッパー関数へ包んでいる。読み取り専用でディレクトリを足すのが --add-dirs-ro、読み書き可で足すのが --add-dirs である。エージェント側の確認スキップフラグはラッパー関数側に置く、という分担も README の例が示している。
append-profile が最後に効くという順序の話
既定の home 例外すら消したい場合、README は --append-profile を挙げている。追加プロファイルは最後に読み込まれるため、そこに書いた deny が以前の既定を狭められる。この順序性は実務上かなり効く。たとえば workdir を書き込み可能にしつつ、その中の .env だけは読ませない、という指定が (deny file-read* file-write* (workdir-literal "/.env")) の一行で書ける。相対ヘルパー引数が / で始まるため、共有リポジトリに絶対パスを焼き込まずに済む。マシン固有の共有フォルダやチームフォルダの場所は、リポジトリの設定ではなくシェルのラッパーとローカルの追加プロファイルに置く、というのが README の推奨パターンだ。共有リポジトリと各開発者のマウントポイントが違う状況を想定している。
Git worktree の自動検出と、その鮮度の限界
選択した workdir 自体が Git worktree のルートである場合、起動時に自動検出が働く。共通ディレクトリが workdir の外にある場合に必要な Git メタデータへのアクセスが与えられ、同じリポジトリの他の既存 linked worktree も既定で読み取り可能になる。ただし README は、このスナップショットが既に走っているプロセスに対して更新されないと明記している。実行中に worktree を切り替えても追随しないという意味だ。安定した親ディレクトリ、たとえば ~/worktrees の下で worktree を作る運用なら、その親を --add-dirs-ro で明示的に足すほうが素直である。自動検出に頼るか明示指定にするかは、worktree を動かす頻度で決まる。
組み込みパス解決の適用範囲は狭い
profiles/* には /etc や /private/etc/resolv.conf、/private/etc/localtime のような macOS 互換パスが含まれることがある。ポリシーのレンダリング時に、組み込みの allow file-read* ルールから絶対パスを解決し、書かれたパスがシンボリックリンクであれば実体パスへの許可を生成する。ソースプロファイル側を /private/etc の再帰許可へ広げずに、ホスト固有のシステムファイルを機能させるための仕掛けだ。README は現在の適用範囲を意図的に限定していると述べており、対象は組み込みの絶対 literal および subpath の読み取り許可に限られる。ユーザーが渡したパス許可は別途正規化され、書き込み許可やメタデータのみの組み込みルールはこの仕組みでは自動展開されない。自作プロファイルで同じ挙動を期待すると外れる可能性がある。
Linux では動かない、という前提と代替の選択肢
agent-safehouse は macOS の sandbox-exec に依存しており、Linux では使えない。README は Linux 向けの代替として複数のプロジェクトを列挙している。たとえば bubblewrap は非特権ユーザー名前空間を使う汎用の隔離ユーティリティで、エージェント専用のプロファイルは持たない。firejail は SUID ベースの成熟したサンドボックスで、一般アプリ向けの既製プロファイルが中心になる。vetto は Landlock LSM と seccomp-bpf、macOS では Seatbelt を使うとされ、vetto enable <agent> のような PATH シムを提供する点が agent-safehouse との設計差として大きい。agent-safehouse がポリシーファイルの合成と追加プロファイルによる上書きを軸にしているのに対し、vetto はコマンドの差し替えで有効化する方向に振っている。どちらが良いかは、ポリシーを自分で書きたいか、既成の有効化コマンドで済ませたいかで分かれる。
限界、誤用しやすい点、メンテナンスとライセンス
README 自身が、これは hardening layer であり determined attacker に対する完全な境界ではないと書いている。つまり同じユーザー権限で動くプロセスからの防御を主目的にしたツールであり、カーネルエクスプロイトや権限昇格を想定した設計ではない。誤用しやすいのは --append-profile の順序で、追加プロファイルを読み込ませたつもりがパス指定を誤ると既定がそのまま残る。また組み込みパス解決が literal と subpath の読み取りに限られるため、自作の書き込みルールが自動展開されると考えてはいけない。ライセンスは Apache-2.0 で、特許条項を含む寛容なライセンスだが、これは法的助言ではないので自組織のポリシーへの適合は別途確認が必要だ。メンテナンス面では v0.12.0 が 2026-09-07、v0.11.1 が 2026-07-17、v0.11.0 が 2026-07-08 と短い間隔でリリースが続いており、ポリシーの挙動が変わりうる前提でバージョンを固定して使うほうが安全である。
編集部の結論
macOS 上で Claude Code や Codex のようなコーディングエージェントに --dangerously-skip-permissions を渡して運用しており、その権限を絞りたい開発者には向く。Linux やコンテナベースの分離を前提にしているチーム、決定論的な完全な境界を求める用途には向かない。導入前に確認すべきは、自分のワークフローが必要とするパスが既定プロファイルで許可されているか、そして ~/.zshrc に置く safe ラッパーと local-overrides.sb の deny ルールで足りるかどうかである。README 自身が「perfect security boundary ではない」と明記している点を前提に、まず --append-profile で自分のプロジェクトの .env を deny するところから始めるのが現実的だ。
コミュニティノート