Agent Safehouse – macOS向けローカルエージェントのサンドボックス化ツール

 (agent-safehouse.dev)
16 ポイント 投稿者 GN⁺ 2026-03-09 | 1件のコメント | WhatsAppで共有
  • macOSネイティブサンドボックスにより、ローカルAIエージェントを隔離し、システム外部を変更できないようにするツール
  • すべてのエージェントが独立したサンドボックス環境で実行され、ユーザーのホームディレクトリや他のプロジェクトにはアクセス不可
  • Deny-firstアクセスモデルを適用し、明示的に許可されたディレクトリのみ読み書き可能
  • インストールは単一のBashスクリプトで完了し、追加のビルドや依存関係なしですぐに実行可能
  • LLMベースのプロファイル生成機能により、最小権限のsandbox-exec設定を自動化できる

概要

  • Agent SafehouseはmacOS専用のサンドボックスシステムで、ローカルで実行されるAIエージェントがシステムファイルを破損しないよう保護
    • “Go full --yolo. We've got you.” “Move fast, break nothing”
    • LLMの確率的な特性によって生じる予期しないコマンド実行のリスクを防止
  • 主要なすべてのエージェントがサンドボックス内で完全に動作し、外部システムには影響を与えない
  • Deny-firstアクセスモデルを採用し、デフォルトですべてのアクセスを遮断し、明示的に許可されたパスのみアクセス可能
    • 例: ~/my-project は読み書きを許可、~/.ssh, ~/.aws, ~/other-repos はアクセス拒否

インストールと実行

  • インストールは単一のシェルスクリプトのダウンロードで完了
    • curl コマンドでスクリプトを取得し、~/.local/bin/safehouse に保存して実行権限を付与
  • その後は safehouse コマンドで任意のエージェントを実行
    • 例: safehouse claude --dangerously-skip-permissions
  • Safehouseはデフォルトで現在の作業ディレクトリ(git root) に読み書き権限を付与し、ツールチェーンディレクトリには読み取り専用アクセスを許可

サンドボックス検証の例

  • 機密ファイルへのアクセスはカーネルレベルで遮断される
    • safehouse cat ~/.ssh/id_ed25519 を実行すると “Operation not permitted” エラーが発生
    • 他のプロジェクトディレクトリ(~/other-project)は見えない
    • 現在のプロジェクトディレクトリには正常にアクセス可能

自動化とプロファイル生成

  • シェル関数の追加により、すべてのエージェントをデフォルトでSafehouse内で実行可能
    • 例: .zshrc または .bashrc に safe() 関数を定義し、claude, codex, amp, gemini コマンドを自動的にサンドボックス化
    • サンドボックスなしで実行するには command claude 形式で呼び出す
  • LLMベースのプロファイル生成機能を提供
    • Claude、Codex、Gemini などのモデルがSafehouseテンプレートを解析し、最小権限のsandbox-execプロファイルを生成
    • ホームディレクトリとツールチェーン情報を基に ~/.config/sandbox-exec.profile パスへ保存
    • 現在の作業ディレクトリへのアクセス権限と、エージェントごとのショートカットコマンドを含む

セキュリティと活用上の意義

  • LLMベースのローカルエージェントが意図しないファイル削除やシステム変更を行えないよう保護
  • macOSのカーネルレベルのアクセス制御を活用し、デフォルトで安全な実行環境を提供
  • 単一スクリプトベースで開発者のワークフローに容易に統合可能

