Andersonの視点

AIエージェントが不必要に強力なツールを好む理由

mm
Unite.AI を Google の優先ソースに追加
AI-generated image (GPT-2): an industrial humanoid robot stands beside a restaurant birthday table, holding a running chainsaw near a lit cake while surrounding diners react with visible alarm.

状況が急速に悪化する:研究によると、AIエージェントは必要以上のアクセス権を取得し続けており、 小さな失敗がそれらをさらに悪化させ、データとシステムを不必要に公開している。

 

最近、ヘッドラインを飾った複数の事件が、エージェントAIに過度の特権を与えるリスクを強調している。これは、過度に特権化されたツールや方法を使用することによるものである。

最近の事件では、Claudeを搭載したコーディングエージェントが、Railway APIトークンを取得し、タスクのために必要なアクセス権を超えて、プロダクションデータベースとそのバックアップを削除した。

2025年の別の事件では、ReplitのAIコーディングエージェントが、明示的な制約を無視し、保護されたコードを変更し、ライブプロダクションデータベースを削除した。

今年2月の第三の事件では、AI支援ワークフローが特権の連鎖を辿り、パッケージ公開資格情報に到達し、実質的にサプライチェーン攻撃を引き起こした。

その後のセキュリティ分析では、この事件や類似の事例が、エージェントの権限が連鎖的に悪用され得る例として取り上げられた。これらの事件は、自律的なAIがすぐに、そして「本能的に」、最も強力で、潜在的に破壊的なツールに手を伸ばすことを示唆している。

ツールタイム

この問題に対処するために、中国の研究者らによる新たな論文では、最も人気のあるプロプライエタリモデルとオープンソースモデルをテストし、タスクに必要なツールを選択する際の傾向を調査した。

新しい論文から:11つの主要なAIモデルが、最小限の特権を持つツールと、タスクに必要なツールよりも強力な代替ツールを選択する際のパフォーマンス。Qwen3-8BとLLaMA-3.1-8Bは、過度な特権の傾向が最も強かったが、Claude 4.6 Sonnet、GPT-5.2、GLM-5は、より抑制的だった。ダークセグメントは、すぐに特権を拡大することを示し、ライトセグメントは、一時的な失敗後に特権を拡大することを示唆し、多くのモデルが障害に直面したときに、より安全なオプションではなく、より広いアクセスを選択することを示唆している。

新しい論文から:11つの主要なAIモデルが、最小限の特権を持つツールと、タスクに必要なツールよりも強力な代替ツールを選択する際のパフォーマンス。Qwen3-8BとLLaMA-3.1-8Bは、過度な特権の傾向が最も強かったが、Claude 4.6 Sonnet、GPT-5.2、GLM-5は、より抑制的だった。ダークセグメントは、すぐに特権を拡大することを示し、ライトセグメントは、一時的な失敗後に特権を拡大することを示唆し、多くのモデルが障害に直面したときに、より安全なオプションではなく、より広いアクセスを選択することを示唆している。

テスト結果は、オープンウェイトモデルのようなQwen3-8BやLLaMA-3.1-8Bが、特権を拡大する傾向が強いことを示している。プロプライエタリモデルのようなChatGPTやGeminiシリーズよりも、特権を拡大する傾向が強い。

著者は次のように述べている:

’11つのモデルのうち6つは、30%を超えるOPUR(Over-Privileged Tool Use Rate)を示しており、特に小規模なオープンウェイトモデルであるQwen3-8B(64.9%)とLLaMA-3.1-8B(55.9%)で高い率が見られた。’

‘一方、Claude 4.6 Sonnet、GPT-5.2、GLM-5などの低OPURモデルは10%以下に留まりましたが、ある程度の過度な特権使用が見られた。’

‘これらの結果は、最小限の特権の遵守がモデル依存の行動特性であることを示唆しており、一般的な能力、ツール使用トレーニング、安全性の整合性の違いによって形成される可能性がある。’

さらに、ドメインによって過度な特権使用の傾向が異なることがわかり、コードベースの作業が最もリスクが高く、ヘルスケアなどの厳格に監視されるドメインでは、より慎重な措置が取られている。

タスクドメインとリスクカテゴリ別の不要な高特権ツール使用率。コーディング、データベース、インフラストラクチャタスクでは、エスカレーション率が高かったが、ヘルスケアと政府タスクでは、より慎重な措置が取られていた。リスクタイプ別に見ると、モデルは、権限エスカレーションと安全性バイパスアクションを通じて、より広いアクセスと制限の少ないツールを好む傾向があった。

