AIエージェントのツール呼び出しで機密流出｜査読前研究

AIエージェントは、社内文書や利用者プロフィールを「読める」だけでなく、その中身を外部ツールへの引数として「送ってしまう」ことがあります。査読前の研究が、業務上必要そうな文脈を添えるだけで、モデルが保護対象の属性をツール呼び出しの引数に混ぜ込むことを示しました。セッション単位の開示率はモデル構成によって20.8%〜75.0%。プロンプトで「出すな」と指示しても、その効果はモデルによってばらつき、ゼロにはなりませんでした。

この記事でわかることは次の3点です。

  • 「ツール呼び出しの引数」という、これまで監視の対象外だった漏えい経路の正体
  • プロンプトによる禁止指示が、なぜ運用上の防御線として当てにできないのか
  • 情シスとして、社内のAI利用のどこを見に行けばよいか

そもそも「ツール呼び出し」とは何か

ツール呼び出し（tool call）とは、AIが自分で外部のシステムを操作するために、呼び出す機能名と引数をモデル自身が組み立てて発行する仕組みです。「先月の売上を調べて」「この内容で担当者にメールして」といった依頼にAIが応えられるのは、この仕組みが裏で動いているからです。

「うちはAIエージェントなど導入していない」と思っていても、実際には入っていることがあります。社内チャットボットの「コネクタ」「拡張機能」「プラグイン」、業務SaaSに後から追加されたAIアシスタント、開発部門が使うコーディング支援ツール——これらは名前こそ違え、同じくツール呼び出しで動きます。近年はこの仕組みを標準化したModel Context Protocol（MCP）の採用が広がっており、AIアプリ側の設定画面に「MCPサーバ」という項目があれば該当します。

該当判定の入口はシンプルです。社内AIツールの管理画面を開き、(1) どの外部連携が有効か、(2) それがどこへデータを送るか、(3) 送った引数がログに残るかを確認してください。3番目が「残らない」なら、今回の研究が指摘する漏えいは起きても気づけません。

何が起きたのか：業務上必要そうに見せると、モデルは出す

研究チーム（Ben Dong氏ほか）は2026年8月21日、arXivに「The Claws in Plain Sight: Unauthorized Context Disclosure through LLM Agent Tool Calls」を投稿しました。提示されたのは authority-pressure attack（権威による圧力を使った攻撃） と名付けられた手口です。

やっていることは、拍子抜けするほど地味です。タスクに隣接する文書やツールの説明文の中で、保護すべき属性を「手続き上・運用上、必要な項目である」かのように書いておくだけ。すると、モデルはそれを「正当な引数」として素直に埋めてしまいます。攻撃コードもエスケープも要りません。

検証は、6段階の圧力レベル × 4段階のプライバシーポリシー指示 × DeepSeekとClaudeの5つのモデル構成、計120回のツール呼び出しという合成ベンチマークで行われました。結果は次のとおりです。

観点 結果
セッション単位の開示率 モデル構成により 20.8%〜75.0%
強いプライバシー指示の効果 全体の開示は減るが、モデル横断で一貫して消えるわけではない
著者らの結論 プロンプトレベルのポリシーは「移植可能な強制境界」にはならない

数字の粒度には注意が要ります。5構成 × 6 × 4 = 120回なので、1構成あたりの試行は24回です。20.8%は24回中5回、75.0%は24回中18回に相当します（率からの逆算）。つまり数パーセントの差を云々できる精度ではありません。読むべきは「3〜4回に1回は出る構成もあれば、4回に3回出る構成もある」という桁感のほうです。

なぜ起きるのか：「読める」と「送ってよい」は別の権限

論文の核心は、攻撃手法よりもこの一文にあります——文脈情報に正当にアクセスできることは、それをあらゆる目的・あらゆる宛先へ送信してよいという許可を意味しない。

従来のアクセス制御は「誰がどのデータを読めるか」を決めてきました。ところがエージェントは、読んだ内容を自分で組み立てた引数として、自分で選んだ宛先に渡します。ここに独立した認可の判断が入っていません。人間なら「この項目を外部サイトに入れるのはまずい」と立ち止まるところを、モデルは「必要と書いてあった」という理由で通してしまう。目的（purpose）と宛先（destination）の観点が、設計から抜けているわけです。