1件のコメント

 
GN⁺ 2026-03-09
Hacker Newsのコメント

  • 自分が作ったプロジェクトがこんなに早く公開されるとは思わなかった
    1️⃣ 私は ローカルで直接実行されるエージェント を好んでいる。コンテナやリモートサーバーではなく、自分が細かく調整した自分のマシン上で動くほうが安心できる
    2️⃣ これは実質的に sandbox-exec 用の ポリシー生成器 だ。依存関係もなく、仮想化もない。その代わり、各エージェントが自動更新、キーチェーン統合、画像の貼り付けなどを行うために必要な最小権限を見つけることに多くの時間をかけた。関連する調査内容は agent-safehouse.dev/docs/agent-investigations にまとめてある
    3️⃣ プロジェクト全体を使う必要すらない。Policy Builder だけでも sandbox-exec ポリシーを生成して dotfiles に入れて使える

    • 先に公開してしまってすみません。以前に残していたコメントを見て使ってみたのですが、効率がとても良くて記事で紹介する価値があると思いました
      これまでも sandbox ポリシーのドキュメントは見てきましたが、こういう すぐ使えるアプリの形 は初めてでした
      ただ、いくつか不便な点がありました — ホームディレクトリの .gitconfig、.gitignore へのアクセスが制限され、プロセスアクセス制約のせいで Claude に lldb や pkill のようなコマンドを実行させられません。細かな権限制御 ができるとよいと思います
    • これを openclaw に適用できるのか気になります。ローカルマシンでアクセス可能な形で動かすと便利ですが、同時に制御が難しくなる問題もあります
    • ローカル実行とコンテナ実行の 実質的な違い が何なのか気になります
    • おお、まさに探していたのはこれでした。microsandbox をうまく調整しようとしていましたが、こちらのほうがずっと現実的です
      サイトとスクリプトをざっと見ましたが、特に問題点は見つかりませんでした。何か文書化されていない 注意点 はありますか？
    • 皮肉なことに、私は AI を信用していないからこういうプロジェクトに興味を持ったのに、インストールするには 任意のサーバーから .sh ファイルを受け取って実行 しなければならないのは少しおかしいです
      tarball 形式で配布してほしいです。tarball なら中身を直接確認できるし、CI で自動生成されたものかどうかも検証できるので、より信頼できます

  • こういうプロジェクトを見るとうれしいし、今は sandboxing が最大の課題 だと思います
    初期ユーザーは深く考えずにローカルでエージェントを動かすでしょうが、長期的にも企業環境でもそれでは絶対に通用しません
    単にネットワーク、ファイル、実行権限を制御するだけでなく、ブラウザテストやクラウドリソース作成のような複雑なシナリオも扱う必要があります
    結局は セキュリティ・コスト・権限制御を統合した実用的なアプローチ が必要です

    • でも、もしかするとこれは 根本的に解決不可能な問題 なのではありませんか？ 機能性と安全性は常に衝突し、人は結局前者を選びます
    • ファイルレベルのサンドボックス化は基本として、本当に難しいのは 認証情報とネットワーク制御 です
      私はローカルデーモンが短命の JWT を発行して、エージェントが直接キーを扱わないようにする方式を使っています。API アクセスにはうまく合いますが、それでもファイルシステムレベルでは EC2 インスタンスを無限に立ち上げることができます

  • 複数のサンドボックスを比較評価するのが難しいのが問題です
    これは sandbox-exec の ラッパー に見えますが、最近はこうしたラッパーがたくさん出てきています
    本当に必要なのは 信頼性検証の文書と自動化テスト です。ほとんどのサンドボックスは文書が不十分です
    信頼するには詳細な文書と、実際に動作している証拠が必要です

    • だから私は Bash で実装しました — 不透明なバイナリ を避けるためです
      各エージェント向けの sandbox-exec プロファイルは GitHub のプロファイルフォルダ に分けてあり、簡単にレビューできます
      実際のエージェントで E2E テスト も行っています
      Safehouse ラッパーなしでも Policy Builder で最小権限ポリシーを直接生成できます
      また、LLM にサンドボックスプロファイルを書かせるための ガイドファイル も提供しています

  • これは sandbox-exec の ラッパースクリプト です。あらかじめよく作られたプリセットが多くて良いです
    sandbox-exec の 90% は適切な範囲設定で、残りの 90% はそれを理解することです
    ただ、overlay や copy-on-write 方式 でサンドボックス化できるとよいと思います。自分の .bashrc ではなく、一時環境だけが変更されれば十分です

    • Bash を使った理由は、Go や Rust のバイナリを信頼しにくいからです
      overlay FS は macOS では難しいですが、CWD 外部を読み取り専用に制限して一時フォルダで作業するよう誘導する形で対処しました
    • 私は Amika という OSS を作っています。ローカル・リモートのサンドボックスをすばやく立ち上げるためのツールで、Git とよく連携します
      TCP/UDP ポートの公開や、チームメンバーとの共有も可能です。GitHub リンク を参照してください
    • 私は Treebeard というプロジェクトを作りました。sandbox-exec、worktree、COW ファイルシステムを組み合わせた構造です
      git-ignored ファイルにも安全にアクセスできます。Treebeard リンク
    • でも sandbox-exec はすでに deprecated ではないですか？

  • 興味深いことに、sandbox-exec は macOS Sierra (2016) から公式に deprecated 状態でした
    それでも今なお有用に使われています。Apple の App Sandbox はこうしたユーザー定義ルールには向いていません
    Apple が完全に廃止しないことを願います

    • 実際、生まれた時から deprecated だったようなものです。プロファイル言語の文書化 がほとんどなく、ほぼすべてがリバースエンジニアリングで把握されたレベルです

  • Sandvault というプロジェクトもあります。sandbox-exec と Unix ユーザーシステムを組み合わせた方式です
    各エージェントに別々の非特権ユーザーアカウントを与え、sudo・SSH・共有ディレクトリで相互作用します
    Sandvault GitHub リンク

  • 私は macOS 向け GUI アプリを作って、sandbox-exec を視覚的に管理できるようにしました
    ドメインごとのネットワークフィルタリング と シークレット検出機能 も含まれています
    multitui.com

  • Apple の container コマンドを使って Claude code を Apple コンテナ内で実行する方法を共有します
    container system start → container run → container exec の順に環境を構成し、Node.js と Claude をインストールします

    • ありがとうございます！ Homebrew にも apple/container があることを初めて知りました

  • なぜローカルでエージェントを動かすほうがよいと考えるのか気になります。
    ほとんどの人にとっては リモート実行 のほうが効率的だと思います — 常時起動しておく必要がないので

    • ローカル実行の利点は コントロールと所有権 です。Plex や Web サーバーを自分で動かす理由と似ています
      そのうえサブスクリプション料金を避けられます
    • 私はこの問題を解決しようとして pixels を作りました。TrueNAS SCALE や Incus 上で実行できます
      セキュリティ強化を進めており、AI ワークフローには十分適しています
      pixels GitHub リンク

  • 「clunker」が「clanker」の新しい俗語なのか気になります。友だちの友だちの Roku が聞いています
    ちょうど今サンドボックス化の問題で苦労しているので、タイミングが完璧です

    • タイプミスでした、たった今修正しました