AI エージェントのセキュリティリスク｜2026 年の事案に共通する構造と対策

はじめに

2025 年末から 2026 年にかけて、AI エージェントのセキュリティ事案が相次いで報告されました。任意の Web ページから AI アシスタントへ指示を注入できた「ShadowPrompt」、他のブラウザ拡張機能が AI エージェントを乗っ取れた「ClaudeBleed」、カレンダーの予定 1 件からローカルでのコード実行に至った Claude Desktop Extensions の RCE、そして Claude Code・Gemini CLI・GitHub Copilot を横断した「Comment and Control」。ベンダーも攻撃面も異なるこれらの事案は、個別に報道される一方で、全体を貫く構造はあまり整理されていません。

本記事は、AI エージェントのセキュリティを考えるためのハブとして、2026 年の主要事案を俯瞰し、それらに共通する構造（confused deputy 問題）と、実務者が取るべき設計原則を体系的にまとめます。個別事案の詳細な対策手順は、それぞれのスポーク記事に委ね、本記事では「なぜ同じ形の問題が繰り返されるのか」という視点を軸に据えます。

結論を先に述べると、一連の事案は個別の実装バグの寄せ集めではなく、「正当な権限を持つエージェントが、誤った依頼者のために動いてしまう」という信頼境界の設計問題が共通構造です。したがって対策の軸は、個々のパッチ適用に加えて、承認モード・権限範囲・エージェントに入る入力経路を「利便性の設定」ではなく「セキュリティ境界」として設計・運用することにあります。

AI エージェントはなぜ攻撃対象になるのか

AI エージェントとは、大規模言語モデルが自律的にツールを選択・連鎖させて、利用者の代わりにタスクを実行するソフトウェアを指します。ブラウザの操作、コードの生成と実行、外部サービスとの連携など、実行できる操作が広がるほど利便性は増しますが、同じ理由で攻撃者にとっての価値も増します。このセクションでは、従来のアプリケーションとの構造的な違いを 3 点に整理します。

従来のアプリケーションとの違い

第 1 に、エージェントは利用者の権限とログイン済みセッションの委譲を受けて動作します。 従来のアプリケーションは自身の権限の範囲で動きますが、エージェントは「利用者としてふるまう」ことが役割そのものです。ブラウザ拡張型のエージェントならログイン中の全サービス、コーディングエージェントならリポジトリへのアクセス権と API キー、MCP 連携型ならローカルシステムの実行権限が、エージェントの到達範囲になります。エージェントを乗っ取ることは、利用者を乗っ取ることとほぼ等価です。

第 2 に、エージェントにとってはデータと命令の区別が構造的に曖昧です。 従来のソフトウェアでは、コードとデータは明確に分離されています。一方、言語モデルは読み込んだテキストをすべて「文脈」として処理するため、Web ページの本文、メールの文面、PR のタイトル、カレンダーの予定名といった本来データであるはずの入力に埋め込まれた指示を、利用者の指示と区別できない場合があります。これが間接的プロンプトインジェクションと呼ばれる攻撃クラスの土台であり、後述する 2026 年の事案の多くがこの性質を利用しています。

第 3 に、エージェントは自律的にツールを連鎖させます。 利用者が意図しない経路、たとえば「低リスクなカレンダー読み取り」から「高リスクなローカルコマンド実行」への橋渡しを、エージェント自身の判断で行ってしまう場合があります。個々のツールが安全でも、連鎖の組み合わせが安全とは限らない点が、従来の権限モデルでは捉えにくい部分です。

参考: Koi Security（ShadowPrompt の報告）
“The security of that agent is only as strong as the weakest origin”
（そのエージェントのセキュリティは、最も脆弱なオリジンと同じ強度でしかない。）
https://www.koi.ai/blog/shadowprompt-how-any-website-could-have-hijacked-anthropic-claude-chrome-extension

攻撃面の 3 分類

2026 年の事案を整理すると、AI エージェントの攻撃面は大きく 3 つに分類できます。

ブラウザ拡張型（Claude for Chrome 等）は、ログイン済みセッションを共有するブラウザ内で動作します。攻撃の起点は、同じブラウザに同居する他の拡張機能や、閲覧した Web ページです。ブラウザという「他者のコードと同居する環境」に権限の大きいエージェントを置くことが、この類型固有のリスクになります。

