AIエージェントのサンドボックスとは？生成コードを本番環境から隔離する
AIエージェントにコードを生成させ、その場で実行できるようにすると、調査、データ加工、テスト、ファイル作成を自動化しやすくなる。一方で、生成されたコードは入力ファイルだけでなく、実行環境から見える秘密情報、ネットワーク、プロセスにも触れられる可能性がある。
そこで必要になるのがサンドボックスである。サンドボックスとは、生成コードを隔離された環境で動かし、事故や攻撃が起きたときの影響範囲を小さくする仕組みだ。ただし、サンドボックスがあるだけでコードが安全になるわけではない。何を見せ、どこへ接続させ、どれだけ資源を使わせ、何を外へ持ち出せるかを明示的に制限する必要がある。
まずコード実行が本当に必要かを判断する
単純な検索、決まった形式への変換、既知のAPI呼び出しだけで目的を達成できるなら、用途を限定した道具を用意する方が安全である。任意コード実行は柔軟だが、その分だけ検討する攻撃面が増える。
コード実行を許可する場合も、エージェントへ万能な端末を渡すのではなく、仕事に必要な能力だけを提供する。サンドボックスは安全性の証明ではなく、侵害された場合の影響を抑える境界として扱う。
制御面と実行面を分ける
システム全体は、エージェントを制御する部分と、生成コードを実行する部分に分ける。
制御面には、利用者の認証、課金、承認、監査ログ、実行環境の作成と破棄を置く。実行面であるサンドボックスには、作業に必要なファイル、コマンド、ライブラリだけを置く。この分離によって、生成コードが実行環境を乗っ取っても、利用者管理や監査記録まで変更されにくくなる。
外部サービスを操作する道具もサンドボックスの外側で認可する。サンドボックス内の隔離が強くても、エージェントが制限なしの送金APIや管理APIを呼べるなら、大きな副作用を止められないからだ。
利用者や仕事ごとに新しい環境を作る
信頼できない利用者同士で同じ作業空間を共有してはいけない。前の仕事のファイル、環境変数、履歴、実行中プロセスが次の仕事から見えると、情報漏えいや攻撃の持続につながる。
基本は、仕事ごとに新しい環境を作り、終了後に破棄する設計である。継続作業のためにスナップショットを使う場合は、秘密情報や悪意ある変更まで保存される可能性を考える。保存期間を決め、疑わしい環境は再開せず、清潔な基盤から作り直す。
異なる利用者の処理を強く隔離する必要がある場合、同じホストのコンテナだけで十分とは限らない。コンテナはホストのカーネルを共有するため、脅威と影響の大きさに応じて仮想マシンやマイクロVMも選択肢にする。
ファイルは必要なものだけを見せる
作業空間は空の状態から始め、必要な入力だけをマウントする。入力を変更する必要がなければ読み取り専用にし、成果物を置く出力先を別にする。
次のようなものは、原則としてサンドボックスへ見せない。
- ホストのホームディレクトリ
- SSH鍵やSSHエージェントのソケット
- クラウドの資格情報やメタデータサービス
- Dockerソケット
- 他の利用者の作業ディレクトリ
- ホスト全体のファイルシステム
成果物を外へ出すときも、そのまま公開しない。対象ファイルを明示的に選び、容量、形式、シンボリックリンク、不審な実行ファイルなどを検査してから受け渡す。
ネットワークは既定で閉じる
外部ネットワークを自由に使えると、秘密情報の送信、攻撃用データの取得、内部サービスへの探索が可能になる。通信は既定で拒否し、仕事に必要な接続先だけを許可する。
許可リストは広いカテゴリではなく、可能な限り正確なドメインや宛先で管理する。リダイレクトや名前解決を経由して許可外へ到達できないことも確認する。パッケージの導入が必要なら、承認済みのレジストリや社内ミラーを使い、導入段階と実行段階のネットワーク権限を分けるとよい。
任意のURLをエージェントへ渡せる機能では、内部IP、クラウドのメタデータ、管理画面への接続を防ぐ。表面的なドメイン判定だけに頼らず、実際の接続先まで検証する。
秘密情報を環境変数へ直接置かない
生成コードは、サンドボックス内から読める環境変数やファイルを読み取れると考えるべきである。アプリケーション本体のAPIキーや長期資格情報を実行環境へ直接渡してはいけない。
外部サービスへの接続が必要なら、資格情報をサンドボックス外の仲介サービスに保持する。仲介サービスが、許可された宛先と操作だけに短期資格情報を付与する設計にする。資格情報には最小権限を与え、用途、利用者、実行時間を限定する。
実行環境へ接続するための専用キーが必要な場合も、他のAPI操作を認可できない専用資格情報として分離する。
OS権限と資源量を制限する
生成コードは権限のない利用者として実行する。root権限、特権コンテナ、ホストのPID名前空間やネットワーク名前空間、Dockerソケットを与えない。不要なLinux capabilityを落とし、seccomp、AppArmor、SELinuxなどの制限も脅威に応じて利用する。
さらに、次の資源へ上限を設定する。
- CPU時間と実行時間
- メモリ量
- プロセス数とスレッド数
- ディスク容量とファイル数
- 単一ファイルと標準出力の大きさ
- ネットワーク帯域と接続数
- 待受ポート数
これにより、無限ループ、fork bomb、大量出力、ディスク枯渇などが他の処理へ波及するのを防ぐ。上限到達時は処理を確実に停止し、環境を回収できるようにする。
依存関係も攻撃面になる
エージェントが自由にパッケージを導入できると、名前の取り違え、悪意ある更新、依存関係の乗っ取りが起きやすくなる。利用するバージョンを固定し、承認済みの取得元を使い、基盤イメージと依存関係を定期的に検査する。
毎回その場で未知のパッケージを導入するより、よく使う依存関係を検証済みの基盤へ組み込む方が再現性も高い。更新時は清潔な基盤から再構築し、過去の作業環境を使い回さない。
監査記録はサンドボックスの外へ残す
問題を追跡するには、実行したコマンド、終了コード、資源使用量、通信先、変更されたファイル、外へ出した成果物を記録する。ただし、入力本文や秘密情報を無差別にログへ残すと、監査基盤自体が漏えい源になる。
記録は目的に必要な範囲へ絞り、機密値を伏せる。監査ログは生成コードが変更できない場所へ保存し、実行ID、利用者、承認、成果物を結び付ける。
サンドボックスの失敗を試験する
正常なコードが動くことだけでは不十分である。次のような失敗を定期的に試す。
- ホストや別利用者のファイルを読めないか
- 環境変数や資格情報を持ち出せないか
- 許可外のネットワークへ接続できないか
- CPU、メモリ、ディスク、プロセスを枯渇させられないか
- 終了後にプロセスやファイルが残らないか
- 再開した環境へ攻撃を持続できないか
- シンボリックリンクや特殊ファイルを成果物として持ち出せないか
- 勝手にポートを公開できないか
重要なのは、攻撃を完全に見抜けるかではなく、検出できないコードが動いても被害を限定できるかである。制限に失敗したときは安全側で停止し、環境を確実に破棄する。
まとめ
AIエージェントのサンドボックスは、生成コードを隔離し、事故や攻撃の影響範囲を抑える仕組みである。安全に運用するには、制御面と実行面を分け、仕事ごとに新しい環境を用意し、ファイル、ネットワーク、秘密情報、OS権限、資源量を必要最小限へ制限する必要がある。
また、サンドボックスの外にある道具やAPIにも別の認可が必要だ。監査記録を外部へ残し、脱出、資源枯渇、残留データ、成果物の持ち出しを継続的に試験することで、生成コードを本番環境へ直結させない設計になる。