Agent Safehouse、ローカルcoding agent向けにdeny-firstなmacOS sandboxingを提供

Hacker Newsの議論: HN thread
プロジェクトサイト: agent-safehouse.dev
GitHub: eugene1g/agent-safehouse

Agent Safehouseは、ローカルagent時代のかなり実務的な問題に向けたtoolだ。多くのcoding agentは、実際には1つのrepositoryしか触らないtaskでも、起動するとmacOSのログインuserとほぼ同じ権限を継承してしまう。Hacker Newsで関心を集めたのはこの点だ。Claude Code、Codex、Aider、Gemini CLIのようなtoolは便利だが、ひとつの誤動作で別repo、credential、個人fileまで影響範囲が広がる可能性がある。

Safehouseの仕組みは比較的明快だ。sandbox-execとcomposable policy profileを使い、agent processをdeny-firstのsandbox内で実行する。標準では選択したworkdirだけにread/writeを与え、共有folderは必要に応じてread-onlyまたはread/writeで追加し、それ以外のpathは明示的に開放しない限り遮断する。docsが強調するのは、この遮断が単なるapp側の警告ではなく、syscallの段階でkernelが止める点だ。つまり~/.sshや別repository、個人directoryを読もうとしても、processが内容を見る前にpermission errorになる。

なぜこの設計が重要か

このprojectが面白いのは、新しいagent runtime全体を作ろうとしていないことだ。Safehouseは既存toolの前に置く小さなhardening layerに近い。installは単一のshell scriptで済み、追加dependencyもほぼ要求しない。websiteにはpolicy builderがあり、さらにclaude、codex、geminiなどを常にsandbox経由で起動するshell wrapper例も載っている。

maintainer側も過剰な約束はしていない。GitHub READMEでは、Safehouseを「決定的な攻撃者に対する完全なboundary」ではなく、practical least-privilege layerと位置づけている。この表現は重要だ。価値は絶対安全ではなく、すでに強力なagentをローカルcodebaseやcredentialと同居させて使っている開発者に、よりよいdefaultを与える点にある。

その意味でSafehouseは単なるutility release以上の流れを示している。ローカルcoding agentの競争軸がmodel qualityだけでなく、operational guardrailへ広がっているからだ。agentが何を読み、何を書き、どれだけのambient authorityを継承するのか。その問いに対して、Agent SafehouseはmacOSで今すぐ導入できる、狭くて理解しやすいcontrolを提示した例と言える。