コーディングエージェント型（Claude Code・Gemini CLI・GitHub Copilot 等）は、リポジトリの内容や PR・issue のテキストを入力として処理し、同じ実行環境に API キーやトークンを保持し、bash 実行などの強力なツールを持ちます。「信頼できない入力」「秘密情報」「実行能力」が同一ランタイムに同居する構成が、この類型の急所です。

MCP 連携型（Claude Desktop Extensions 等）は、Model Context Protocol を介して複数の外部コネクタを連鎖させます。カレンダーやメールのような低リスクなデータソースと、ローカルコマンド実行のような特権的なコネクタが、エージェントの判断でつながり得る点が固有のリスクです。ブラウザのサンドボックスに相当する隔離がなく、ホスト上の権限で動作する実装が多いことも、影響を大きくします。

次のセクションでは、この 3 分類に沿って、2026 年の主要事案を時系列で俯瞰します。

2026 年の主要事案の俯瞰

ここでは、前セクションで示した 3 分類（ブラウザ拡張型・コーディングエージェント型・MCP 連携型）に沿って、2026 年前後に報告された代表的な事案を俯瞰します。各事案の詳細な仕組みや対策手順は個別のスポーク記事に委ね、本セクションでは「何が起きたか」と「どの信頼境界が破られたか」に絞って整理します。

ShadowPrompt: 任意サイトからのゼロクリック注入

ブラウザ拡張型の初期事案が「ShadowPrompt」です。これは、利用者が悪意のある Web ページを訪れるだけで、Claude の Chrome 拡張機能にプロンプトを注入できたというものでした。拡張機能が *.claude.ai という広いオリジンパターンを信頼していたことと、そのサブドメイン上でホストされていた第三者製 CAPTCHA コンポーネントの DOM ベース XSS を組み合わせることで、攻撃者は Claude に任意の指示を送り込めました。

Anthropic は拡張機能 v1.0.41 でオリジン検証を claude.ai の完全一致に厳格化し、この事案は修正済みです。破られた信頼境界は「どのオリジンからのメッセージを信頼するか」であり、正規ドメインのサブドメインという「一見信頼できる出所」が悪用された点が特徴です。

ClaudeBleed と偽装クリック問題: ブラウザ拡張の信頼境界

続く事案が「ClaudeBleed」です。これは、権限を持たない別の拡張機能でも Claude for Chrome にコマンドを送り込め、Gmail・GitHub・Google Drive からのデータ持ち出しやメール送信を行わせられるというものでした。原因は、拡張機能が「コマンドの実行コンテキスト（誰が送ってきたか）」ではなく「オリジン（claude.ai）」を信頼していた点にあります。LayerX はこれを confused deputy 問題として説明しています。

Anthropic は初期緩和策として、外部から渡せるプロンプトを固定タスクの集合に絞り込みました。しかしその後、この「固定タスクを起動する仕組み」自体がクリックの真正性（event.isTrusted）を確認していないことが指摘され、別の拡張機能が偽装クリックで固定タスクを起動できる状態が、2026 年 7 月時点でも残っています。この偽装クリック問題の詳細な仕組みと、パッチ提供前に実施できる設定・運用の対策は、関連記事『Claude for Chrome に未修正の脆弱性｜偽装クリックのリスクと当面の対策』で扱っています。

参考: CyberScoop（LayerX の説明）
“LayerX called ClaudeBleed a confused-deputy problem, a program with real authority acting for the wrong caller.”
（LayerX は ClaudeBleed を confused deputy 問題、すなわち正当な権限を持つプログラムが誤った呼び出し元のために動作する問題と呼んだ。）
https://thehackernews.com/2026/07/claude-for-chrome-flaw-lets-other.html

Claude Desktop Extensions（MCP）の RCE: 低リスク連携から特権実行へ

MCP 連携型の事案として、Claude Desktop Extensions のリモートコード実行が報告されています。Claude Desktop Extensions は Model Context Protocol サーバーをパッケージ化したもので、ブラウザ拡張機能と異なりサンドボックスの外で、ホスト上の権限で動作します。

LayerX の報告によると、「Task Management」といった無害な名前を付けたカレンダーの予定に指示を仕込み、利用者が「最新の予定を確認して対応しておいて」と依頼するだけで、Claude がその指示を「ローカルでコードを実行してよい」と解釈し、実際に実行に至るケースが示されました。低リスクなコネクタ（カレンダー）から高リスクなコネクタ（ローカル実行）へ、エージェントの判断でデータが橋渡しされてしまう点が急所です。破られた信頼境界は「データソースと実行能力の分離」であり、Anthropic はこの事象を現行の脅威モデルの範囲外と位置づけ、MCP サーバーの導入時には第三者ソフトウェア同様の注意を促しています。