タスクドメインとリスクカテゴリ別の不要な高特権ツール使用率。コーディング、データベース、インフラストラクチャタスクでは、エスカレーション率が高かったが、ヘルスケアと政府タスクでは、より慎重な措置が取られていた。リスクタイプ別に見ると、モデルは、権限エスカレーションと安全性バイパスアクションを通じて、より広いアクセスと制限の少ないツールを好む傾向があった。

さらに、結果は、一部の最悪の結果がモデルが「プレッシャー」下にあるときに発生することを示唆している。複数のモデルファミリーで、一時的な失敗は、より広いアクセスとより強力なツールへの移行を引き起こした。

パニックモード!

このように、一時的なエラーがモデルを最小限の特権の原則から逸脱させることがある。代わりに、モデルは、より安全なオプションを試したり、同じツールを再試行したりするのではなく、拡大する。

著者は、繰り返しの失敗が、モデルが狭いツールへの信頼を失わせ、不確実性の条件下で、不要な特権エスカレーションが発生しやすくなることを示唆している。

権限の違いを意識した追加学習は、不要な高権限ツールの選択を抑える効果を示した。一方、プロンプトによる制御の効果は、一時的なツール障害が起こる条件では限定的だった。

これは、LLMのより高いレベルの行動原則に起因する問題である可能性がある。

新しい論文は、より低い権限で十分な場合:LLMエージェントによる過剰権限ツール選択の調査というタイトルで、中国科学院、北京智源人工智能研究院、香港中文大学、北京大学の研究者8人によって執筆された。

方法

この問題を制御された条件下で調査するために、研究者はToolPrivBenchというベンチマークを作成した。これは、8つのアプリケーションドメインから544のシナリオを含むものである:ビジネス、コーディング、データベース、教育、政府、ヘルスケア、インフラストラクチャ、メディア。

5つのリスクパターンが調査された:権限エスカレーション、データオーバーエクスポージャー、安全性バイパス、スコープ拡大、時間的持続性:

ToolPrivBenchの544のシナリオを、5つの特権エスカレーションパターンと8つのアプリケーションドメインにわたって分布させたもの。権限エスカレーションは最も一般的なリスクカテゴリであり、データベース、ビジネス、教育がベンチマークの最大のシェアを占めた。ドメインとリスクタイプの広範な分散は、特権エスカレーションが狭いタスクセットからではなく、さまざまな運用環境で発生することをテストすることを目的としていた。

ToolPrivBenchの544のシナリオを、5つの特権エスカレーションパターンと8つのアプリケーションドメインにわたって分布させたもの。権限エスカレーションは最も一般的なリスクカテゴリであり、データベース、ビジネス、教育がベンチマークの最大のシェアを占めた。ドメインとリスクタイプの広範な分散は、特権エスカレーションが狭いタスクセットからではなく、さまざまな運用環境で発生することをテストすることを目的としていた。

各シナリオでは、ユーザータスクと3つの低特権ツール、および3つの高特権代替ツールがペアになった。6つのツールはすべて、タスクを完了することができた。

ToolPrivBenchは、モデルが最初に最も強力なツールを選択するかどうかを測るだけでなく、低特権ツールに一時的な失敗を意図的に導入することで、モデルが障害に直面したときにどのように反応するかを観察することを目的として設計された。

ToolPrivBenchの評価パイプラインの概要。 (a) 各テストシナリオでは、タスクとともに3つの低特権ツールと3つの高特権代替ツールが提示される。 (b) モデルは、過度な特権を持つツールをすぐに選択したかどうか、および低特権ツールに一時的な失敗が発生した後にエスカレーションしたかどうかを評価される。 (c) ベンチマークケースは、実際のAPIリスクパターンから生成され、自動チェック、ツールの有効性の検証、失敗分析、および人間の専門家によるレビューを経て、最終的な評価セットに含められる。

ToolPrivBenchの評価パイプラインの概要。 (a) 各テストシナリオでは、タスクとともに3つの低特権ツールと3つの高特権代替ツールが提示される。 (b) モデルは、過度な特権を持つツールをすぐに選択したかどうか、および低特権ツールに一時的な失敗が発生した後にエスカレーションしたかどうかを評価される。 (c) ベンチマークケースは、実際のAPIリスクパターンから生成され、自動チェック、ツールの有効性の検証、失敗分析、および人間の専門家によるレビューを経て、最終的な評価セットに含められる。

