ハクソク

世界を動かす技術を、日本語で。

エージェントセーフハウス – macOSネイティブのサンドボックスによるローカルエージェントの保護

概要

Safehouseは、macOS向けのローカルエージェント用サンドボックス
デフォルト拒否型アクセスモデルで安全性を確保。
シェルスクリプト一つで導入、追加依存なし。
プロジェクトディレクトリのみアクセス許可、他はカーネルレベルで遮断。
エージェントの誤動作や情報漏洩を未然に防止

Safehouse: macOS向けローカルエージェントサンドボックス

  • Safehouseは、macOSネイティブなサンドボックス環境を提供
  • LLMや各種エージェントの誤動作リスクをカーネルレベルで遮断
  • デフォルト拒否型アクセスモデルを採用し、明示的許可がない限りアクセス不可
    • エージェントはユーザー権限を継承せず、Safehouseが明示的に許可したディレクトリのみアクセス可能
  • プロジェクトディレクトリ(デフォルトはGitルート)には読み書きアクセスを自動付与
  • ツールチェーンには読み取り専用アクセスを付与
  • SSH鍵、他リポジトリ、個人ファイル等はカーネルレベルで完全遮断

導入手順

  • シェルスクリプト一つで導入可能、追加依存やビルド不要
    • BashとmacOSのみで動作
  • インストール例
    • mkdir -p ~/.local/bin
      curl -fsSL https://raw.githubusercontent.com/eugene1g/agent-safehouse/main/dist/safehouse.sh -o ~/.local/bin/safehouse
      chmod +x ~/.local/bin/safehouse
      
  • 任意のエージェントをSafehouse内で実行
    • cd ~/projects/my-app
      safehouse claude --dangerously-skip-permissions
      

サンドボックスの動作検証

  • 機密情報へのアクセスはカーネルが遮断
    • 例:SSH秘密鍵の読み取り試行→Operation not permitted
      • safehouse cat ~/.ssh/id_ed25519
        
    • 他プロジェクトのリスト表示→Operation not permitted
      • safehouse ls ~/other-project
        
    • 現在のプロジェクト内操作は問題なく動作
      • safehouse ls .
        

シェル関数による自動化

  • シェル設定ファイルに関数追加で、全エージェントを自動的にSafehouse内で実行
    • 例:~/.zshrcまたは~/.bashrcに追加
      • safe() { safehouse --add-dirs-ro=~/mywork "$@"; }
        claude() { safe claude --dangerously-skip-permissions "$@"; }
        codex() { safe codex --dangerously-bypass-approvals-and-sandbox "$@"; }
        amp() { safe amp --dangerously-allow-all "$@"; }
        gemini() { NO_BROWSER=true safe gemini --yolo "$@"; }
        
  • 通常はサンドボックス内がデフォルト
  • サンドボックス外で実行したい場合はcommand claude等で関数をバイパス

特徴まとめ

  • ローカルエージェントの安全実行環境
  • 明示的なアクセス制御による誤動作・情報漏洩防止
  • 導入・運用が非常にシンプル
  • macOSユーザー向けの最適なサンドボックスソリューション

Hackerたちの意見

