セキュリティ

AIエージェントの権限昇格問題 — MCPが抱える「confused deputy」とツール権限の暴走

2026/04/14

1. 「ツールを呼べる」ことが、新しいリスク面になる

チャットで質問に答えるだけのLLMと、ファイルを読み書きし、APIを叩き、外部サービスと連携するAIエージェントとでは、セキュリティ上の性質がまったく違う。後者は「何を答えるか」だけでなく「何を実行できるか」というリスクを新たに背負う。Anthropicが提唱し、いまや事実上の標準になりつつあるMCP（Model Context Protocol）は、この「AIエージェントがツールを呼び出す」ための配線を標準化する仕組みだが、標準化が進むほど、権限の設計を誤ったときの被害範囲も広がる。

本稿では、MCPの公式仕様書が名指しで警告している「confused deputy（混乱した代理人）」問題の仕組みと、実際に大手サービスのMCP連携で起きた権限暴走の事例を見ていく。

2. 「confused deputy」問題とは何か

「confused deputy」は、MCP固有の概念ではなく、1988年に提唱された古典的なセキュリティ問題（信頼された代理人が、権限を持たない第三者の指図で、その権限を誤用してしまう状態）だ。MCPの公式ドキュメント「Security Best Practices」は、この問題がMCPプロキシサーバー（MCPクライアントと外部API・外部サービスの間を仲介するMCPサーバー）で具体的にどう発生しうるかを、攻撃フローの図解付きで説明している。

条件は以下の4つが揃ったときに成立する。

MCPプロキシサーバーが、外部の認可サーバーに対して固定の（すべてのユーザーで共通の）クライアントIDを使っている
MCPプロキシサーバーが、MCPクライアント側の動的なクライアント登録を許可している（クライアントごとに別々のclient_idを発行できる）
外部の認可サーバーが、初回の認可後に同意済みを示すCookieをブラウザに保存する
MCPプロキシサーバーが、外部への転送前に、クライアントごとの同意確認を適切に実装していない

この4条件が揃うと、攻撃者は次の手順で正規ユーザーになりすませる。

ユーザーが正規にMCPプロキシ経由で外部APIを利用し、認可に同意する（このとき同意済みCookieがブラウザに残る）
攻撃者が、悪意あるリダイレクト先を指定して新しいクライアントIDを動的登録し、細工したリンクをユーザーに送る
ユーザーがそのリンクを開くと、ブラウザに残っていた同意済みCookieのせいで、外部認可サーバーは同意画面を省略してしまう
認可コードが、攻撃者が指定したリダイレクト先（攻撃者のサーバー）に渡ってしまう
攻撃者はその認可コードを使い、正規ユーザーになりすましてMCPサーバーにアクセスする

MCP仕様書は、この対策として「クライアントごとの同意状態をサーバー側で管理し、外部認可サーバーへ転送する前に必ず確認する」ことを必須（MUST）としている。単に「一度同意させれば良い」という設計が、この種のなりすましを生む土壌になる。

3. 実例：GitHubのIssueひとつで、プライベートリポジトリが漏れる

理論上の問題ではなく、実際に大手サービスの公式MCP連携で起きた事例がある。2025年5月、AIセキュリティ企業Invariant Labsが、GitHub公式のMCPサーバーに対する攻撃手法を報告した。

開発者が「オープンなIssueを確認して」とAIエージェントに指示するだけの、日常的な操作が起点になる。攻撃者はあらかじめ、公開リポジトリに「隠し指示」を埋め込んだIssueを作成しておく。AIエージェントがこのIssueを読み込むと、埋め込まれた指示に従って、そのユーザーがアクセス権を持つプライベートリポジトリの情報を収集し、それを公開リポジトリ側にプルリクエストとして自動的に投稿してしまう。報告によれば、この手法によって実際に、対象ユーザーの住所・給与情報・プライベートリポジトリの内容といった機微な情報が、公開の場に漏洩する結果になったという。

重要なのは、これはGitHub MCPサーバーの実装バグではなく、アーキテクチャ上の構造的な問題だと報告書が指摘している点だ。「公開情報を読む権限」と「非公開情報へアクセスする権限」を同じエージェントセッションが同時に持っていたことが、根本原因になっている。プロンプトインジェクションによって「公開領域の読み取り」という低い信頼度の操作が、「非公開領域への到達」という高い信頼度の権限を、事実上乗っ取ってしまった格好だ。これはまさに、confused deputy問題がエージェントの文脈で現実化した形だと言える。報告された緩和策は、「1セッションにつき1リポジトリまでしかアクセスさせない」「エージェントには必要最小限の権限のトークンだけを与える」というシンプルなものだった。

4. 実例：正規パッケージが、ある日突然「暴走」する

もう一つ、2025年9月に発覚した事例は、権限そのものよりも、その権限を持つツール自体が汚染されるパターンを示している。メール配信サービスPostmark向けの非公式MCPサーバー「postmark-mcp」の、npm上のパッケージが乗っ取られた。バージョン1.0.16で、送信されるすべてのメールを攻撃者のサーバーへBCCで転送する、という1行のコードが追加されていたことが、セキュリティ企業Koi Securityによって発見された。

このパッケージ自体は、それまで正常に動作しており信頼を得ていた。「メールを送信する」という正規の機能に対して与えられていた権限が、ある日のアップデートを境に、パスワードリセットメール・請求書・社内連絡といった機微な情報を外部に横流しする経路として悪用されてしまった。削除されるまでに1,643回ダウンロードされていたと報告されている。MCPサーバーは往々にして「メールを送る」「リポジトリを操作する」といった広い権限を単一のツールに集約するため、そのツール自体が汚染されたときの被害が大きくなりやすい、という構造的な弱点を示す事例だ。

5. 何を見直すべきか

3つの事例に共通するのは、「このエージェント（あるいはこのツール）に、どこまでの権限を、どういう単位で与えているか」を具体的に把握できていなかったという点だ。

セッション単位でのスコープ限定：GitHub MCPの事例が示すように、1つの操作単位でアクセスできる範囲（1リポジトリ、1つのデータソースなど）を狭く区切ることが、被害の連鎖を止める最も直接的な手段になる
クライアントごとの同意管理：confused deputy問題への対策として、MCP仕様書が必須としている「クライアントIDごとの同意状態を、サーバー側で確認してから外部へ転送する」実装を怠らない
サードパーティ製MCPサーバーのサプライチェーン監視：postmark-mcpの事例のように、正規に動作していたパッケージが、あるアップデートを境に汚染されることがある。導入時だけでなく、継続的な監査が必要になる

AIエージェントが「何を答えるか」だけでなく「何を実行できるか」を扱うようになった以上、権限設計はもはやAIの問題ではなく、従来型のアクセス制御・最小権限の原則がそのまま問われる領域になっている。目新しい防御技術を探す前に、まず「今、自組織のエージェントはどこまでの権限を持っているか」を棚卸しすることが、現実的な出発点になりそうだ。