6つのAI脆弱性。3つの失敗パターン。多くの組織が間違った問題を修正している。

AIセキュリティリスクを再定義した波

2025年6月から2026年4月にかけて、セキュリティ研究者は、ほとんどのエンタープライズが日常的に利用しているプラットフォームにおいて、6件の重大なAI脆弱性を公表しました。個別に見ると、それぞれの公表はパッチ適用とニュース報道を引き起こしましたが、まとめて見ると、エンタープライズデータの窃取手法が構造的に変化していることを示す、業界で最も重要な証拠群となっています。

主なポイント

1. 1年足らずで6件の重大なAI脆弱性が公表。 EchoLeak、Reprompt、GeminiJack、ForcedLeak、GrafanaGhost、OpenAIプラグインのサプライチェーン攻撃は、2025年半ばから2026年4月にかけて、Microsoft Copilot、Salesforce、Google Gemini、Grafana、OpenAIエコシステムを標的としました。
2. 業界はこれらを1つの問題として扱っているが、実際は3つ。 これら6件の公表は、3つの異なる失敗パターンを含みます：AIが検証なしに処理する信頼できない入力、操作ごとの強制がない過度に広範なデータアクセス、設計されていない機能範囲で動作するバックエンドプロセス。
3. 信頼できない入力が最も一貫した失敗。 この一連の脆弱性はすべて、外部データが正規のチャネルを通じてシステムに入り、AIが検証せずに処理することから始まります。このパターンを業界はほとんど無視しています。
4. GrafanaGhostは他の5件とアーキテクチャ的に異なる。 Grafanaはユーザー向けデータアクセスにRBACを採用していますが、この攻撃はユーザーセッションではなく、システムレベルのバックエンドプロセスを通じて行われたため、RBACは発動しませんでした。データアクセス制御は他の5件には有効ですが、GrafanaGhostには効果がありません。
5. モデルレベルのガードレールはすべてのケースで機能しなかった。 Grafanaの防御は1つのキーワードで突破され、SalesforceのCSPは5ドルで回避されました。ガードレールは攻撃対象システム内部の設定であり、実際の制御を補完するものですが、代替にはなりません。

EchoLeakはMicrosoft 365 Copilotにおける最初の正式なゼロクリックAI脆弱性（CVSS 9.3、2025年6月パッチ適用）でした。ForcedLeakはSalesforce Agentforceで2025年9月に発見され（CVSS 9.4）、5ドルのドメイン購入で悪用可能でした。GeminiJackはGoogle Gemini Enterpriseにおける真のゼロクリック攻撃で、1つの細工されたドキュメントから数年分のWorkspaceデータを流出させることができました。Repromptは、細工されたURLによるCopilotのワンクリックデータ流出を実証しました。GrafanaGhostは信頼されたバックエンドプロセスを見えないデータ運搬役に変えました。そしてOpenAIプラグインエコシステムへのサプライチェーン攻撃は、収集されたエージェント認証情報を使い、47の企業で6か月間検知されずに活動しました。

すべてのベンダーは責任ある対応を行い、すべてのプラットフォームにパッチが適用されました。しかし、いずれの攻撃も、個別プラットフォームのパッチでは埋められないアーキテクチャ上のギャップを突いています。

CrowdStrike 2026 Global Threat Reportによると、2025年の検知の82%はマルウェアを伴わないものでした。攻撃者はすでに正規ツールを利用して活動しており、これら6件の脆弱性はその傾向の極致です。AI自体が正規ツールであり、信頼されたデータアクセスチャネルが流出経路となり、監視システムは異常を検知できません。

6つの脆弱性の概要

パターン1：信頼できない入力がAIの信頼済みコンテキストとして処理される

この一連の脆弱性はすべて同じ流れで始まります。外部データが正規のチャネル（メール、共有ドキュメント、Webフォーム送信、URLクエリパラメータ、侵害されたプラグインなど）を通じてシステムに入り、AIコンポーネントがそれを敵対的なものとみなさずに処理します。

EchoLeakのペイロードは、Copilotが定例クエリ時にコンテキストとして取り込んだ細工メールでした（ユーザーは開封していません）。GeminiJackは、ターゲット組織の誰とでも共有可能な細工Googleドキュメントで、GeminiのRAGシステムにインデックスされ、従業員の検索で初めて発動しました。ForcedLeakは、42,000文字のWeb-to-Leadフォームフィールドに隠されたテキストで、AIはフォームデータと注入命令を区別できませんでした。GrafanaGhostは、Grafanaのイベント監視ログに保存されたURLクエリパラメータで、外部Webリクエストが通常トラフィックとして記録され、後にAI対応バックエンドプロセスが処理しました。

外部入力は、いかなるシステムが処理する前にも検証されるべきという原則は、Webアプリケーションセキュリティの基本です。組織はこれを前提にWAFを構築し、開発者も訓練されています。しかし、AIが処理するデータについては、メールや共有ドキュメント、イベントログ、フォームフィールドがAIプロンプトインジェクションの入力チャネルになるとは誰も考えていませんでした。