これはsandbox-execのラッパーみたいなもんだね。考え抜かれたプリセットがたくさんあるのはいいことだよ。sandbox-execを使うときの90%は、内部環境に必要なスコープを正しく設定することだから(残りの90%はsandbox-execの動作を理解すること)。シェルスクリプトだけなのも好きだな。プログラムをオーバーレイやコピーオンライトのセマンティクスでサンドボックス化する簡単な方法があればいいのに(もっと言えば、バインドマウントとか)。作業中にLLMエージェントが.bashrcを変更しても気にしないけど、自分の.bashrcが変更されるのだけは勘弁だな。
ありがとう、Bashを選んだのは、GoやRustのバイナリが怖いからだよ!「オーバーレイFS」についてだけど、Macでこれができればいいのにと思ってる。最も近いのは、CWDの外でエージェントを読み取り専用に制限することだけど、何回かやってるうちに、$TMPで動かさざるを得なくなっちゃった。全然同じじゃないけどね。
これがTreebeard[0]で目指してたことだよ。sandbox-exec、作業ツリー、COW/オーバーレイファイルシステム。オーバーレイファイルシステムはいいね。元のディレクトリにあるgit無視ファイルにアクセスできるから、元のファイルが変更される心配がない(COWセマンティクスのおかげで)。でも、正直言うと、全部うまく動かしてからはあまり使ってないな。[0] https://github.com/divmain/treebeard
OSSプロジェクトのAmikaに取り組んでるんだ。コーディング作業のためにローカルまたはリモートのサンドボックスをすぐに立ち上げられるようにしてる。ローカルではコピーオンライトのセマンティクスをサポートしてる(今のところ「コピーしてから書き込む」だけど…ディレクトリを一時ファイルツリーにコピーするだけ)。Gitと仲良く動くように調整してるんだ。CLIからサンドボックスを立ち上げたり、アプリのTCP/UDPポートを開放して作業を確認したり、ホストされたサンドボックスを運用してる場合は、サンドボックスのURLをチームメイトと共有したりできる。要するに、サンドボックス化されたエージェントを`git clone ...`のように簡単に実行できるようにしたいんだ。ドキュメントはまだ初期段階で、粗い部分もあるけど、今週からAmikaを使って自分の開発を進めていくつもり。フィードバック大歓迎!ちなみに、私たちもスタートアップだけど、ローカルサンドボックス管理はOSSのままにするよ。[1]: https://github.com/gofixpoint/amika
クリエイターです - こんなに早く公開されるとは思ってなかった。いくつかメモ:1. 自分のエージェントはローカルで動かしたいからこれを作ったんだ。コンテナの中でも、リモートサーバーでもなく、自分の調整したマシンで動かすのが好き。これで全エージェントをフルオートで平和に動かせる。2. そう、これはsandbox-execのポリシー生成器に過ぎないよ。個人的には、これがプロジェクトの一番のポイントだと思う - 依存関係もないし、特別な技術も、仮想化もなし。だけど、エージェントが自動更新やキーチェーン統合、画像のペーストなどで動き続けるために必要な最小限の権限を特定するのに多くの時間をかけたよ。各エージェントが必要とするものについての調査メモもあるよ。https://agent-safehouse.dev/docs/agent-investigations/(AI生成)3. プロジェクトの残りは必要なくて、ポリシービルダーだけ使って一つのsandbox-execポリシーを生成してdotfilesに入れることもできるよ。https://agent-safehouse.dev/policy-builder.html
おお、すごい! microsandboxをうまく動かそうとしてたんだけど、これは自分が実際に必要としてるものに近いね。サイトとスクリプトをちらっと見たけど、特に目立った問題は見つからなかったよ。まだドキュメントに載ってない問題とか見つけた?
これをopenclawに適応できるか考えてるんだけど。アクセス可能なマシンで動かすと、摩擦が減っていろんな使い方ができるけど、同時にコントロールや制限が難しくなるよね。
OPです。これが早すぎたらごめんね。HNでのあなたのコメントを見て知って、使い始めたんだけど(同僚もね)、その効率の良さに感動して、投稿する価値があると思ったんだ!エージェント用のサンドボックスポリシー文書は見たことあるけど、これは初めての使えるアプリだよ。今のところ、いくつかの摩擦ポイントがあったんだけど: - ホームフォルダ内の.gitconfigや.gitignoreみたいなファイルにはアクセスできなくて、ホームフォルダに読み取り専用アクセスを与えない限り、アクセスできないと思う。 - プロセスアクセスが制限されてるから、Claudeにlldbやpkillなどのローカルプロセスをデバッグするためのコマンドを実行させることができない。もっと細かいコントロールがあったらいいな。
興味深いけど… 昨年の夏(2025年7月〜8月)には、こういうサンドボックスが本当に必要だった。Claude Codeや他の初期AIモデルで何度も災害に遭ったから。最悪だったのは、Claude Codeが単一のファイルを復元するためにハードなgitリバートを行って、約1000行の開発作業が消えちゃったこと。だけど、2026年3月現在、少なくとも自分の経験では、エージェントはより信頼性が高くなってきた。claude.mdに適切なガードレールと内蔵の安全対策があって、ここ3ヶ月は大きな事故がなかった。でも、複数の安全策を重ねるのは常におすすめだよ。ソフトウェア資産は自分の資産だからね。こういうのを使うのはまだおすすめするけど、少しずつ変わってきてる。
プロンプトインジェクション攻撃は本当に存在するよ。エージェントがどれだけ優れていても、脆弱だし、自分が知らないことは知らないからね。
確かに彼らは良くなってきてるけど、「rm -rf」の0.1%の可能性があるってことは、「いつ」起こるかの問題であって、「もし」起こるかの問題じゃないよね。最近はそのルーレットをよく回してるし。Safehouseならその可能性は0%になるから、全然違うんだよね。それに、node_modules内のファイルが俺のドットファイルを中国に送る指示を注入するなんて、理論的にもあり得ないでいてほしい。
git reflogを見てみて。変更がコミットされていたら、たとえそのコミットがブランチにもう存在しなくても、ほぼ確実に復元できるはずだよ。
https://nono.sh/で遊んでるんだけど、これがサンドボックスの部分にプロキシを追加して、エージェントのスコープから認証情報を外すんだ。みんなこの点で追いつこうとしてるのがちょっと心配だし、組み込みの解決策があまり良くないのも気になる。
Appleコンテナ内でClaudeのコードを実行する方法 - ``` $ container system start $ container run -d --name myubuntu ubuntu:latest sleep infinity $ container exec myubuntu bash -c "apt-get update -qq && apt-get install -y openssh-server" $ container exec myubuntu bash -c "apt-get install -y curl && curl -fsSL https://deb.nodesource.com/setup_lts.x | bash - && apt-get install -y nodejs " $ container exec myubuntu npm install -g @anthropic-ai/claude-code $ container exec myubuntu claude --version ```
Sandvault [0](その作者はここにいるかも)は、sandbox-exeとUnixユーザーシステムというシステムサンドボックスの元祖を組み合わせた別のアプローチだよ。基本的には、エージェントに自分専用の特権のないユーザーアカウントを与えて(sudoやSSH、共有ディレクトリを通じてやり取りする)、その上にsandbox-exeを追加してシステムリソースへのアクセスをより細かく制御するって感じ。0. https://github.com/webcoyote/sandvault
これを見るのは素晴らしいね。正直、サンドボックス化が技術がその潜在能力を完全に発揮するために解決すべき主要な課題だと思ってる。早期採用者はYOLOでエージェントをネイティブに動かすだろうけど、長期的には全く通用しないし、規制の厳しい企業環境や保守的な環境では無理だよ。特に重要な操作やデータが関わるプロダクションシステムではね。課題は、これまで誰も作ったことがないような、もっと洗練されたサンドボックス化が必要だってこと。ネットワーク、ファイルシステム、実行権限から始められるけど、それ以上のものが必要だよ。例えば、エージェントにブラウザを使わせてアプリをライブ環境でテストしたり、スクリーンショットをキャプチャしてデバッグしたりする必要がある場合、従来のサンドボックスモデルでは制限できないような様々な権限を与えなきゃいけない。お金がかかるリソース(例えば、クラウドリソースを作成する)とやり取りする必要があるなら、エージェントにはクラウドコストや請求の制約を意識させる必要がある。これらすべてを実際に人々が実用的に扱えるような一貫したアプローチにまとめる必要があるんだ。
ファイルレベルのサンドボックス化は今や当たり前のことだよね。もっと難しいのは、認証情報やネットワークの問題。サンドボックス内で動いてるエージェントは、まだあなたのAWSキーやGitHubトークン、環境変数にあるものを持ってるから。俺は、ローカルデーモンがエージェントプロセスにスコープ付きの短命JWTを発行する設定を使ってるんだ。生の認証情報を渡す代わりにね。だから、混乱したエージェントが明示的に許可した以上のことをすることはできない。APIアクセスにはうまく機能してるよ。でも、君が言ったように、ファイルシステムレベルではエージェントがあなたのアカウントで50のEC2インスタンスを立ち上げるのを止めるものは何もないんだ。
> 解決済み それが解決不可能だと考えたことはある? それとも、少なくとも、能力と安全性の間にはどうしようもない緊張関係があるってこと? そして、人々は選択肢があれば常に前者を選ぶんだよね。
Nixを使ってるなら、Linux(landrun)やmacOS(sandbox-exec)で動くhttps://github.com/srid/sandnixもあるよ。
あと、俺や他の人(例えばjpeeler)が集めたさまざまなサンドボックスツールも見てみて: https://news.ycombinator.com/item?id=47102258
サンドボックス実行用のGUIを持つネイティブmacOSアプリを作ったし、ドメインごとのフィルタリングとシークレット検出機能を持つネットワークサンドボックスも作ったよ: https://multitui.com/