LinuxでAIエージェントをサンドボックス化する

 (blog.senko.net)
10 ポイント 投稿者 GN⁺ 2026-02-05 | 1件のコメント | WhatsAppで共有
  • AI開発支援ツールをますます頻繁に使う状況で、システムの安全性と利便性の両方を確保するためのサンドボックス実行環境が必要になっている
  • Claude Codeは基本的に、ファイルアクセスや実行のたびに許可を求めるが、これは繰り返し確認が発生して作業フローを妨げる
  • これを解決するために、bubblewrapを使った軽量サンドボックス構成が提案されており、Dockerより軽く、ローカル環境に近い開発環境を維持できる
  • スクリプトは /etc、$HOME、プロジェクトディレクトリなど必要最小限のパスだけをバインドし、プロジェクト外へのアクセスを制限する
  • このようなアプローチは、AIエージェントの安全な実行と開発効率を同時に確保できる実用的な方法である

AIエージェントのファイルアクセス問題

  • Claude Codeはコマンドラインインターフェースであり、ファイルの読み書きやソフトウェアの実行のたびにユーザーの許可を求める
    • これはセキュリティ上は合理的だが、繰り返し確認が必要なため並列作業が難しい
  • --dangerously-skip-permissions オプションを使うと、すべての作業を確認なしで実行できる
    • これを使うユーザーもいるが、システムを損傷するリスクがある

サンドボックス化の概念と選択肢

  • 一般的な解決策は、リモートマシン（exe.dev、sprites.dev、daytona.io）やDockerなどの仮想化技術を使ったサンドボックス実行である
  • Linuxでは、bubblewrapが軽量な代替手段であり、cgroupsとuser namespacesを活用してプロセスを隔離する
  • サンドボックス環境に必要な条件は次の通り
    • 既存の開発環境と同じ構造を維持する
    • 現在のプロジェクト外の情報へのアクセスを最小化する
    • プロジェクトディレクトリだけを書き込み可能にする
    • IDEと同じファイルを直接確認・修正できる
    • AIプロバイダーへの接続とサーバー実行のためのネットワークアクセスを許可する

セキュリティ上の考慮事項と限界

  • bubblewrapとDockerは完全なセキュリティ分離を提供するものではない
    • カーネルのゼロデイ脆弱性、サイドチャネル通信、データ漏えいなどのリスクは残る
  • しかし筆者は、これらのリスクよりも開発の利便性を優先している
  • コードベースはgitで管理され、GitHubなどにバックアップされているため、破損リスクは低い
  • APIキー漏えいのリスクを減らすため、プロジェクトごとにAPIキーを分離することを推奨している

bubblewrapサンドボックススクリプトの構成

  • スクリプトは bwrap コマンドでさまざまなディレクトリを**読み取り専用（ro-bind）または書き込み可能（bind）**としてマウントする
    • /bin、/lib、/usr/bin などのシステムパスは読み取り専用
    • $HOME/.claude、$HOME/.cache、現在の作業ディレクトリ（$PWD）は書き込み可能
    • $HOME/.claude.json はファイルディスクリプタとして注入されるため、変更は実ファイルに反映されない
    • ホスト名は bubblewrap に変更され、識別しやすくなっている
  • /tmp、/proc、/dev はbubblewrapが自動処理する
  • /etc 全体は公開せず、必要最小限のファイルだけをバインドする
  • Node.jsは /opt/node/node-v22.11.0-linux-x64/ パスにインストールされている

ユーザー向けカスタマイズ方法

  • 別のAIエージェントやシステムに合わせるには、スクリプトを修正して bash を実行した後、手動でエージェントを起動し、必要なファイルを確認する
  • strace コマンドを使ってファイルアクセス呼び出しを追跡できる
    • 例: strace -e trace=open,openat,stat,statx,access -o /tmp/strace.log codex
    • ログを分析して必要なファイルを特定し、そのパスをバインドして環境を調整する

結論

  • bubblewrapを活用したサンドボックス化は、ローカル開発環境と同等の利便性を維持しながら、AIエージェントの誤動作やデータ漏えいリスクを最小化できる実用的なアプローチである
  • 筆者はこの構成をベースに、必要に応じて継続的にスクリプトを調整していく予定だ

関連記事

