GrafanaGhostが明らかにしたAIセキュリティの失敗パターンは1つではなく3つ

攻撃者のURL、バックエンドプロセス、そして外部サーバー上のあなたの財務データ

2026年4月7日、Noma Securityの研究者がGrafanaGhostを公表しました。これは、Grafanaの信頼された内部プロセス自体が、意図せずデータ流出のパイプラインに変貌した攻撃です。業界ではAIのデータアクセス制御の失敗と位置付けられましたが、それだけでは不十分です—この違いは、AI搭載ツールを導入するすべての組織に影響を及ぼします。

主なポイント

1. 攻撃はイベント監視データ内にプロンプトを隠しました。攻撃者は、クエリパラメータにAIへの隠し命令を埋め込んだURLを作成し、それがGrafanaのエントリーログに記録されました。システムレベルの権限を持つ信頼されたバックエンドのエンリッチメントプロセスが、後にこの隠されたAI命令を実行—誰も要求していないダッシュボードを生成し、機密データを外部送信用の画像タグに埋め込みました。
2. Grafanaはユーザー向けデータアクセスにRBACを備えています。しかし攻撃はそれを一切発動させませんでした。GrafanaGhostはユーザーセッションではなく、システムレベルのバックエンドプロセスを通じて動作しました。ユーザーレベルのアクセス制御は無関係で、攻撃は完全にユーザー層をバイパスしました。
3. これは1つではなく3つの失敗パターンです。入力信頼境界の失敗（外部データが検証なしに処理される）、プロセス封じ込めの失敗（本来想定されていない機能範囲でバックエンドプロセスが動作）、モデルレベルのガードレールの失敗（単一キーワードで突破）。それぞれ異なる対策が必要です。
4. この入力信頼の失敗は、過去1年の主要なAI脆弱性すべてに現れています。EchoLeak、GeminiJack、ForcedLeak、Reprompt、GrafanaGhostはいずれも、信頼されていない外部データがシステムに入り、AIが検証なしに処理することから始まっています。
5. データアクセスガバナンスは1つのパターンに対応します。入力検証とプロセス封じ込めは他の2つに対応します。これらを混同すると、1つを修正しても他が露出したままになります。

攻撃者は細工したWebリクエストをGrafanaインスタンスに送信しました。リクエスト自体は目立ったものではありませんが、URLのクエリパラメータにAIへの隠し命令が含まれていました。Grafanaのイベント監視はこれらのリクエストを通常のトラフィックとして記録。悪意あるペイロードは、正規の運用データと区別がつかない形でシステム内部に保存されました。

Grafanaはエンタープライズの可観測性の中心に位置し、データベース、クラウドインフラ、財務システム、顧客データバックエンドと接続されています。ここから先が、GrafanaGhostがアーキテクチャ上で重要な理由です。

実際の攻撃の仕組み

信頼されたバックエンドのエンリッチメントプロセスが実行されました。これらはイベントデータを相関・分析・ダッシュボードやアラート用に準備するためのプロセスです。ほぼすべてのデータにアクセスする必要があるため、システムレベルの権限で動作します。複数のソースから読み込み、エンリッチした情報をデータベースに書き戻します。ユーザーにデータを提供するためのものではなく、ユーザーレベルのRBACも適用されません。

エンリッチメントプロセスが攻撃者のイベントを分析した際、隠されたAIプロンプトに遭遇し、それを実行しました。AIコンポーネントはバックエンドプロセスの特権コンテキスト内で動作し、誰も要求していないダッシュボードを生成、機密データ（財務指標、インフラのテレメトリ、顧客記録など）を画像タグ内に埋め込み、それらの画像を外部からアクセス可能にしました。

Nomaの研究者は、「INTENT」というキーワードでAIのガードレールが崩壊することを発見しました。別のURL検証の脆弱性—//attacker.comのようなプロトコル相対URL—によって、クライアント側の保護が外部ドメインを内部と誤認するよう誘導されました。データは画像レンダリングのURLパラメータとして外部に送信されました。

すべてのSIEM、DLPツール、エンドポイントエージェントは、バックエンドプロセスが通常通り動作していると認識し、何も検知しませんでした。

