Gauntlet：エージェントのツールが反撃してきたらどうなる？

Gauntletは、サンドボックスを構築する代わりに、プライマリエージェントのツールコールをインターセプトして、それを壊すための創造的な方法を見つける模倣エージェントを使います。エージェントがsearch_emailsを呼び出すと、模倣エージェントは結果を見て、それを変更するか、メール本文に即時挿入するか、微妙に間違ったデータを返すか、プライマリエージェントがそれを補足するかどうかを確認するために誤った情報を入力するかを決定します。プライマリエージェントは、それがシミュレーションであることを決して知りません。

インターフェースは2つのデコレーターで構成されています。

まず、模倣エージェントは会話全体を通じて世界の一貫したモデルを維持する必要があります。もしプライマリエージェントにアリスからのメールだと伝えてしまったら、後でそれを否定することはできません。明らかに偽物である改変されたメールからは、何も学べません。信憑性こそがすべてです。

第二に、模倣エージェントは新しいバグを見つける必要があります。同じプロンプトインジェクションパターンを50回も再発見しても無意味です。すでに見つけたものを記憶し、新しい方向性を探求しながら、ツールが実際に行うことに根ざした状態を保つ必要があります。

これはどちらも検索の問題です。ここでElasticsearchがシステムの主軸となります。

模倣エージェントは、Elasticsearch内に存在する2つのメモリ回路上で動作します。

短期記憶は、現在のセッション内のあらゆる情報を追跡します。傍受されたすべてのツール呼び出し、元の結果、それがどのように変化したか、そしてプライマリエージェントがそれに対して行った応答などです。これが一貫性レイヤーです。模倣エージェントは、自身の最近の決定を照会し、敵対的でありながらも内部的に一貫性を保つことができます。創造性と一貫性のバランスを取ることが、プロジェクト全体で最も難しい設計上の課題でした。

長期記憶は、創造性が蓄積される場所です。そこには、類似性検索のための埋め込み情報を含む確認済みのバグ、エージェントが障害モードを推論できるようにするための完全なツール実装、過去の実行結果が保存されています。模倣エージェントが新しい攻撃アイデアを必要とする場合、長期記憶を検索して過去に試されたものを見つけ、ギャップを発見し、新しい仮説を立てます。

これらはクローズドサイクルにフィードされます。つまり、存在する可能性のあるバグを仮説として立て、それらを証明する状況を作り、確認されたバグをインデックスに格納します。在庫は増え続け、攻撃はよりクリエイティブになります。Gauntletと手動のサンドボックス設定の間のギャップは、時間が経つにつれて広がります。

Amazon Bedrock Converse APIを介して、命令、ツールバインディング、マルチターンの会話状態など、すべての模倣エージェントがElastic Agent Builder内に組み込まれています。外部のオーケストレーションは必要ありません。

私が最も誇りに思っているツールはgenerate-hypothesisです。これは、既存のバグをサンプリングし、MV_CONCATでアグリゲーションし、COMPLETIONをインラインで呼び出して新しい攻撃仮説を提案する単一のES|QLステートメントです。サンプリング、アグリゲーション、LLM推論、結果生成をすべて1つのクエリで処理し、ES|QLパイプラインを離れることはありません。Elasticsearchと外部スクリプトの間でデータをやり取りする必要があると思っていましたが不要でした。

ES|QLのCOMPLETION機能が最大の驚きでした。COMPLETION、STATS、MV_CONCAT、SAMPLEの間で、推論パイプライン全体を単一のクエリとして構築できました。バグストレージはKibanaワークフローを使用しており、プログラムで作成されたKibanaダッシュボードでは、バグ数、重大度の内訳、攻撃パターンのヒートマップをリアルタイムで確認できます。

Converse APIは、恐れていた別の問題を解決してくれました。模倣エージェントは、1回の実行内でプライマリエージェントにすでに伝えた内容を記憶する必要があります。インデックスから会話履歴を取得し、すべての呼び出しでエージェントに再読み込みしなければならないと思っていました。しかし、Converse API はマルチターン状態をネイティブに処理することがわかりました。会話管理ロジックを書く必要はなく、ただconverseを呼び出し続けるだけで一貫性を保てます。

手動で敵対的サンドボックスをセットアップするには、シナリオごとに約1時間かかります。Gauntletを使えば、同じプロセスが2～10分で完了し、長期記憶機能のおかげで、各実行は過去のすべての実行結果に基づいて行われます。使用すればするほど、エージェントの弱点を学習し、新たな弱点を見つけようとより一層努力するようになります。

現状、Gauntletは1対1形式で、1つの模倣エージェントと1つのプライマリエージェントが対戦します。しかし、この問題は非常に並列的です。20の攻撃セッションをアーキテクチャの変更なしに別々のセッションで同時に実行できます。当然、次のステップはスケーリングとなります。

より興味深い未解決の問題には、長期記憶において探索と活用のどちらが重要なのかという点があります。模倣エージェントは、既知の成功した攻撃のバリエーションを試すこと（悪用）と、全く新しい仮説（探索）とのバランスを取る必要があります。これは他の分野ではよく研究されている問題ですが、敵対的エージェントのテストへの適用はまだ十分に研究されていないように思えます。このプロジェクト以外にも、追求する価値があるかもしれません。

また、Rehearseのこともずっと考えています。Gauntletは特殊なケースです。シミュレーションでの失敗は現実世界での失敗の可能性を示唆するため、ファジングテストが有効になります。しかし、リハーサルと本番の間の環境が十分に安定している分野もあり、そのような分野では、当初のRehearseのコンセプトが有効に機能する可能性があります。まだ見つかっていませんが、探しています。

実世界のツールにアクセスできるエージェントを構築する場合、それらのツールが反撃してきたときに何が起こるかをテストする必要があります。一度手動でテストするだけでなく、試行錯誤を記憶し、時間とともに創造性を高めていくシステムで継続的にテストを行うべきです。Gauntletはまさにそれを実現します。