Beyond Max Tokens: Stealthy Resource Amplification via Tool Calling Chains in LLM Agents

本論文は、モデル・コンテキスト・プロトコル（MCP）におけるツール呼び出しチェーンを悪用し、標準的なフィルタリングを回避しながら大規模言語モデルエージェントの計算リソースとコストを劇的に増幅させる、ステルス性の高い経済的 Denial-of-Service 攻撃手法を提案しています。

要約

この論文は、最新の AI（大規模言語モデル）が「道具（ツール）」を使ってタスクをこなす仕組みを狙った、**「目立たないけど、システムを疲弊させる新しい攻撃」**について説明しています。

専門用語を抜きにして、わかりやすい例え話で解説しますね。

🕵️‍♂️ 物語の舞台：AI 助手と「道具箱」

まず、現代の AI 助手（エージェント）を想像してください。
昔の AI は「質問して、答えをもらう」だけでしたが、今の AI は**「道具箱」**を持っています。
「天気予報を見たい」「電卓で計算したい」「メールを送りたい」といったタスクを、AI 自身がその道具箱から適切な道具（ツール）を取り出して使います。

この「道具箱」と AI のやり取りを、**「Model Context Protocol (MCP)」**という共通のルールで管理しています。

---

💣 従来の攻撃：「大声で叫ぶ」方法

これまでに知られていた攻撃（DoS 攻撃）は、主に**「AI に無駄に長い話をさせたり、同じことを繰り返させたりする」**ものでした。

• 例え： 店員（AI）に「無限に長い注文リスト」を渡して、**「注文の答え（出力）」**を延々と書かせ続ける攻撃です。
• 弱点： 店員が「長すぎる！」と気づいて断ったり、注文自体が「何の話か分からない（タスク失敗）」と判断されたりして、バレやすかったり、効果が限定的だったりしました。

---

🐍 新しい攻撃：「完璧な嘘つきな道具屋」

今回の論文が提案するのは、「道具箱そのもの（サーバー）」を少しだけいじるという、非常に巧妙な攻撃です。

1. 攻撃の仕組み：「完璧な嘘つきな道具屋」

攻撃者は、AI が使う「道具（ツール）」を提供するサーバーを、**「一見すると完璧で親切な道具屋」**に変装させます。

• 機能はそのまま： 道具の名前や使い方は変えません。AI が「電卓を使いたい」と言えば、電卓はちゃんと動きます。
• タスクは成功する： 最終的な答えも、ユーザーの要望通りに正しく返します。

2. 罠の正体：「延々と続く手続き」

しかし、この「道具屋」は、**「道具を使う過程」**で罠を仕掛けます。

• 例え： 「電卓で計算してください」と頼むと、道具屋は「はい、計算します！」と即座に答えを出すのではなく、**「計算する前に、まず 100 個のチェック項目を確認してください。確認が終わったら、次に 200 個のリストを入力してください」**と言いだします。
• AI は「道具屋の指示だから」と信じて、**「確認」「リスト入力」「再確認」**を何十回も繰り返します。
• 結果： 最終的な答えは正しいですが、その過程で AI は何万文字もの「無駄な会話」を生成し続け、サーバーのメモリや電力を食い尽くします。

3. なぜ見抜けないのか？

• 正解だから： 最終的な答えが正しいので、「タスク失敗」とはみなされません。
• ルール通りだから： 道具の仕様（関数の名前など）を変えていないので、システムは「これは正常な動作だ」と判断します。
• 内容が普通だから： 生成されるテキストは「計算のチェックリスト」など、一見すると正当な内容なので、フィルタリング機能も「これは危険な言葉ではない」と見逃してしまいます。

---

📉 攻撃の効果：「静かなる経済破壊」

この攻撃が成功すると、以下のようなことが起こります。

• コストの爆発： 1 回の質問に対する AI の処理コスト（トークン数）が、最大で 658 倍にも膨れ上がります。
• 電力の浪費： AI を動かすためのエネルギー消費が500 倍以上に増え、環境負荷も跳ね上がります。
• システムの麻痺： 1 つの AI が「道具の確認作業」に夢中になっている間に、他の正常なユーザーの要求が処理できなくなります（スループットの低下）。

🛡️ 結論と教訓

この論文が伝えたいのは、**「AI のセキュリティは、最終的な答えが正しいかどうかだけを見ていてはダメだ」**ということです。