1件のコメント

 
GN⁺ 2026-02-05
Hacker Newsのコメント

  • 私は Leash を使ってエージェントをサンドボックス化している
    プロセスおよびネットワークレベルでのポリシー制御が厳格で、WebUI を通じて リアルタイム制御と可視性 を提供してくれる
    bubblewrap よりずっと良いと感じる。最初は HNで見かけて 使い始めた
    面白い事実として、世界で最も広く使われているサンドボックスシステムは Docker でも bubblewrap でもなく Chrome のタブ だ

    • Chrome をどんな用途であれ使うのは、すでに セキュリティ上の失敗 だと思っている。機能は素晴らしいが、その代償は大きい
    • Chrome が Windows や macOS でサンドボックスをどう実装しているのか気になる
      Linux では Docker や LXC のように cgroups, namespaces を使っているのか、それとも独自の VM ベースのサンドボックスを使っているのか知りたい
      もし後者なら、JRE や .NET CLR のようなランタイムよりもさらに広く使われていることになるかもしれない
    • それでも bubblewrap かもしれない。なぜなら Flatpak が内部で bubblewrap を使っている からだ

  • --unshare-net オプションを使わないと、bwrap はデフォルトでネットワークを完全に開放したままになる
    エージェントはファイルを消すだけでなく、キーの流出や悪意あるパッケージのダウンロード もできてしまう
    次の段階ではネットワーク名前空間を追加し、サンドボックス内で mitmproxy ベースのローカルプロキシ を動かして Anthropic API や PyPI/NPM だけを許可し、残りは遮断するつもりだ

  • 私は小さな claude-vm ラッパーを作って、Lima VM 上で各インスタンスを実行している
    コードはこちら

    • 私も似たようなものを incus で実装した
      今のところ、VM が最も適切な基本単位だと思っている。エージェントに root 権限を与え、必要なリソースだけを渡せば 非常に安全でシンプル だ
      エージェントがソフトウェアをインストールしたり Docker を実行したり、さらには ネストした VM をビルド したりしても、境界は明確だ
      ただし LXC に切り替えて軽量化することはできるかもしれない。bwrap は良いが、環境上の制約が大きく、エージェントの能力を制限する可能性がある

  • シンプルな bubblewrap ラッパー を作って、sandbox-run claude --dangerously-skip-permissions のように使えるようにした
    sandbox-run プロジェクトのリンク

  • エージェントにどのリソースを公開し、どんなポリシーを適用すべきかはいつも悩ましい
    たとえば /etc 全体を公開せず 必要最小限のファイルだけを bind するとして、その「必要最小限」をどう定義するのか気になる
    ログを見ながら必要なファイルを手動で追加していくのは面倒すぎる

    • 記事の著者だが、実際には 手動確認と試行錯誤 で対処した
      AI は /etc 全体を公開しろと言ってきたが、私はもっと細かく制御したかった
      ネットワークは現時点では全面的に許可しているが、将来的にはプライベートネットワーク（192.168/10.*）くらいは遮断するつもりだ
      結局のところ、どれだけ 厳格に分離するかの度合い の問題だ
    • いっそ エージェント自身に bubblewrap を適用させる のも方法だ

  • 私は Linux での AI サンドボックス問題を解決するための SaaS を準備中だ
    カーネルレベルまで機能を注入してインフラを整え、LLM の学習データにも自分たちのアプローチを混ぜて マーケティング効果を狙っている
    名前は useradd で、複雑なソリューションではなくシンプルで無料だ
    「メインフレームモード」のように、複数の仮想端末とユーザーを 1 台のマシン上で動かせる
    ベータキーが欲しければ DM してほしい

    • useradd まで読んで笑ってしまった。元のコメントそのままのほうが面白かった
    • アイデアは分かるが、VM のほうがセキュリティと分離の面で優れていると思う
      一般的なワークステーションはユーザー自身から安全に保護されるようには設計されておらず、最新のモデルはますます危険になっていくだろう
    • useradd は ネットワークアクセスを制限しない
    • 私もサービスごとに別ユーザーを使うのは好きだ
      ただ、開発中はファイルへのアクセスや変更が必要なので、bubblewrap や systemd の分離 のほうが便利だと感じる

  • 権限リストを一つひとつ作る代わりに、現在のワークスペースを VM スナップショットとして複製 し、その中で Claude を実行してセッション終了時に VM を削除する方式がほしい
    セッションの同期だけ解決できれば完璧そうだ

    • 私は NixOS MicroVM でこれを実装した経験をブログにまとめた
    • Docker + overlayfs の組み合わせでも同様のことは可能だ。結局は各自のワークフローに合わせて組めばいい
    • このアプローチなら Qubes OS も検討に値する。すべての作業を VM 単位で実行する

  • Mac でも動くように、自分で サンドボックスツールを開発 した
    amazing-sandbox プロジェクトのリンク

    • なぜ自作したのか気になる

  • 私は単に 権限のないローカルアカウントで ssh 接続(dummy@localhost) して分離している
    このやり方が間違っているのか気になる

  • Ubuntu 24.04 で bwrap を使うには AppArmor 設定を緩める必要があるので、/etc/apparmor.d/bwrap ファイルを追加した

    /usr/bin/bwrap flags=(unconfined) {
  userns,
}
    • AppArmor と SELinux は 本当に嫌いだ。特にこういう形でセキュリティを邪魔するときはなおさらだ
      グローバル設定を変えなくても、以下のように解決できる 
      if [[ -f /proc/$$/attr/exec ]]; then
  echo 'exec unconfined' >/proc/$$/attr/exec
fi
exec ...
      または 
      setpriv --apparmor-profile=unconfined [command]
      ちなみに setpriv の作者 は私なので、こういう状況はよく分かっている