3つの失敗パターン

業界の議論では、GrafanaGhostを他のAI脆弱性と一括りにして「AIにはより良いガードレールが必要」というストーリーで語られています。しかしこの単純化は危険です。GrafanaGhostと、過去1年に公表されたAI脆弱性の一連の事例は、3つの明確な失敗パターンを示しています。それぞれ異なるアーキテクチャ上の対応が必要です。

パターン1：信頼されていない入力が信頼されたAIコンテキストとして扱われる

外部データが正規のチャネルを通じてシステムに入り、AIコンポーネントによって検証なしに処理されました。GrafanaGhostでは、外部データはイベントログに保存されたURLクエリパラメータでした。バックエンドのエンリッチメントプロセスは、そのデータを内部かつ信頼できるものとして扱いました。

これは、過去1年の主要なAI脆弱性すべてに共通する失敗です。EchoLeakのペイロードは、Copilotがコンテキストとして取り込んだ細工メール。GeminiJackはRAGでインデックスされた細工済みGoogleドキュメント。ForcedLeakは42,000文字のWeb-to-Leadフォームフィールドに隠されたテキスト。いずれも「外部入力はシステムで処理する前に必ず検証する」という、Webアプリケーションの入力チェックやWAFの原則がAI処理データには適用されていませんでした。

外部から取り込まれたデータは、内部に保存されたからといって信頼できるものではありません。これはゼロトラストな入力検証の問題であり、アプリケーション層やAIアーキテクチャでの対応が必要—データアクセス制御では解決できません。

パターン2：操作単位での制御がない広範なAIデータアクセス

過去1年に公表された5件の脆弱性—EchoLeak、Reprompt、GeminiJack、ForcedLeak、OpenAIプラグインエコシステムへのサプライチェーン攻撃—はいずれも、AIシステムがユーザーの代理で広範な暗黙的データアクセス権を持ち、操作単位でのポリシー適用がありませんでした。AIはセッションレベルで一度認証されると、到達可能なデータすべてにアクセスできました。

操作ごとにアクセス制御（各データリクエストをポリシーに照らして評価）を行えば、これらのケースで被害範囲を限定できました。ここでRBAC、ABAC、認証情報の分離、監査証跡が直接有効です。

GrafanaGhostはこのパターンではありません。攻撃はユーザーセッションではなく、システムレベルのバックエンドプロセスを通じて行われました。Grafanaはユーザー向けデータアクセスにRBACを備えていますが、発動しませんでした。パターン2の制御をGrafanaGhostに適用しても、根本的な問題は解決しません。

Kiteworksのデータセキュリティ＆コンプライアンスリスク：2026年予測レポートでは、ガバナンス制御と封じ込め制御の間に15〜20ポイントのギャップがあることが判明しています。操作単位の制御ギャップは現実かつ緊急の課題であり、該当する5件の脆弱性に当てはまります。

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

GrafanaGhostのバックエンドエンリッチメントプロセスには広範なデータ読み取り権限が必要でした。これは正当化できます。しかし、ダッシュボードをレンダリングしたり、画像タグを生成したり、外部サーバーにリクエストを送信する機能は不要でした。これらは本来想定されていない出力機能ですが、誰も積極的にアクセスを防ぎませんでした。

これは封じ込めの失敗です。最小権限の原則は、データアクセスだけでなく、プロセスが呼び出せるAPIやレンダリング処理、出力チャネルなどの機能範囲にも適用すべきです。データの読み書きを行うエンリッチメントプロセスが、外部と通信する機能を持つべきではありません。

OpenAIプラグインのサプライチェーン攻撃もパターン3の失敗です。エージェントの認証情報がAIのアクセス可能なコンテキスト内に保存されていたため、侵害されたプラグインコードからアクセス可能でした。認証情報の分離がなかったため、47社で6か月間アクセスが継続しました。

モデルレベルのガードレール崩壊—最初の防御ではなく第3層