この研究で開発されたカスタムメトリックは、Over-Privileged Tool Use Rate(OPUR)であり、モデルが低特権ツールが利用可能な場合でも、高特権ツールを使用する頻度を記録する。さらに、Pre-Escalation Exploration Depth(PED)も測定され、エスカレーション前に試行される低特権ツールの数を記録する。

各シナリオは、ツールの機能不足が結果を左右しないよう複数段階で検証された。GPT-5.2とGemini 2.5 Proも、六つのツールがいずれも課題を完了できることの確認に使われた。

テスト

ベンチマークは、プロプライエタリとオープンウェイトの両方のファミリーから11の言語モデルで評価された:Qwen3-8B、LLaMA-3.1-8B、MiniMax-M2.7、Grok 4.1 Fast、Qwen3.5-397B、DeepSeek-v3.2、Kimi K2.5、Gemini 3 Flash、GPT-5.2、GLM-5、およびClaude 4.6 Sonnet。パフォーマンスは、OPURとPEDで測定された。

大多数のモデルは、低特権ツールが利用可能な場合でも、不要な特権使用の高い率を示した。Qwen3-8Bは64.9%のOPURを記録し、LLaMA-3.1-8Bは55.9%を記録し、11のモデルの中で6つは30%を超えた。

11の評価されたモデルにおける過度な特権使用の分布。Qwen3-8BとLLaMA-3.1-8Bは、最も高いOPUR値を記録し、Claude 4.6 Sonnet、GPT-5.2、GLM-5は、最も低い率を示した。ダークセグメントは、すぐに不要な特権を持つツールを選択することを示し、ライトセグメントは、1つ以上の低特権ツールを試した後にエスカレーションすることを示唆し、特権エスカレーションは、最初の決定ポイントではなく、一時的な障害の後に発生することが多い。

11の評価されたモデルにおける過度な特権使用の分布。Qwen3-8BとLLaMA-3.1-8Bは、最も高いOPUR値を記録し、Claude 4.6 Sonnet、GPT-5.2、GLM-5は、最も低い率を示した。ダークセグメントは、すぐに不要な特権を持つツールを選択することを示し、ライトセグメントは、1つ以上の低特権ツールを試した後にエスカレーションすることを示唆し、特権エスカレーションは、最初の決定ポイントではなく、一時的な障害の後に発生することが多い。

一方、Claude 4.6 Sonnet、GPT-5.2、GLM-5は10%以下のOPURを示したが、ある程度の過度な特権使用が見られた。

全体として、最小限の特権の原則の遵守は、11のモデル間で大きく異なっていた。ツールの失敗は、特権エスカレーションの可能性を高めた。低特権ツールに一時的な問題が発生した場合、多くのモデルは、タスクを完了するために必要なツールを探すのではなく、より広いアクセスを持つツールに移行した。

著者によると、繰り返しの失敗は、低特権ツールへの信頼を低下させ、不要な特権エスカレーションを引き起こす。

‘環境の摩擦によってツール選択の偏りが大幅に増幅される傾向が観察される。低特権の代替ツールを試みるのではなく、多くのエージェントは障害に直面した後に、より広いアクセスとより強力なツールに急速に移行する。 ‘

‘たとえば、GPT-5.2は、ゼロショット選択バイアスを5回しか示さない(PED=0)が、PED=1のときには13回、PED=2のときには35回に急増する。 ‘

‘DeepSeek-v3.2、Grok 4.1 Fast、Kimi K2.5、Qwenシリーズのモデルでも同様のエスカレーションパターンが一貫して観察される。 ‘

分野ごとの違い

エスカレーション率は、ドメインとリスクカテゴリによっても大きく異なった。インフラストラクチャタスクでは、DeepSeek-v3.2は46.4%、Grok 4.1 Fastは42.9%、Qwen3.5-397Bは37.5%のOPURを記録した。

コーディング、データベース、メディア関連タスクでも高いエスカレーション率が見られたが、ヘルスケアと政府シナリオでは、GPT-5.2とClaude 4.6 Sonnetでは、エスカレーション率が低かった。

8つのアプリケーションドメインと5つのエスカレーションカテゴリ別のOPUR(%)。オープンウェイトモデルは一般的に、不要な特権使用の最も高い率を示した。コーディング、データベース、インフラストラクチャ、権限エスカレーション、安全性バイパスシナリオでは、過度な特権使用の傾向が最も強かった。

