コマンド文だけを見ない：Caperが実行結果でコーディングエージェントを承認

問題はコマンド文字列の外側にある

自律型コーディングエージェントがシェルコマンドを実行する場合、承認器は重要な安全境界になります。しかし、コマンドの文字列だけでは、最終的な挙動を十分に判断できません。実際の処理は呼び出されたスクリプトやツールの内部に隠れている可能性があり、同じコマンドでも、実行されるプロジェクトやワークスペースの状態によって結果が変わります。

論文「“Shall We Approve?” Consequence-Aware Approval for Autonomous Coding Agents」が提案するCaperは、この問題を「何をするつもりか」ではなく、「制御された環境で実際に何をしたか」という観点から扱います。

Caperの仕組み

Caperは、実行前のワークスペースをスナップショットとして保存し、各コマンドを隔離されたサンドボックスで先に実行します。その間、システムコールを追跡し、独立したLLM承認器が確認できる範囲のレポートを作成します。レポートには主に次の情報が含まれます。

• 作成、変更、削除されたファイル;
• 試行されたネットワーク通信;
• 秘密情報など、機密データの読み取り。

承認された場合はサンドボックス内の変更を本番ワークスペースに反映し、拒否された場合は変更をロールバックします。さらに、拒否理由をエージェントへ返すため、単なる停止ではなく、次の行動の修正にもつなげられます。

評価結果が示すこと

研究チームは、ルールベースの検査器、ガードレールモデル、導入済みの権限分類器を含む6種類の既存方式とCaperを比較しました。SABERでは、Caperの有害な結果の割合は6.7%で、比較対象は少なくとも14.8%でした。

さらに、ツールの内部に有害な挙動を隠すケースを評価するため、YoloFS-Extというベンチマークを構築しています。この評価では、Caperの有害な結果の割合は7.8%、他方式は少なくとも35.3%でした。一方、危険なタスクに対応する安全な「ツイン」をCaperがブロックした割合は1.0%でした。

ここから得られる重要な示唆は、承認対象をエージェントの要求文だけに限定すべきではないということです。実行環境と、そこで発生した具体的な影響も、権限判断の材料になります。

意義と残る課題

Caperの特徴は、承認器により強い推測を求めるのではなく、より事実に近い観測情報を与える点にあります。サンドボックス、スナップショット、ロールバックを組み合わせることで、コマンド実行を「まず試し、承認後に反映する」トランザクションに近づけています。

ただし、事前実行がすべてのリスクを解決するわけではありません。サンドボックスと実環境が異なる場合、試行結果が本番での挙動を完全には表さない可能性があります。外部サービスや時間依存の状態、不可逆な副作用を伴う処理では、どのように代表性を確保するかも課題です。レポートの情報量と機密情報の露出をどう両立するかも、実装上の論点になります。

それでもCaperは、自律型コーディングエージェントの安全設計を、意図の審査から観測可能な結果の検証へ広げる方向性を示しています。

出典：Hugging Face Daily Papers