【ITニュース解説】Your sandbox says what the agent could do. What did it do?

システムを自動的に動かすプログラム、通称「エージェント」が、サンドボックスと呼ばれる安全な隔離環境の中で作業を行う際、そのエージェントが「何をする許可があったか」だけでなく、「実際に何を行ったか」を正確に把握することは非常に重要である。サンドボックスは、エージェントがアクセスできるファイルやネットワークなどの「ルール」（境界声明）を定義し、システムを予期せぬ変更から保護する役割を果たす。しかし、エージェントがそのルールに従って作業を行ったとしても、具体的にどのファイルを変更したり、作成したり、削除したりしたか、という「実際の行動」（変更声明）については、サンドボックス自身は通常教えてくれない。例えば、エージェントが書き込みを許可されたディレクトリ内に存在する重要なデプロイスクリプトを書き換えたとしても、サンドボックスのルールは破られていないため、何の警告も発されない。しかし、この変更はシステム運用上、大きな問題を引き起こす可能性がある。

この「エージェントが何をしたか」を知るために、作業後に手動でgit statusやfind -newerといったコマンドを使って変更を探す方法が考えられる。しかし、これらの方法はいくつかの問題点を抱えている。第一に、これらのコマンドはエージェントがアクセスできた環境で、エージェントの作業後に人間が実行するため、その結果がエージェントによる変更の決定的な証拠とはなりにくい。エージェント自身が、これらの結果を生成するツールや環境を改ざんする可能性もゼロではない。第二に、これらの結果には誰からの署名もなく、後から改ざんされたり、その信頼性を疑われたりする可能性がある。第三に、そして重要な点だが、これらの単純な前後比較では、すべての変更を正確に把握できない場合がある。

なぜなら、変更を検出するためのスナップショット取得や比較処理自体が完璧ではないからである。例えば、エージェントが作業中に特定のディレクトリが何らかの理由で読み取れなくなったとする。この場合、単純な比較ツールは、そのディレクトリが「消滅した」と誤解し、その配下にあるファイルすべてが「削除された」と誤って報告する可能性がある。これは誤報となる。さらに悪いケースとして、その読み取れないディレクトリを単にスキップしてしまい、「何も変更がなかった」と報告してしまうことも考えられる。しかし、「何も変更がなかった」という報告は、システム運用者が最も聞きたい情報であると同時に、実際にシステムに破壊的な変更を加えたエージェントが最も聞かせたい情報でもある。同様に、作業中にファイルシステム上のマウントポイントが変更されたり、パスがシンボリックリンクに置き換えられたり、あるいは対象のファイルツリーが膨大すぎてすべてのファイルを正確に走査できなかったりといった状況も発生しうる。これらの状況では、ツールが情報を完全に取得できなかったにもかかわらず、「異常なし」と誤った安全宣言をしてしまう可能性がある。

このような問題を防ぐため、変更記録を生成するツールは、何かを見ることができなかった部分があった場合、その事実を正直に「不完全である」と明示し、その理由も記録する必要がある。不完全な記録であっても、それは「何が見られたか」の真の証拠として価値を持つが、完全な記録として偽ってはいけない。

この課題に対し、「Pipelock 3.6」というツールが具体的な解決策を提供している。Pipelockは、エージェントの起動前に、エージェントにアクセスが許可された各ワークスペースについて「マニフェスト」と呼ばれる目録を作成する。このマニフェストには、各ファイルのパス、種類（ファイルかディレクトリか）、サイズ、最終変更日時、そして特定のサイズ（デフォルトで10MiB）以下の通常ファイルについてはSHA256というハッシュ値（ファイルの同一性を保証する「指紋」のようなもの）が記録される。エージェントが正常終了するか否かに関わらず、Pipelockはエージェントの終了後に再度同様のマニフェストを作成し、起動前のマニフェストと比較する。この比較結果に基づき、追加されたパス、削除されたパス、変更されたパスのリストと、それぞれの総数を記載した「workspace-change-statement.json」という変更声明ファイルが生成される。このファイルには、比較に用いられたサイズやハッシュ値自体は含まれない。

さらに重要なのは、この変更声明ファイルが、エージェント起動前のシステムの状態（ポスチャーカプセル）を署名したのと同じキーで署名されることである。この署名キーはエージェントのセッション中に変更できないように固定されているため、変更声明の信頼性が担保される。Pipelockは、この変更声明とポスチャーカプセルを検証する機能も持ち、異なるセッションの記録とのペア検証も可能だ。また、比較処理中に何か問題が発生した場合、例えば、読み取れないファイルやディレクトリがあった場合、別のマウントポイントに属するパスが見つかった場合、リスト作成時と読み取り時でパスの種類が入れ替わった場合などには、その対象と配下のサブツリーを記録から除外し、その数をカウントする。そして、もし何らかの要素が除外されたり、ファイルツリーの走査が予算（制限時間やリソース）切れで完了しなかったり、あるいは許可されたルートディレクトリ自体が消失したりした場合は、変更声明に「incomplete: true」というフラグとその理由を明記し、検証はエラー終了となる。例えば、カーネルバージョンが5.8より古いシステムではマウントIDを正確に報告できないため、Pipelockは同じファイルシステム内のバインドマウントを識別できず、この場合も「不完全」としてマークし、その理由を記録する。また、デフォルトのサイズ制限（10MiB）を超えるファイルは、ハッシュ値ではなくサイズと変更日時のみで比較され、これも変更声明を「不完全」としてマークする。もしこれらの大容量ファイルに対してもコンテンツレベルの比較が必要な場合は、制限値を引き上げる必要がある。

ただし、Pipelockが提供するのはあくまで「証拠」であり、システムの「バックアップ」機能ではない。変更されたファイルのパス名はわかるが、ファイルの中身そのものは記録されないため、元に戻す（リストア）機能はない。また、これは「前後比較」であるため、エージェントがファイルを一時的に作成し、終了前に削除した場合は、記録には残らない。さらに、どのプロセスが具体的な変更を行ったかまでは特定できない。監視対象となるのは、エージェントに許可されたワークスペース内のみであり、エージェント自身のホームディレクトリや一時ファイルディレクトリ内の変更は対象外となる。そのため、重要なデータは必ず許可されたワークスペース内に配置する必要がある。もし何らかの理由で変更声明ファイルが生成できなかった場合、例えば署名キーが見つからない場合でも、エージェントのセッション自体はブロックされない。その代わり、スクリプトが認識できるような単一行のメッセージでその旨が通知される。

これらのことから、もしあなたが重要なデータへの書き込み権限を持つエージェントを運用しているならば、その作業後に以下の点を自問自答すべきである。エージェントが作業を終えた後、エージェント自身がアクセスできない安全な方法で、何が変更されたかをリストアップできるか？そのリストは、エージェントが改ざんできないような信頼できるメカニズムで署名されているか？そして、もし監視対象の一部が何らかの理由で読み取れなかった場合、その変更記録は「不完全である」と正直に教えてくれるか、それとも「何も変わらなかった」と誤って報告するか？特に、通常のファイル変更だけでなく、読み取れないディレクトリが発生した場合の挙動を実際にテストし、システムが「不完全な調査」と「変更がなかった完全な調査」を明確に区別できることを確認することが肝要である。