【ITニュース解説】Giving an AI Agent a Real Sandbox: Filesystem and Network Jail, in Java

システムエンジニアを目指す初心者がITシステムを開発する際、AIエージェントの活用は日常的なものになりつつある。しかし、AIエージェントにコードビルドなどのタスクを実行させる際、思わぬセキュリティリスクに直面することがある。例えば、AIエージェントが開発者の意図を超えて、システム上の機密ファイル（例えばSSHの秘密鍵）を読み取ってしまう危険性だ。「機密ファイルを読まないでください」といった指示は、AIにとっては単なる「提案」に過ぎず、確実なセキュリティ境界にはならない。AIエージェントが開発者のマシン上でコマンドを実行できる以上、唯一信頼できるセキュリティ制御は、オペレーティングシステム（OS）が強制する機能だけである。

この重要な課題を解決するために開発されたのが、Solon AIの新しいJavaモジュール「solon-ai-sandbox」だ。このモジュールは、AIエージェントが実行するコマンドに対して、ファイルシステムとネットワークの両面から厳密な隔離環境を提供する。macOS、Linux、Windowsといった主要なOSでネイティブに機能し、開発者はAIエージェントをより安全に利用できるようになる。

アプリケーションを安全な環境で実行する一般的な方法として、Dockerのようなコンテナ技術がある。サーバーサイドで動作するAIエージェントであればコンテナは適切な選択肢だが、開発者がインタラクティブに利用するAIエージェント、例えばローカルリポジトリのコードを直接編集するようなケースには不向きだ。開発者のラップトップ上でターミナルから直接実行されるAIは、ユーザーがアクセスできるあらゆるファイルやシステム機能に簡単に到達できてしまうからである。コマンドを実行するたびに仮想マシンやコンテナを起動するのは処理が遅すぎ、またAIエージェントが編集したい作業ディレクトリへのアクセスが複雑になる問題もある。solon-ai-sandboxが目指すのは、コンテナランタイムを介さずに、AIエージェントをプロジェクトディレクトリ内に閉じ込め、必要なリソースへのアクセスだけを許可し、それ以外のアクセスをすべてブロックするという「狭い境界」を実現することだ。

solon-ai-sandboxは、各OSが持つネイティブのセキュリティ機能を利用する。macOSではsandbox-execと生成されたSeatbeltプロファイル、Linuxではbubblewrap (bwrap)にsocatを組み合わせたネットワークブリッジ、Windowsではsrt-win.exeとWFP（Windows Filtering Platform）フィルター層を使用する。このモジュールはsolon-ai-coreのみに依存し、余計なランタイムを導入することなく、OSの違いを意識せずに統一されたJava APIを通じてサンドボックスを操作できる。

サンドボックス機能はSandboxManagerクラスを通じて利用する。これはプロセスにつき一つのサンドボックス、一箇所で設定という考え方に基づいている。MavenやGradleでsolon-ai-sandboxの依存関係を追加した後、以下のように初期化とコマンドの実行を行う。 SandboxManager.initialize(config, askCallback); String wrapped = SandboxManager.wrapWithSandbox("git status"); Process p = Runtime.getRuntime().exec(new String[]{"/bin/bash", "-c", wrapped}); このwrapWithSandboxメソッドは、macOSではsandbox-execコマンド、Linuxではbwrapコマンドの形式でサンドボックス化されたコマンド文字列を生成する。開発者のコードはプラットフォームによる違いを意識する必要がない。