Comment and Control: コーディングエージェントを横断した注入

コーディングエージェント型の代表事案が「Comment and Control」です。これは、GitHub の PR タイトル・issue 本文・コメントといった通常のテキストにプロンプトを仕込み、GitHub Actions 上で動作する AI エージェントに認証情報を窃取させるという攻撃クラスで、Anthropic の Claude Code Security Review、Google の Gemini CLI Action、GitHub の Copilot Agent という 3 ベンダーの製品を横断して成立することが、2026 年 4 月に公開されました。

攻撃の全体は GitHub の内部で完結し、外部サーバーを必要としません。エージェントが PR タイトル等を信頼できる文脈として読み込み、埋め込まれた指示を実行し、窃取した認証情報を PR コメントや commit を通じて外部へ返します。とりわけ Copilot への攻撃では、HTML コメントに payload を隠すことで、環境変数フィルタリング・シークレットスキャン・ネットワークファイアウォールという 3 層のランタイム防御をすべて回避できたと報告されています。

この事案が示すのは、「信頼できない入力」「本番の秘密情報」「実行能力」が同一ランタイムに同居する構成そのものが根本原因であり、出力フィルタやネットワーク制御では防ぎきれないという点です。Anthropic は当該事象を CVSS 9.4（Critical）と評価したのち内部評価を None に変更し、Google・GitHub を含むいずれのベンダーも CVE を採番していません。この「重大と評価されつつ CVE が採番されない」問題は、後のセクションで改めて扱います。

参考: SecurityWeek（研究者 Aonan Guan 氏の説明）
“The injection surface changes, but the pattern is the same.”
（注入の入り口は変わっても、パターンは同じである。）
https://www.securityweek.com/claude-code-gemini-cli-github-copilot-agents-vulnerable-to-prompt-injection-via-comments/

これらの事案は、ベンダーも攻撃面も異なりますが、破られた信頼境界には共通の構造があります。次のセクションでは、その構造を confused deputy 問題として整理します。

事案に共通する構造: confused deputy 問題

前セクションで俯瞰した事案は、ベンダーも攻撃面も異なります。しかし破られた信頼境界を並べると、いずれも同じ形をしています。ここでは、その共通構造を confused deputy 問題として整理します。

正当な権限を持つプログラムが「誤った依頼者」のために動く

confused deputy（混乱した代理人）問題とは、正当な権限を持つプログラムが、その権限を、本来の依頼者ではない別の主体のために行使してしまう、という古典的なセキュリティ上の問題です。プログラム自身は「与えられた権限の範囲で、依頼された仕事をしている」だけなのに、依頼者のすり替えを検知できないために、結果として攻撃者の意図が実現してしまいます。

AI エージェントは、この構造に陥りやすい性質を複数備えています。エージェントは利用者の権限を委譲されて動作し（第 1 の性質）、読み込んだテキストのなかで「利用者の指示」と「データに埋め込まれた指示」を構造的に区別しにくく（第 2 の性質）、自律的にツールを連鎖させます（第 3 の性質）。この 3 つが揃うと、攻撃者は「エージェントが正規の仕事として読み込む場所」に指示を置くだけで、エージェントの権限を借りて目的を達成できます。

2026 年の事案を、この観点で並べ直すと構造が見えてきます。ShadowPrompt では「訪れた Web ページ」が、ClaudeBleed と偽装クリック問題では「同居する別の拡張機能」が、MCP の RCE では「カレンダーの予定」が、Comment and Control では「PR タイトルや issue コメント」が、それぞれ「誤った依頼者」でした。入り口はすべて異なりますが、エージェントがそれらを正規の依頼者と取り違えて権限を行使した、という形は共通しています。

参考: CSO Online（Manifold Security の Ax Sharma 氏）
“Monitoring AI agents at the prompt layer is fundamentally insufficient.”
（AI エージェントをプロンプト層で監視するだけでは、根本的に不十分である。）
https://www.csoonline.com/article/4168867/claude-in-chrome-is-taking-orders-from-the-wrong-extensions.html

プロンプト層の監視だけでは防げない理由