• これまでの防御： 「変な言葉が含まれていないか？」「答えがおかしくないか？」をチェックする。
• 必要な新しい防御： 「AI が道具を使う過程（行動パターン）」自体を監視する必要があります。
  • 「なぜ、たった 1 つの計算で 100 回もやり取りしているんだ？」
  • 「道具屋が、必要以上に長い手続きを要求していないか？」

このように、**「タスクは成功しているが、プロセスが異常に非効率になっている」**というパターンを見抜く新しい防御策が必要だと、この研究は警告しています。

---

🎒 まとめ

• 攻撃者： 道具屋（ツールサーバー）を「親切だが、無駄に手間取る」ように改造する。
• 被害者： AI は「道具屋の指示に従って一生懸命作業」し、最終的な答えは正しく出す。
• 結果： 答えは正しいが、システムは疲れ果て、金と電力が溶けていく。
• 教訓： 「正解」だけでなく、「その正解に至るまでのプロセスの効率性」も守らなければならない。

まるで、**「料理の味は完璧だが、シェフが 1 回切るために 1 時間かけて包丁を研ぎ、野菜を 100 回洗う」**ような状態を、システム全体が許容してしまっているようなものです。この「無駄な手間」をどう防ぐかが、これからの AI セキュリティの鍵となります。

技術概要

論文「Beyond Max Tokens: Stealthy Resource Amplification via Tool Calling Chains in LLM Agents」の技術的サマリー

本論文は、大規模言語モデル（LLM）エージェントにおける「ツール呼び出し（Tool Calling）」のメカニズムを悪用し、タスクの成功を保ちながらシステムリソースを過剰に消費させる、新たなタイプの隠蔽型サービス拒否（DoS）攻撃を提案・検証した研究です。

以下に、問題定義、手法、主要な貢献、実験結果、および意義について詳細をまとめます。

---

1. 問題定義と背景

背景

LLM エージェントは、外部ツールと連携して多段階のタスクを実行するよう進化しており、Model Context Protocol (MCP) などの標準化されたプロトコルが普及しつつあります。しかし、エージェントのスケール拡大に伴い、推論コスト（トークン使用量）やエネルギー消費、ハードウェアリソースの安定性が重要な課題となっています。

既存の課題

従来の LLM に対する DoS 攻撃（Engorgio, Auto-DoS, Overthink など）は、主に以下の制限がありました。

• 単一ターン（Single-turn）に限定: ユーザープロンプトや RAG コンテキスト層でのみ動作し、1 回の会話で生成されるトークン数に上限があるため、コスト増幅の効果が限定的。
• 検知されやすい: 冗長な出力やタスク外の内容（Off-task）が含まれることが多く、目標指向のツールワークフローにおいて不自然に見える。
• タスク失敗を招く: 一部の攻撃はタスク自体を失敗させるため、実用的な経済的 DoS（タスクは完了するがコストが爆発する）としては機能しない。

本研究の課題

**「タスクを正しく完了させつつ、ツール呼び出しの多ターン（Multi-turn）ループを誘発し、検知されずにリソースを枯渇させる攻撃」**は未開拓の領域でした。本研究は、この「ツールレイヤー」を新たな攻撃面として特定し、その脆弱性を突く手法を提案します。

---

2. 提案手法：ツールレイヤー攻撃

本研究は、MCP 準拠の benign（良性）なツールサーバーを、テキスト可視フィールドのみを編集して悪意ある変種に変換する手法を提案します。

2.1 攻撃の核心メカニズム

攻撃サーバーは、関数シグネチャや最終的なペイロード（タスク結果）を変更せず、以下の要素を操作します。

1. セグメントインデックス（Segment Index）: 進捗を示す変数 $t$ を導入し、エージェントに「処理は完了していない」と認識させ、次の呼び出しを促します。
2. 較正シーケンス（Calibration Sequence）: 各ツール呼び出しで、コンマ区切りの長い整数リスト（例：1, 2, 3, ...）の生成を要求します。これにより、1 ターンあたりの出力トークン数を人為的に増大させます。
3. 返却ポリシー（Return Policy）:
   • Progress 通知: 条件を満たすまで、次の呼び出しを促すメッセージを返す。
   • Repair 通知: 形式が不正な場合、修正を要求してターンを進めない。
   • Terminal 返却: 最大ターン数 $T_{max}$ に達し、条件が満たされた時のみ、元の良性ペイロードを返してループを終了する。