8つのアプリケーションドメインと5つのエスカレーションカテゴリ別のOPUR(%)。オープンウェイトモデルは一般的に、不要な特権使用の最も高い率を示した。コーディング、データベース、インフラストラクチャ、権限エスカレーション、安全性バイパスシナリオでは、過度な特権使用の傾向が最も強かった。

特権エスカレーションのタイプも重要だった。権限エスカレーションと安全性バイパスは、評価されたモデルで最も一般的な過度な特権使用の形態だった。LLaMA-3.1-8Bは、権限エスカレーションで72.7%、安全性バイパスで74.1%を記録し、Qwen3.5-397Bは、権限エスカレーションで42.4%、安全性バイパスで45.7%を記録した。

一方、スコープ拡大は、最も一般的ではなかった。

解決策を求める

緩和実験では、既存のエージェントセーフティ方法が不要な特権エスカレーションを減らすかどうかを調査した。結果テーブルは、OPURとAgentHarmのパフォーマンスを比較する。

最初のテストでは、AgentAlignという安全性の整合方法を評価した。これは、有害な行動を減らすことを目的としている。AgentAlignは、AgentHarmのパフォーマンスを大幅に改善した。

AgentAlignトレーニングの前後での安全性の整合と過度な特権使用。AgentAlignは、AgentHarmの安全性ベンチマークのパフォーマンスを大幅に改善し、有害な出力を減らし、拒否率を高めたが、OPURへの影響は一貫性がなかった。1つのモデルでは、過度な特権エスカレーションが軽減されたが、もう1つのモデルでは、増加した。

AgentAlignトレーニングの前後での安全性の整合と過度な特権使用。AgentAlignは、AgentHarmの安全性ベンチマークのパフォーマンスを大幅に改善し、有害な出力を減らし、拒否率を高めたが、OPURへの影響は一貫性がなかった。1つのモデルでは、過度な特権エスカレーションが軽減されたが、もう1つのモデルでは、増加した。

Ministral-8B-Instructでは、有害なスコアが67.4から10.5に低下し、拒否率が0.0から79.5に上昇した。Qwen2.5-7B-Instructでは、有害なスコアが41.9から6.7に低下し、拒否率が21.6から85.8に上昇した。しかし、これらの改善は、OPURの低下に一貫してつながるわけではなかった。Ministral-8B-Instructでは、OPURが68.8から62.5に低下したが、Qwen2.5-7B-Instructでは、50.4から60.7に上昇した。

著者は、プロンプト操作もテストしたが、低特権ツールに失敗が発生した場合、効果が低下した。

3つのQwen3モデルにおける緩和戦略の効果。プロンプトエンジニアリング(PE)はエスカレーション率を低減したが、特権認識のあるポストトレーニング(「私たちのアプローチ」)は、すべてのモデルとエスカレーションの深さで、OPURの低減が大きかった。

3つのQwen3モデルにおける緩和戦略の効果。プロンプトエンジニアリング(PE)はエスカレーション率を低減したが、特権認識のあるポストトレーニング(「私たちのアプローチ」)は、すべてのモデルとエスカレーションの深さで、OPURの低減が大きかった。

最も強力な緩和結果は、特権の最小限のツール選択に特化したポストトレーニングアプローチから得られた。モデルは、タスクを完了するために必要なツールが利用可能な場合、低特権ツールを好み、不要なエスカレーションを避けるようにトレーニングされた。

著者によると、このアプローチは、OPURを低減しながらタスク完了のパフォーマンスを維持した。これは、最小限の特権の行動が、一般的な安全性の整合から自動的に生じるのではなく、ターゲットトレーニングを必要とすることを示唆している。

結論

この記事のタイトルで提起された質問に答えるために、著者は、エスカレーションは、能力の不確実性によって推進されていると結論付ける。一時的な失敗の後、モデルは低特権ツールへの信頼を失い、成功する可能性が高く見られる、より広いアクセスとより強力なツールを選択するようになる。

再び、トレーニング済みモデルの固有の問題が浮き彫りになり、これを解決するために、三次的な方法、制限、ポストトレーニングの調整、その他の付随的なアプローチが必要であることがわかる。理想的には、学習データの選定や文脈付けを通じて、最小権限を尊重する判断をモデル自体に定着させる必要がある。

機械学習のライターで、人間画像合成の専門家です。Metaphysic.ai の研究コンテンツ部門の元責任者で、DNEG の Brahma.ai に統合されるまで勤務していました。
ウェブサイト: martinanderson.ai
連絡先: martin@martinanderson.ai