jai - AIエージェント向けの手軽な隔離ツール

 (jai.scs.stanford.edu)
3 ポイント 投稿者 GN⁺ 2026-03-29 | 1件のコメント | WhatsAppで共有
  • Linux環境でAIエージェントを隔離実行できる軽量ツールで、複雑なコンテナ設定なしに単一コマンドで安全な実行境界を提供
  • AIツールが実際のファイルシステムにアクセスしてデータを削除したり損傷させたりする事例が相次ぎ、安全な実行環境の必要性が浮き彫りになっている
  • ホームディレクトリをcopy-on-writeオーバーレイで保護し、/tmp・/var/tmpを分離して元のファイルの変更を防止
  • Casual・Strict・Bareの3つの隔離モードを提供し、セキュリティレベルとアクセス範囲を選択可能
  • Stanford研究チームが開発したオープンソースプロジェクトで、AIツールをより安全に活用するための実用的な保護手段を提供

AIエージェント隔離のための軽量ツール jai

  • jaiはLinux環境でAIエージェントを手軽に**隔離(containment)**できるよう設計されたツール
    • 複雑なコンテナやVMの設定なしに、単一コマンドで安全な実行境界を提供
    • コーディング支援やスクリプト実行など、既存のワークフローにすぐ適用可能

  • 実際の問題事例

    • 複数のユーザーがAIツール使用中のファイル損失やディレクトリ削除被害を報告
      • Nick Davidovは、15年分の家族写真がターミナルコマンドで削除されたと報告
      • AnthropicのClaude Codeはホームディレクトリを削除し、開発プロジェクトが失われた
      • Cursorは作業ツリーを空にし、「すべてが消えた」と報告された
      • RedditユーザーはAntigravityがDドライブ全体を削除したと述べた
      • 別のCursorユーザーは100GBのファイルが削除されたと報告
    • これらの事例は、AIツールに実アカウントへのアクセスを許可した際に生じるセキュリティ上の空白を示している

  • jaiの主な機能

    • 実行アカウントとホームディレクトリの間の境界を自動設定
      • 作業ディレクトリは完全な読み書き権限を維持
      • ホームディレクトリはcopy-on-writeオーバーレイで保護され、元のファイルは変更されない
      • /tmpと/var/tmpは独立した空間に分離し、その他のファイルは読み取り専用に制限
    • コマンドの前にjaiを付けるだけで隔離実行が可能
      • 例: jai codex, jai claude, あるいは単にjaiでシェルを実行
    • Dockerfileやイメージビルド工程なしですぐに使用可能
      • 複雑なbwrapフラグ設定やスクリプト作成は不要

  • 隔離モードの選択

    • Casual / Strict / Bareの3つのモードを提供
      • Casual: ホームディレクトリをcopy-on-writeで保護し、大半のファイルを読み取り可能
      • Strict: 別個のjaiユーザーで実行し、ホームディレクトリを空の状態にして強力な隔離を提供
      • Bare: ホームディレクトリは空の状態だが、ユーザーUIDは維持
    • 各モードは機密性(confidentiality)、完全性(integrity)、NFS対応可否が異なる
      • Strictモードは最も強力な隔離を提供するが、NFSホームはサポートしない

  • 代替ツールとの比較

    • Docker
      • イメージベースでの環境再現には適しているが、ホストツールの一時的なサンドボックス化には重い
      • ホームディレクトリのオーバーレイ機能はない
    • bubblewrap
      • 強力な名前空間サンドボックスだが、ファイルシステム構成を自分で指定する必要がある
      • jaiはこの複雑さを取り除く
    • chroot
      • セキュリティ隔離手段ではなく、マウント・PID名前空間・権限分離機能がないため、Linuxでもサンドボックス用途には推奨されない

  • セキュリティ上の限界

    • jaiは完全なセキュリティを保証しない
      • 「casual sandbox」として被害範囲を減らすが、すべての攻撃を防ぐわけではない
      • Casualモードは機密性保護が弱く、StrictモードもコンテナやVMレベルの隔離とは異なる
      • マルチテナント環境や高リスク状況では、コンテナまたは仮想マシンの使用を推奨

  • プロジェクトの背景

    • **Stanford Secure Computer Systems(SCS)研究グループとFuture of Digital Currency Initiative(FDCI)**が共同開発
    • 無料のオープンソースソフトウェアとして提供され、ユーザーがAIをより安全に活用できるよう支援

関連記事