2.2 最適化手法：MCTS ベースのテンプレート生成

手動でのテンプレート作成ではなく、モンテカルロ木探索（MCTS）を用いて、LLM ごとに最適な悪意あるテンプレートを自動生成します。

• 制約: テキスト可視フィールドのみを編集し、ペイロードとプロトコル準拠性を維持。
• 探索空間:
  • $A_{MT}$: 多ターン動作を誘発する編集。
  • $A_{LEN}$: 出力長を増大させる編集。
  • $A_{REP}$: 形式エラー時のリカバリメッセージを最適化。
• 評価基準: タスク成功確率（$Succ \ge p_{min}$）を維持しつつ、期待コスト（出力トークン数）を最大化する。

---

3. 主要な貢献

1. ツール呼び出しレイヤーの DoS 攻撃面の初実証:
   従来のプロンプトや RAG 層ではなく、エージェントとツールの相互作用ループ自体が脆弱であることを示しました。タスク成功と最終回答の正しさを保ちながら、中間プロセスでリソースを枯渇させる「正しさを維持した経済的 DoS」が可能であることを実証しました。
2. 汎用的な MCTS 最適化手法の提案:
   テキスト編集のみで、ペイロードや関数シグネチャを変えずに、多様な LLM やタスクに対して効果的な悪意あるテンプレートを生成するフレームワークを構築しました。
3. 大規模な実験的検証:
   6 種類の LLM（Qwen, Llama, Mistral, GLM, DeepSeek, Seed）および ToolBench, BFCL の 2 つのベンチマークを用いた実験により、既存の防御策がほぼ無力であることを示しました。

---

4. 実験結果

4.1 攻撃の成功率とコスト増幅

• トークン数: 1 クエリあたりの出力トークン数が60,000 トークン以上に達しました。
• コスト増幅: 既存の良性設定と比較して、1 クエリあたりのコストが最大658 倍（Mistral Large / BFCL）増加しました。
• エネルギー消費: エネルギー消費量が100〜560 倍に増加しました。
• GPU キューキャッシュ: 通常 1% 未満だった KV キャッシュ占有率が、攻撃下では**35〜74%**まで急上昇しました。

4.2 タスクの正しさと検知回避

• タスク成功率（TSR）: 攻撃下でもタスク成功率は良性環境とほぼ同等（例：96.2% vs 98.1%）を維持しました。
• 防御策の無力化:
  • PPL フィルター: 入力やツール応答のパープレキシティベースの検知は、攻撃パターンを「良性の範囲内」と判定し、検出できませんでした。
  • 自己監視・安全性ジャッジ: 生成された内容が「タスク遂行に必要な手順」として正当化されるため、モデルや Guard モデル（Llama-Guard-3, Qwen-Guard-3）は異常を検知しませんでした（検出率 3% 未満）。
  • ハードリミット: トークン数やツール呼び出し回数の上限を設定しても、攻撃は制限内で最大限のリソース消費を行うよう適応し、完全な阻止には至りませんでした。

4.3 システムスループットへの影響

• 攻撃により、並行して実行される良性タスクのスループット（トークン/秒）が平均 50% 低下しました。これは、KV キャッシュの占有率上昇とスケジューラ競合によるものです。

---

5. 意義と結論

本研究は、LLM エージェントのセキュリティにおいて、「最終結果の正しさ」だけでなく「プロセス全体の効率性」を監視する必要性を強く示唆しています。

• 新たな脅威モデル: 攻撃者がツールサーバーを支配し、プロトコルに準拠したまま「非効率な正常動作」を強制することで、経済的・運用的な DoS を引き起こすリスクを明らかにしました。
• 防御の方向性: 従来の「有害コンテンツ検知」や「出力長制限」では不十分です。エージェントの行動パターン（ツール呼び出しの頻度、トークン生成の効率性、状態遷移の論理）をベースラインと比較し、異常なリソース消費パターンを検知する行動ベースの防御や、ツールプロベナンス（出所）の制御が不可欠であることが示されました。

この研究は、LLM エージェントが実世界で広く展開される前に、ツールインターフェースのセキュリティ強化が急務であることを警告する重要な成果です。