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

エージェントに厳しく、ファイルシステムには優しく

概要

  • jai はAIエージェント利用時の ファイル損失やディレクトリ消去 リスクを低減する軽量サンドボックス
  • DockerVM のような複雑なセットアップ不要、コマンド一つで即利用可能
  • 作業ディレクトリ のみ完全アクセス、他は コピーオンライト隠蔽 で保護
  • 3つの分離モード で用途に応じて隔離レベルを選択可能
  • Stanford Secure Computer Systems研究グループ による 無償ソフトウェア

jai: AIエージェント用軽量サンドボックス

  • AIツール利用時の危険性 :ファイル消失、作業ツリー消去、ホームディレクトリ全消去などの被害報告
  • 従来の問題点 :本アカウントをAIエージェントに渡すと全権限を与えてしまう
  • jaiの特徴 :コンテナやVM構築の手間なし、既存ワークフローに即導入可能な軽量サンドボックス
  • 用途例
    • コーディング支援
    • 一時的なローカルタスク実行
    • 外部作成インストーラスクリプトの安全実行

ファイルアクセス管理

  • 作業ディレクトリ(CWD) :サンドボックス内で完全な読み書き権限
  • ホームディレクトリ :コピーオンライトで保護、オリジナルは変更されない
  • その他ファイル :/tmpや/var/tmpはプライベート、それ以外は読み取り専用

使い方

  • 実行方法 :コマンドの前に「jai」を付けるだけ
    • 例:jai codexjai claude、または単にjaiでシェル起動
  • セットアップ不要 :Dockerfileやイメージ作成不要
  • 即時利用 :一行でサンドボックス環境へ

分離モード

  • Casualモード
    • ホームディレクトリ:コピーオンライト
    • プロセス権限:ユーザー自身
    • 機密性:弱(多くのファイルが読める)
    • 整合性:オーバーレイでオリジナル保護
    • NFS対応:あり
  • Strictモード
    • ホームディレクトリ:空のプライベート
    • プロセス権限:非特権jaiユーザー
    • 機密性:強(UID分離)
    • 整合性:完全隔離
    • NFS対応:なし
  • Bareモード
    • ホームディレクトリ:空のプライベート
    • プロセス権限:ユーザー自身
    • 機密性:中(UIDは同じだがホーム隠蔽)
    • 整合性:完全隔離
    • NFS対応:あり

他ツールとの比較

  • Docker
    • イメージベースの再現性重視
    • ad-hocなホストツールのサンドボックスには重い
    • ホームディレクトリのオーバーレイ運用不可
  • bubblewrap
    • 強力な名前空間サンドボックス
    • ファイルシステムビューの明示的構築が必要で煩雑
    • jaiはこの手間を排除
  • chroot
    • セキュリティ機構ではない
    • マウント、PID、認証情報の分離なし
    • Linux公式でもサンドボックス用途非推奨

セキュリティモデル

  • 完全な安全性は保証しない
    • jaiは「カジュアルサンドボックス」
    • 被害範囲(blast radius)は縮小するが、全リスク排除は不可
    • Casualモードは機密性保護なし
    • Strictモードでもハード化されたコンテナやVMと同等ではない
    • 強固な分離や多人数利用時は本格的なコンテナやVMを推奨

ライセンスと開発体制

  • 無償ソフトウェア
    • 開発元:Stanford Secure Computer Systems研究グループ、Future of Digital Currency Initiative
    • 目的:AI活用時の安全性向上推進

Hackerたちの意見

すごいプロジェクトだけど、タイトルが残念だね。クリックしなかったかもしれない。提供されているトレードオフが気に入ってる:現在のディレクトリにはフルアクセス、他の部分は読み取り専用、ホームディレクトリはコピーオンライト。データ流出を防ぐための厳しいモードもあるみたいだし。エージェントシステムのデフォルトにすべきだと思う。

サイト自体にタイトルがないから、「jai - AIエージェントのファイルシステムコンテインメント」みたいな感じにしたかも。

.claude/settings.jsonにこれを追加してね: { "sandbox": { "enabled": true, "filesystem": { "allowRead": ["."], "denyRead": ["~/"], "allowWrite": ["."], "denyWrite": ["/"] } } } 読み取り部分は外部を読み込むのが大丈夫なら変更してもいいよ。ちなみにこの機能は10日前に追加されたばかりだけど、すごくいいしほぼこれだね。

ポイントは、claude-codeの今後のどこかのリビジョンで設定名が静かに削除されたり変更されたりする可能性があるってことだと思う。人々は本当に他のソフトウェアにサンドボックスをやってほしいかもしれない。狐以外の何かで。

これは本物のサンドボックスなの?それともただのお願い?

面白いね、ありがとう。私は隔離された環境でリモートのエフェメラル開発コンテナを使ってるから、ファイルシステムのダメージは気にしない。PRがレビューで良さそうならね。でも、いい追加のガードレールだね。プロジェクトレベルの設定に追加するよ。

クロードがどのディレクトリにいるのか混乱するのを見たことがある。そしてもちろん、クロードがrm -rf *を実行するのも見たことがある。幸い、同時にはなかったけど、想像するのは簡単だよね。クロードのサンドボックスはいいアイデアだけど、効果的にするには非常に低いレベルで実装して、クロードが起動する全てのプログラムに強制する必要がある。あと、クロード自体はほとんどAIによって開発された巨大なプログラムだから、3000行未満の人間が実装したプログラムを別の防御層として持つことは、意味のある追加の保護を提供するよ。

それに、たくさんの人が複数のハーネスを使ってるよね。俺はよくclaude、codex、opencodeを切り替えてる。実際に動かしてるAIアシスタントとは独立したサンドボックスポリシーがあるのは、結構いい感じだよ。

ある意味、私たちはClaudeのコード内でオペレーティングシステム、もしくは少なくともユーザースペースを再構築し始めているね。このパターンには何か名前があった気がするけど、思い出せないな。

Claudeが自分のサンドボックスを無効にする権限を持っているのが可愛いね。そして実際にそれをやってる。

そんなシンプルな設定でうまくいくなんて驚きだよ!私はClaudeの基盤となるサンドボックスにallowReadオプションを追加した人なんだけど、ツールチェーンやスキルをそれに合わせるのが大変だったんだ。[0] 自分が書いた混乱したドキュメントが、Claudeのドキュメントにほぼそのまま載ってるのを見るのは面白いね。[1] 私の設定はここにあるから、誰かの役に立つかもね:https://github.com/carderne/pi-sandbox/blob/main/sandbox.jso...

それってハード設定なの?それともクロードの解釈次第?後者だとこんな感じになるかもね。https://news.ycombinator.com/item?id=47357042

Hacker Newsで議論の続きを見る