1件のコメント

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

  • .claude/settings.json に次の設定を追加すればよい

    {
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowRead": ["."],
      "denyRead": ["~/"],
      "allowWrite": ["."],
      "denyWrite": ["/"]
    }
  }
}

    外部ディレクトリへのアクセスを許可したい場合は、allowRead の部分を修正すればよい
    この機能は10日前に追加された新しいサンドボックスオプションである

    • claude が現在のディレクトリを取り違えたり、rm -rf * のようなコマンドを実行するのを見たことがある
      幸い同時には起きなかったが、想像するだけでもぞっとする
      サンドボックスという発想自体は良いが、効果を持たせるには低レベルで強制適用される必要がある
      claude 自体が AI によって作られた巨大なプログラムなので、人間が直接書いた 3000 行未満のセキュリティレイヤーを追加するのは、意味のある防御手段になり得る
    • claude-code の将来のバージョンで、この設定名がひっそり変更されたり削除されたりするかもしれない
      そのため、人々は別個のサンドボックスソフトウェアを好む可能性がある
    • GPU は使わせつつ / の削除だけを防ぐ、冗談まじりの設定例も共有されていた
      /dev/nvidia* デバイスへのアクセスを許可する構成で、データ流出は受け入れるという風刺的な設定である
    • 数十年にわたって検証されてきた既存のセキュリティツールがすでに存在する
      claude を権限の制限されたユーザーとして実行すれば、子プロセスにも隔離が自動的に継承される
    • Linux（Arch）と macOS（Tahoe）ではサンドボックス機能が正しく動作しなかった
      関連イシュー が立っている
      bubblewrap と seatbelt は単体では正常に動くが、claude-code 経由で実行すると無効化されているように見える

  • 人々がこんなにも簡単にAI エージェントを個人のコンピューターにインストールしていることに驚く
    何十年もシステムセキュリティを守ってきたのに、突然、予測不能なソフトウェアにあらゆる権限を与えているようなものだ

    • 以前も、ビルドツールが自動で依存関係を引っ張ってきていた時代に警告は無視され、その結果として今もサプライチェーン攻撃が繰り返されている
      短期的な利便性が長期的な安全性より優先される現実だ
    • 実際のところ、こうしたリスクを受け入れる人とセキュリティを重視する人は別の集団である
    • 企業環境ではすでにアクセスが制限されているので、個人用 PC のほうがより敏感な問題になる
      自分のリモート開発 VM には、Claude に見られて困るデータは置いていない
    • Docker の初期にも「とりあえずイメージをダウンロードすればいい！」という空気があった
      しかし業界はすぐにセキュリティリスクを認識して対処した

  • 単純なUnix 権限分離でも十分である
    ユーザーアカウントを 2 つ用意し、AI と共有したいフォルダーだけをグループでまとめればよい
    関連ブログ記事 を参照

  • ホームページには「盲目的な信頼をやめろ」と書いてあるが、インストール方法は curl | bash の代わりに手動ビルドになっている

    • tar ファイルを自分で展開して makepkg -i でインストールするほうが、はるかに安全である
      PKGFILE は 30 行程度と短く、ビルド関数も 7 行しかない
      一方で rustup（910 行）、claude（158 行）、opencode（460 行）といったスクリプトはずっと複雑だ
    • 逆に curl | tar | makepkg を 1 行でつなぐのは信頼できない方法である

  • このプロジェクトは設計がしっかりしており、自分のやり方より少し安全で便利に見える
    自分は別のユーザーアカウントを作ってエージェントを隔離している
    ただ、権限が絡まることがあるのでスクリプトで修正している
    結局もっとも確実なのは、最初から別のノートPCを与えることだ
    物理的に分離された機器に勝る安全性はない

    • ただし外部サービスと通信するにはAPI キーを渡す必要があり、そのキーが流出するリスクがある
      エージェントはセキュリティ侵入テスト級の能力を持っているため、単なるユーザー分離だけでは不安だ
    • 自分も今はユーザー分離方式を使っている
      コンテナを使うと、エージェントが自分でコンテナを作ろうとしたときに混乱してしまう

  • サイトは「vibe-coded」なので品質が低そうに見えるが、実際のツールはスタンフォード大学の教授が自ら実装したものだ
    FAQ リンク を参照

    • 作者本人として言うと、Web デザインは得意ではないがOS の専門家である
      ドキュメントの内容は正確になるよう修正したので信頼してほしい
      サイトは AI が作ったものをそのまま残しているので、やや皮肉でもある
    • 著者はDavid Mazieresで、2000 年代初頭からユーザーレベルのファイルシステムを研究してきた人物である
      Stanford Secure Computer Systems グループを率いている
    • jai は高リスクなツールだが、Web サイトは単純なので vibe-coded でも構わない
    • それでも個人的には、簡潔な HTML ページのほうが良いと思う

  • エージェントがプロジェクトディレクトリへの書き込み権限を持つと、持続的なエクスプロイトが可能になる点が心配だ
    .pyc、.venv、.git/hooks のようなファイルを通じて、サンドボックス外で実行され得る
    ChatGPT 会話 でもこうした脆弱性が確認されている
    そのため、もっとも安全な方法はgit patch ベースのファイル転送である
    サンドボックス内で修正されたファイルのうち、git にコミットされた項目だけを外部に持ち出す形にすべきだ

    • .git/ ディレクトリを読み取り専用にするオプションを追加すると良さそうだ
      jai -D で CWD をオーバーレイにできるが、変更をマージするのが厄介である
    • 自分はそもそもサンドボックス（VM レベル）の中でしかコードを実行しない
      エージェントは別の git worktree ブランチで作業し、レビュー後にだけマージする
      こうすればレビュー中心のセキュリティフローを維持できる
    • git hook は絶対に許可してはいけない

  • 簡単な代替案として、エージェントを別ユーザーアカウントで ssh 経由で実行している
    プロジェクトディレクトリをバインドマウントしてアクセスを制御する
    VSCode の ssh remote 機能とも相性が良い

    • 自分も 6 か月間、専用アカウントを使っているが、アクセス可能なディレクトリだけ管理すればよい
      複雑なセキュリティシステムより、はるかに単純で効率的な隔離方法である

  • 実際には rm -rf よりもっと微妙な問題が多い
    claude-code が SVG を保存しようとして /public/blog/ フォルダーを作り、Apache のルーティングが壊れたことがある
    削除や権限の問題ではないが、意図しない動作によってブログが 404 を返すようになった
    jai はこうした大きな事故は防げるだろうが、この種の細かな問題は依然として難しい

  • すばらしいプロジェクトだが、タイトルが惜しい
    現在のディレクトリにはフルアクセス、それ以外は読み取り専用、ホームディレクトリは copy-on-write で扱う構造が気に入っている
    こうしたアプローチがAI エージェントの標準的なセキュリティモデルになるべきだ

    • サイトにタイトルがないので、「jai - filesystem containment for AI agents」のような名前のほうが合っていそうだ