Grafanaはプロンプトインジェクション対策を構築していましたが、単一のキーワードで突破されました。これはより広範な研究とも一致しており、主要なLLMはほぼ完全な成功率で脱獄されています。2026年2月のAgents of Chaos調査では、AIエージェントがインフラを破壊し、PIIを本番環境で漏洩させる事例が記録されました。

モデルレベルのガードレールは有用な防御層ですが、入力検証（パターン1）、操作単位のアクセス制御（パターン2）、プロセス封じ込め（パターン3）の代替にはなりません。仮にガードレールが機能していたとしても、GrafanaGhostの根本的なアーキテクチャ—信頼されていない入力が過剰な機能範囲を持つ特権プロセスに到達する—は依然として破綻していました。

Kiteworksの役割—対応できる範囲とできない範囲

GrafanaGhostから得られる教訓と、それぞれの制御がどのパターンに対応するのかを正確に理解することが重要です。

Kiteworksは、RBAC・ABACポリシー適用、OSキーチェーンに格納された認証情報によるOAuth 2.0認証、レート制限、SIEMに連携する改ざん検知付き監査証跡を備えたガバナンスデータレイヤーを提供します。AIシステムがKiteworks経由でデータをリクエストする場合—Secure MCP ServerやAI Data Gateway経由—すべてのリクエストはAIモデルとは独立して認証・認可・記録されます。

これらの制御はパターン2—AIがユーザーの代理でデータアクセスする場合—に対応します。AIシステムが広範な暗黙的アクセス権を持ち、操作単位の制御がない5件の脆弱性—EchoLeak、Reprompt、GeminiJack、ForcedLeak、OpenAIプラグイン攻撃—において、操作単位のABAC、認証情報の分離、監査証跡は被害範囲の縮小と検知を直接可能にします。

GrafanaGhostはパターン1＋パターン3です。攻撃はシステムレベルのバックエンドプロセスを通じて行われ、ユーザー向けAIリクエストではありませんでした。データアクセス制御—Kiteworksを含む—はデータアクセスの問題には対応しますが、入力検証の失敗（信頼されていないイベントデータの未検証処理）やプロセス範囲の失敗（エンリッチメントプロセスが本来不要な出力機能を持つ）には対応しません。

KiteworksがGrafanaGhostの教訓に貢献できるのは、「独立性」の原則です。AIモデルの下層、AIのコンテキスト外、AIがどんな命令を受けても独立して動作するセキュリティ制御。この原則を入力信頼境界やプロセス機能範囲にも拡張することが、GrafanaGhostが示すアーキテクチャ上の課題です。

セキュリティリーダーが取るべきアクション—3つのパターンすべてへの対応

パターン1（入力信頼）: AIが処理するすべてのデータソース—イベントログ、メール、共有ドキュメント、フォーム送信、APIレスポンス—を監査してください。外部入力がAIコンポーネントで処理される可能性がある場合、その入力は敵対的であると見なします。Webユーザー入力に適用しているのと同じ検証手法をAI処理データにも適用してください。

パターン2（データアクセス範囲）: すべてのAIデータリクエストに対し、操作単位での認証とABACを必須とします。認証情報はAIのコンテキスト外に保存します。完全な責任追跡が可能な改ざん検知付き監査証跡をSIEMに連携してください。

パターン3（プロセス封じ込め）: バックエンドAIプロセスの機能範囲を必要最小限に限定します。広範なデータ読み取り権限は必要かもしれませんが、コンテンツのレンダリング、外部リクエスト生成、ユーザー向けダッシュボードの構築などの機能は不要です。プロセスができることを制限し、アクセスできるデータだけでなく機能自体を制御してください。

すべてに共通: AI統合部分をレッドチームでテストしてください。GrafanaGhostはディフェンダーではなく研究者によって発見されました。イベントデータ、ログエントリ、メタデータ経由のプロンプトインジェクションもテスト対象に含めてください—ユーザー向けチャネルだけでなく。

GrafanaGhostにはパッチが適用されました。しかし、3つのアーキテクチャ上の教訓—AI処理前の信頼されていない入力の検証、操作単位のデータアクセス制御、プロセスの機能範囲封じ込め—は未解決のままです。