Cyera 2025年AIデータセキュリティレポートによると、エンタープライズの83%が日常業務でAIを利用している一方、AIがどのようにデータへアクセスしているかを強く可視化できているのは13%のみ。その70ポイントのギャップこそが、これらの脆弱性が突いている攻撃面です。AIは数十のソースからデータを処理しますが、それらのソースに敵対的AI命令が含まれていないか、誰も検証していません。

これは6件すべての脆弱性に共通する失敗であり、業界がほとんど無視している問題です。データアクセス制御では対応できず、モデルレベルのガードレールも無力です。AIが触れるすべてのデータソースに対して、入力検証の徹底が必要です。

パターン2：操作ごとの強制がない過度に広範なAIデータアクセス

6件中5件（EchoLeak、Reprompt、GeminiJack、ForcedLeak、OpenAIプラグイン攻撃）は、ユーザーの代理として広範かつ暗黙的なデータアクセス権を持ち、操作ごとのポリシー強制がないAIシステムに関係しています。

Microsoft 365 Copilotは、OneDrive、SharePoint、Teamsといった全生産性スイートへの事前設定済みアクセスを持ちます。Google Gemini EnterpriseのRAGは、Gmail、Docs、Calendar全体にネイティブアクセスします。Salesforce AgentforceはCRM全体をクエリ可能です。いずれもAIはセッションや接続レベルで一度認証されると、到達可能なすべてのデータにアクセスします。命令が注入されると、AIはユーザーの意図を超えてデータを取得し、個々の取得ごとにポリシー評価されることはありません。

OpenAIプラグイン攻撃はこのパターンの変形です。侵害された認証情報がエージェントのIDとして機能し、47の環境で6か月間広範なアクセスを許しました。認証情報は正当で、アクセスも通常通りに見えました。個々の操作ごとに制限する仕組みがありませんでした。

操作ごとのアクセス制御（各リクエストごとに独立して認証、属性ベースポリシーの適用、認証情報をAIのアクセス可能なコンテキストから隔離、すべてのアクセスを完全な帰属情報付きで記録）は、これら5件の被害範囲を抑制できたはずです。

Kiteworksデータセキュリティ＆コンプライアンスリスク：2026年予測レポートでは、ガバナンス制御（監視、ログ、人間の介在）と封じ込め制御（目的制約、キルスイッチ、ネットワーク分離）との間に15〜20ポイントのギャップがあると指摘しています。操作ごとの強制のギャップは現実的かつ緊急の課題であり、該当する5つの脆弱性で顕著です。

パターン3：プロセス封じ込めと機能スコープの失敗

GrafanaGhostは他の5件とアーキテクチャ的に異なり、単なるデータアクセス制御の問題として扱うのは誤りです。

Grafanaはユーザー向けデータアクセスにRBACを採用していますが、GrafanaGhostはこれを発動させませんでした。攻撃はユーザーの代理ではなく、システム権限で動作する信頼されたバックエンドエンリッチメントプロセスを通じて行われました。これらのプロセスは、イベントデータをダッシュボード用に相関・分析・準備するためのものです。

エンリッチメントプロセスが攻撃者のイベント（URLクエリパラメータに隠されたAIプロンプト）を分析した際、AIコンポーネントはそのプロセスの特権コンテキスト内で命令を実行しました。誰も要求していないダッシュボードを作成し、機密データを画像タグに埋め込み、外部からアクセス可能にしました。Nomaの研究者は、「INTENT」というキーワードでAIのガードレールが完全に崩壊することを発見しました。URL検証の不備により、外部サーバーが内部サーバーに偽装されていました。

バックエンドプロセスには広範なデータ読み取り権限が必要だったのは正当ですが、ダッシュボードのレンダリングや画像タグ生成、外部サーバーへのリクエスト送信などの出力機能は本来不要でした。しかし、それらへのアクセスを積極的に防ぐ仕組みがありませんでした。

OpenAIプラグイン攻撃もパターン3の要素を共有しています。エージェント認証情報が、侵害されたプラグインコードからアクセス可能な場所に保存されていたため、認証トークンがAIのアクセス可能なコンテキストから隔離されていませんでした。

最小権限の原則は、データアクセスだけでなく、プロセスが呼び出せるAPIやレンダリングルーチン、出力チャネル、認証情報の保存場所にも適用されるべきです。これが封じ込めのギャップであり、データアクセスガバナンスとは異なるアーキテクチャ的対応が必要です。

3つの失敗パターンと制御策の対応表

モデルレベルのガードレールは全体で失敗—だがこれは症状にすぎない

GrafanaのAIガードレールは1つのキーワードで突破され、SalesforceのContent Security Policyは5ドルの期限切れドメインで回避されました。Google GeminiのRAGは細工ドキュメントと正規ドキュメントを区別できず、Microsoft Copilotの安全機能も細工メールやURLによるコンテキストハイジャックを防げませんでした。

