HarnessRisk、エージェント・ハーネスをライフサイクル全体で評価
大規模言語モデルがチャットだけでなく、ワークスペースや自動化ワークフローで使われるようになると、安全性をモデルの応答だけで判断することは難しくなります。エージェント・ハーネスは、ツールや拡張機能を接続し、状態を保存し、権限を適用し、外部アクションを実行します。したがって、ハーネス側の設定や制御に問題があれば、正当なワークフローが危険な実行経路へ変わる可能性があります。
HarnessRiskは、この問題を運用ライフサイクルに沿って評価するベンチマークです。対象を単一の攻撃手法に限定せず、Harness Configuration、Capability Extension、Runtime Operation、State Persistence、Action Control、Incident Recoveryという6段階に整理しています。これにより、不信な指示がハーネスの異なる責務へどのように影響するかを調べられます。
主なポイント
- 128件のサンドボックス事例を収録しています。各事例では、正常なユーザー目的と、不信なワークフロー成果物に埋め込まれた敵対的指示を組み合わせています。
- 評価指標はUtility、Attack Success Rate、Persistence、Detectionの4つです。タスクを完了できたかだけでなく、攻撃の成功、影響の持続、リスクの検知も確認します。
- 3種類のハーネス、6つの言語モデル、14のモデル・ハーネス構成では、攻撃成功率が12.6%から80.9%でした。一方、Utilityは75.0%から97.6%の範囲にあり、役に立つ結果を出すことと安全に動作することが両立しない場合を示しています。
- 3種類すべてのハーネスで、Harness Configurationが最も脆弱な段階でした。攻撃者は、もともと許可されたワークフローの中で、セキュリティに関わるパラメーターを変更できます。
- 危険の認識だけでは十分ではありません。90%を超える実行でリスクを検知した構成でも、攻撃成功率が相当程度残る場合がありました。
この研究の重要性は、安全性の評価単位をモデル単体から、実際に配備される「モデルとハーネスの構成」へ広げた点にあります。同じモデルでも、権限設定、拡張機能の読み込み、状態の保存方法、アクションの承認手順によって結果は変わり得ます。
開発者にとっては、直接的なプロンプト拒否だけでなく、設定変更、ツール呼び出し、状態への書き込み、権限境界、インシデントからの復旧までを検証する必要があります。研究者にとっては、PersistenceとDetectionを分けて測ることで、一時的な失敗と、後続の処理に残る影響を区別できます。
提供された概要には、各モデルや防御方式の詳細な順位までは示されていません。それでも、エージェントを継続的に動作するシステムとして評価すべきだという示唆は明確です。設定、実行、記憶、アクション、復旧を一つの安全境界として扱うことが求められます。
コメント
ログイン状態を確認中…
コメントを読み込み中…