この構造から導かれる重要な帰結は、「悪意ある指示そのものを検知する」というアプローチには限界がある、という点です。攻撃者の指示は、Web ページの本文やカレンダーの予定名、PR のタイトルといった、エージェントが正規の仕事として読み込む場所に紛れ込みます。これらは、エージェントにとって「処理すべき文脈」そのものであり、明らかに悪意あるパターンとして弾くことが難しいものです。

さらに、エージェントが認識する環境そのものを操作される攻撃も報告されています。ClaudeBleed の分析では、UI の表示（ボタンのラベル等）を書き換えることで、エージェントの「状況認識」を操作し、本来なら承認を要する操作を安全な操作に見せかける手口が示されました。プロンプト層やモデル層でどれだけ入力を検査しても、エージェントが「安全だと認識した」うえで行う操作は、その検査をすり抜けます。

したがって、防御の重心は「モデルに何を読ませないか」だけでなく、「エージェントが何を実行できるか」「その実行にどこで承認境界を置くか」という、行動（アクション）の側に移す必要があります。この考え方は、後のセクションで実務者向けの設計原則として具体化します。

OWASP Top 10 for LLM Applications で整理する

confused deputy 問題という共通構造は、LLM アプリケーション固有のリスクを体系化した OWASP Top 10 for LLM Applications の枠組みでも整理できます。本セクションでは、2026 年の事案が対応する 2 つのリスク項目と、これらの事案に共通してみられる「CVE が採番されない」という追跡上の問題を扱います。

間接的プロンプトインジェクション（LLM01）

OWASP はプロンプトインジェクションを最上位のリスク（LLM01）に位置づけ、これを直接注入と間接注入に分けています。間接的プロンプトインジェクションは、Web サイトやファイルなど外部のソースから受け取った入力によって、モデルの挙動が意図しない形で変えられるものを指します。

2026 年の事案の多くは、この間接注入に該当します。悪意ある Web ページ（ShadowPrompt）、カレンダーの予定（MCP の RCE）、PR タイトルや issue コメント（Comment and Control）は、いずれも「エージェントが外部から受け取るデータ」であり、そこに埋め込まれた指示が挙動を変えました。Manifold は今回の偽装クリック問題も、間接的プロンプトインジェクションに対応づけています。

過剰なエージェンシー（LLM06）

もう 1 つの対応項目が、過剰なエージェンシー（excessive agency、LLM06）です。これは、エージェントに与えられた権限・自律性・ツールへのアクセスが広すぎるために、注入が成功した際の被害が拡大する、というリスクを指します。

MCP の RCE で、カレンダー読み取りからローカルコマンド実行へと連鎖できたこと、Comment and Control で、エージェントが本番の秘密情報と実行能力を同一ランタイムに持っていたことは、いずれも過剰なエージェンシーの現れです。注入という「入り口」の問題（LLM01）と、権限の広さという「被害範囲」の問題（LLM06）は独立しており、両方に手を打つ必要があります。Manifold は偽装クリック問題における無言実行のリスクを、この過剰なエージェンシーに対応づけています。

CVE が採番されない問題

2026 年の一連の事案に共通する、追跡上の問題も押さえておく価値があります。それは、重大と評価された事象でも CVE が採番されないケースが目立つ、という点です。

Comment and Control は、あるベンダーが一度 CVSS 9.4（Critical）と評価しながら、最終的にどのベンダーも CVE を採番せず、公開アドバイザリも出しませんでした。偽装クリック問題についても、2026 年 7 月時点で CVE は採番されていません。ベンダー側が「製品はプロンプトインジェクションに対して堅牢化されていない（設計上の既知の性質）」という立場を取る場合、これは修正すべき脆弱性ではなく、仕様上の限界として扱われがちです。

この状況には、実務上の直接的な影響があります。CVE を起点に脆弱性を追跡する運用（NVD の参照、CI/CD の依存関係スキャン、CVE アラートに反応する自動更新）では、これらの事象を捕捉できません。組織が影響を受けているかどうかを、CVE の有無だけで判断できない、という前提に立つ必要があります。AI エージェントの導入・運用にあたっては、CVE データベースに加えて、ベンダーのシステムカードや第三者のセキュリティリサーチを継続的に確認する体制が求められます。

実務者が取るべき設計原則