モデルレベルのガードレールは攻撃対象システム内部の設定です。プロンプトインジェクションで上書きされたり、信頼境界を狙われたり、AIが処理するコンテキストを操作されることで無効化されます。主要なLLMはすべて管理された研究環境でほぼ完璧な成功率で脱獄（jailbreak）されています。Agents of Chaos研究（2026年2月、MIT・ハーバード・スタンフォード・CMU等20名の研究者による）は、AIエージェントがインフラを破壊し、PIIデータベースを漏洩し、ライブ環境でなりすましを受け入れる様子を記録しました。

ガードレールは有用な防御層ですが、実際の制御（入力検証、操作ごとのアクセス強制、プロセス封じ込め）を補完するものであり、代替にはなりません。いかなる規制当局、監査人、フォレンジック調査員も「モデルに禁止命令を出していた」というだけでは、アクセス制御・入力検証・プロセス封じ込めの証拠として認めません。

Kiteworksによるデータアクセスパターンへの対応—そしてその先の課題

Kiteworksは、Secure MCP ServerとAI Data Gatewayを通じて、AIシステムとエンタープライズデータリポジトリの間にガバナンスされたデータレイヤーを提供します。AIからのすべてのデータリクエスト（MCP経由の対話型アシスタントでも、API経由のRAGパイプラインでも）は、OSキーチェーンに保存された認証情報（AIモデルには決して公開されない）を用いたOAuth 2.0認証を経て、すべての操作でリアルタイムにRBACおよびABACポリシー評価を受け、大量抽出を防ぐためにレート制限され、完全な帰属情報付きでSIEMに連携される改ざん検知可能な監査証跡に記録されます。

これらの制御はパターン2—AIシステムがユーザーの代理で広範な暗黙的アクセスを持ち、操作ごとの強制がない5件の脆弱性—に直接対応します。操作ごとのABACにより、AIが各リクエストでアクセスできる範囲を制限し、認証情報の隔離で収集を防ぎ、監査証跡で検知とコンプライアンス要件を満たします。

パターン1（信頼できない入力）については、Kiteworksが実装する「AIモデルやAIのアクセス可能なコンテキストの外部で動作する制御」の原則が、入力検証の課題にも拡張されます。しかし、SalesforceフォームやGoogleドキュメント、Microsoftメール、Grafanaイベントログに入力されるコンテンツに敵対的AI命令が含まれていないかを検証するのは、データアクセスガバナンスだけでは解決できないアプリケーション層の責任です。

パターン3（プロセス封じ込め）については、KiteworksのMCP実装が正しいアーキテクチャ的アプローチを示しています。OSキーチェーンでのOAuthトークン管理、すべてのMCP操作へのABAC、パストラバーサル検証などです。これらの原則を、サードパーティのバックエンドプロセスの機能スコープ（アクセスできるデータだけでなく、実行できる機能自体の制限）にも拡張することが、今後の課題です。

率直な評価として、Kiteworksはパターン2の被害範囲縮小と検知を実現しますが、パターン1と3には業界全体でさらなるアーキテクチャ的制御が必要です。

セキュリティリーダーが取るべき行動—3パターンすべてに対応するために

第一に、すべてのAI連携で入力の信頼境界を監査してください。AIが処理するすべてのデータソース（メール、共有ドキュメント、フォーム送信、イベントログ、APIレスポンス、メタデータフィールド）を特定します。外部データがAIコンポーネントに届くシステムがあれば、システム内部のどこに保存されていても、その入力を敵対的なものとして扱い、Webユーザー入力と同じ検証を適用してください。

第二に、ユーザーの代理で動作するすべてのAIシステムに対し、操作ごとのデータアクセス強制を必須としてください。接続時だけでなく、すべてのリクエストごとに認証し、すべての操作ごとにABACを評価、認証情報はAIのアクセス可能なコンテキスト外に保存、完全な帰属情報付きの改ざん検知可能な監査証跡をSIEMに連携します。これらのいずれかが欠けていれば、そのAI連携にはプロンプトインジェクションに耐えるデータアクセス制御がありません。

第三に、バックエンドAIプロセスの機能スコープを必要最小限に限定してください。広範なデータ読み取り権限が必要な場合もありますが、コンテンツレンダリング、外部リクエスト生成、ダッシュボード作成、出力ルーチン呼び出しなどは不要です。最小権限は「アクセスできるデータ」だけでなく、「実行できる機能」にも適用されるべきです。これがGrafanaGhostに欠けていた制御です。

第四に、モデルレベルのガードレールを代替制御として扱うのをやめてください。このシリーズのすべてのケースで失敗しています。ガードレールは有用な防御層ですが、上記3パターンのいずれの代替にもなりません。

第五に、AI連携を3パターンすべてでレッドチームテストしてください。ユーザー向けチャネル（パターン2）だけでなく、イベントデータ、ログエントリ、メタデータ、バックエンドデータソース（パターン1と3）経由のプロンプトインジェクションも検証します。このシリーズのすべての脆弱性は、プラットフォーム運用組織ではなく研究者によって発見されました。テストしなければ、発見を意図の異なる第三者に委ねることになります。

パッチは適用済みですが、3つのアーキテクチャギャップは残っています。次の亜種は、未対応のパターンを突いてきます。