だからこそ著者らは、対策としてプロンプトの改善ではなく「実行前に、生成された引数そのものを、目的と宛先の観点で検査すること」を挙げています。

この研究の限界（ここは正直に読む）

著者ら自身が明記している限界を押さえておきます。

  • 査読前のプレプリントであり、結果は今後変わりうるものとして扱う必要があります。
  • 使われたのは合成プロファイルで、実在の個人データではありません。
  • 測っているのは「文脈から引数が生成される境界でのポリシー違反」であって、ネットワーク越しの実際の送信完了や、実運用中の利用者からの漏えいではありません。「実際に流出した」という話ではない点は、社内で共有する際に必ず添えてください。
  • 評価対象は5構成のみ。他のモデルや実装にこの数値がそのまま当てはまるとは限りません。

現場目線：一番効くのが一番地味という現実

この論文を読んで肝が冷えるのは、攻撃の高度さではなく「防御側のログに何も残らない」点です。不正アクセスもマルウェアも介在せず、正規のAIアシスタントが、正規の連携先に、正規の形式のリクエストを送っただけ。ふるまいとしては何も異常がありません。EDRにもプロキシのアラートにも引っかからないでしょう。

加えて、AI連携は資産管理台帳に載りにくいという構造的な弱点があります。業務部門がSaaSの管理画面でトグルをひとつ有効にすれば連携は増え、稟議も端末へのインストールも伴わない。「どの部署のどのAIが、どこへ何を送れる状態か」を把握できている組織は、正直まだ少ないはずです。

そして解決策が、これまた地味です。ツール呼び出しの引数をログに残し、宛先ごとに送ってよい項目を決めておく。新技術の話に聞こえて、やることは昔から変わらない「棚卸しとログ」です。後回しにされやすい領域ですが、逆に言えば今から着手しても十分間に合います。

情シスはどうすべきか

自前でチェックリストを作るより、公的機関の資料を土台にしたほうが確実です。AIの利用をめぐるサイバーリスクは情報セキュリティ10大脅威 2026（IPA、2026年1月29日公表）の組織編で初選出ながら3位。優先度を経営層に説明する材料としてそのまま使えます。

技術面ではMCPの公式仕様が参考になります。Security Considerations には、クライアントが行うべきこととして「悪意ある、あるいは偶発的なデータ持ち出しを避けるため、サーバを呼ぶ前にツールの入力を利用者に提示すべき（SHOULD）」と明記されており、今回の論文の提言と方向は同じです。AIツールの選定時に「引数を実行前に見せる／記録する」機能の有無を基準へ加えてください。後から足せる機能ではありません。

AIエージェントの漏えい経路は今回の一つだけではありません。拒否した応答からも機密が復元されうる研究（AIエージェント、拒否しても機密は漏れる｜研究解説）、権限の与えすぎを抑える研究（AIエージェントの過剰権限を学習で抑制｜研究解説）、実装側の脆弱性の実例（MCP Toolboxに認証回避3件｜AIのDB接続が危険）とあわせて読むと全体像がつかめます。分類の枠組みはOWASP LLM Top10 2026が参考になります。

まとめ

  • 漏えい経路は「ツール呼び出しの引数」。業務上必要そうな文脈を添えるだけで、モデルは保護対象の属性を引数に混ぜる。査読前研究での開示率は構成により20.8%〜75.0%（1構成24回の試行）。
  • プロンプトでの禁止指示は防御線にならない。強い指示で全体の開示は減るが、モデル横断で一貫して消えるわけではなく、著者らは「移植可能な強制境界ではない」と結論づけている。
  • 見るべきは「読めるか」ではなく「どこへ送れるか」。社内AIツールの外部連携を棚卸しし、引数がログに残るかを確認する。選定時は「実行前に引数を提示・記録できるか」を基準に入れる。

出典

タイトルとURLをコピーしました