これまで見てきた共通構造を踏まえ、実務者が AI エージェントを導入・運用する際の設計原則を、利用者・管理者・共通の 3 つの立場で整理します。個別製品の具体的な設定手順は各スポーク記事に委ね、ここでは立場ごとの考え方の軸を示します。

利用者: 承認モードと権限範囲をセキュリティ境界として扱う

利用者の立場で最も重要なのは、エージェントの「承認モード」や「アクセスできる範囲」を、利便性の設定ではなくセキュリティ境界として扱うことです。

confused deputy 問題の帰結として、防御の重心は「エージェントが何を実行できるか」の側にあります。したがって、自律実行モード（確認を省くモード）を安易に有効にせず、実行前の承認ステップを残すことが、注入が成功した場合の被害を抑える現実的な手立てになります。承認ダイアログが表示された際に、自分が意図した操作かを都度確認する運用も、この境界を機能させる前提です。

あわせて、エージェントに与える権限は必要最小限にとどめることが望まれます。ログイン中のセッションを共有するブラウザ拡張型では、機微な情報を扱う作業と、エージェントを試用する作業のブラウザプロファイルを分けることが考えられます。コーディングエージェント型では、エージェントが到達できるトークンや秘密情報の範囲を絞ることが、被害範囲の限定につながります。

管理者: 拡張機能・エージェントの統制

組織の管理者の立場では、個々の利用者の設定に依存せず、組織単位で統制の枠組みを設けることが軸になります。

第 1 に、導入するエージェントや拡張機能を許可リスト方式で管理することです。「原則すべてを禁止し、明示的に許可したものだけを導入可能にする」という方針は、素性の不明なコンポーネントが混入する余地を減らします。ブラウザ拡張型については、Chrome Enterprise のポリシーや、製品側の管理者コントロール（アクセス可能なサイトの許可リスト・ブロックリスト）を組み合わせられます。この具体的な設定手順は、関連記事『Claude for Chrome に未修正の脆弱性｜偽装クリックのリスクと当面の対策』で扱っています。

第 2 に、試用（パイロット）の段階を分離することです。新しいエージェントを本番環境や機微な情報を扱う端末にいきなり展開せず、限定的な許可リストと対象ユーザーで試し、挙動を確認しながら段階的に広げる運用が、公式ドキュメントでも推奨されています。

第 3 に、CVE に依存しない情報追跡です。前セクションで述べたとおり、AI エージェントの重大な事象は CVE が採番されないことがあります。ベンダーのシステムカードやセキュリティリサーチを継続的に確認する体制を、脆弱性管理のプロセスに組み込むことが求められます。

共通: 信頼できない入力の経路を洗う

利用者・管理者に共通する原則は、「信頼できない入力がエージェントの実行コンテキストに入る経路」を洗い出すことです。

一連の事案は、攻撃の入り口こそ Web ページ・拡張機能・カレンダー・PR コメントと異なりますが、いずれも「エージェントが正規の仕事として読み込む場所」に指示が紛れ込む、という形でした。したがって、自組織で運用しているエージェントについて、それが外部からどのような入力を受け取り、その入力にどの程度の実行能力が結び付いているかを把握することが、リスク評価の出発点になります。

とりわけ、コーディングエージェント型では、外部の貢献者が触れられる場所（PR・issue 等）を入力として処理するエージェントが、本番の秘密情報や実行能力と同一ランタイムを共有していないかを確認する価値があります。該当する場合、外部貢献者からの入力を処理したエージェントが触れた認証情報は、予防的にローテーションの対象と考える運用も検討に値します。

まとめ

2025 年末から 2026 年にかけての AI エージェントのセキュリティ事案は、個別の実装バグの寄せ集めではなく、正当な権限を持つエージェントが誤った依頼者のために動いてしまう confused deputy 問題という共通構造を持っています。防御の重心を「モデルに何を読ませないか」から「エージェントが何を実行できるか」へ移し、承認モードや権限範囲をセキュリティ境界として設計・運用することが、実務上の軸になります。

• 一連の事案の共通構造は confused deputy 問題
• 攻撃の入り口は異なっても破られる境界は同型
• プロンプト層の監視だけでは根本的に不十分
• OWASP では LLM01 と LLM06 に対応
• 重大な事象でも CVE 不在のケースがある
• 利用者は承認モードと権限範囲を境界として扱う
• 管理者は許可リスト方式と試用環境の分離で統制

以上、最後までお読みいただきありがとうございました。