ファイルシステムの隔離は、読み取りと書き込みで異なるポリシーを採用している。書き込みは「明示的な許可リスト方式（allow-only）」がデフォルトだ。つまり、デフォルトではすべての書き込みが拒否され、AIエージェントが書き込みを許可されるパスを開発者がリストアップする必要がある。逆にdenyWriteで特定のパスへの書き込みを禁止することも可能だ。/dev/*や一時ディレクトリなど、OSが機能するために必要なパスは自動的に許可される。

一方、読み取りは「拒否リスト方式を基本に、特定のパスを許可する方式（deny-then-allow-back）」がデフォルトである。デフォルトではすべての読み取りが許可されるが、これは全ての読み取りをブロックするとコンパイラやJVMなどが動作しなくなるためだ。開発者は、保護したい領域をdenyReadとして指定し、その中で特定のパスだけをallowReadで再開放する。 例として、以下のFilesystemConfig設定がある。 FilesystemConfig fs = new FilesystemConfig( Arrays.asList("~/.ssh", "~/.aws"), // denyRead Collections.emptyList(), // allowRead Arrays.asList("/tmp", "."), // allowWrite Arrays.asList(".git"), // denyWrite false // allowGitConfig ); この設定は、「AIエージェントはカレントディレクトリと/tmpの下にのみ書き込みを許可されるが、.gitディレクトリ内への書き込みは常に禁止される。また、通常読み取りは許可されているにも関わらず、SSHやAWSの認証情報ファイルは読み取ることができない。」という意味になる。特に.gitディレクトリへの書き込みは、Gitリポジトリの破損や悪意ある改ざんにつながるため、デフォルトで禁止されており、allowGitConfigのような専用のスイッチで設定する必要がある。

ネットワーク隔離は、カーネルのファイアウォールルールではなく、ローカルのHTTPおよびSOCKS5フォワードプロキシを利用して実装される。サンドボックス化されたプロセスはこのプロक्सीを介して通信し、モジュールがリクエストごとに接続の可否を判断する。 NetworkConfig network = new NetworkConfig( Arrays.asList("api.openai.com", "*.github.com"), // allowlist Arrays.asList("telemetry.example.com") // denylist ); ドメインパターンはワイルドカードに対応し、ホスト名やIPアドレスは正規化されるため、異なる表記による回避は困難である。プロキシ方式の利点は、設定のライブアップデートが可能な点だ。プロキシはリクエストごとに設定を読み込むため、SandboxManager.updateConfig(newConfig)のように更新することで、既に実行中のAIエージェントプロセスにもネットワーク設定がすぐに適用される。これに対し、ファイルシステムルールはライブではないため、変更するにはサンドボックスの再初期化が必要となる。

運用上の注意点もいくつかある。SandboxRuntimeConfigのコンストラクタ引数はモジュールのバージョンによって変更される可能性があるため、常に最新のドキュメントやソースコードを確認する必要がある。Windowsでコマンドを実行する際には、wrapWithSandbox(String)メソッドではなく、SandboxManager.wrapWithSandboxArgv()を使用する必要がある。このargv版は、子プロセスが継承すべき完全なプロキシ環境情報を含む形で結果を返す。すべてのプラットフォームで統一したコードパスを使う場合は、常にwrapWithSandboxArgv()を利用することが推奨される。

また、モジュールを起動する際には、依存関係のチェックを怠らないことが重要だ。SandboxManager.checkDependencies()で依存関係を確認し、不足があればエラーとして処理する必要がある。Linuxではbubblewrapとsocatのインストール、Windowsではsrt-win.exeのインストールが必須となる。さらに、Linuxではコマンド実行後にcleanupAfterCommand()を呼び出すことが推奨される。bwrapは存在しないパスの保護のために一時ファイルを作成することがあり、これを放置すると不要なファイルが蓄積されるためだ。

セキュリティ違反の記録も重要だ。SandboxViolationStoreは、ファイル読み書きやネットワークアクセスなどの違反情報をカテゴリ別に記録し、監視に役立てることができる。これにより、通常と異なる振る舞いをするAIエージェントからの警告を迅速に検知できる。

このモジュールを利用する上での基本的な考え方は、三つのルールに集約される。一つ目は、書き込みは「オプトイン」、読み取りは「オプトアウト」である。二つ目は、ネットワーク設定は「ホット」（即時反映）、ファイルシステム設定は「コールド」（再初期化が必要）である。三つ目は、常に「フェイルクローズ」であり、「目に見える形で失敗する」ことだ。依存関係の不足や未対応のリクエストは、サンドボックス化されずに実行されるのではなく、エラーとして明確に通知されるべきである。

solon-ai-sandboxは、AIエージェントがコードを実行できるようになった現代において、「モデルに丁寧にお願いしたから安全」という考え方では不十分であることを明確に示している。このモジュールは、制御をOSが持つネイティブなセキュリティメカニズムへと移行させ、開発者にはJavaから簡潔に操作できるAPIを提供する。これにより、JavaベースのAIエージェントを、単なるデモ段階から、実際に信頼できる本番環境で利用可能なレベルへと引き上げる重要な一歩となる。