第3章 データ保護と権限

学習目標

• 機密情報が入力からログまでのデータライフサイクルのどこで漏れるかを見つけ、最小化する。
• 過剰な代理権を機能・権限・自律性に分けて診断し、ツール設計で権限を縮小する。
• エージェントが誰の権限で実行するかを決め、委任トークンとスコープを最小化する。
• モデル出力を信頼しない入力として扱い、到着先に合わせて安全にレンダリング・処理する。
• システムプロンプトとベクトルストアに関するよくある誤解を正す。

はじめに

ある通販サイトの相談チャットボットは、正確に回答するために顧客アカウント全体を照会するツールを使っていました。配送に関する問い合わせ1つで、住所、電話番号、最近の注文10件、ポイント履歴までコンテキストに入りました。たいていの日は何も起きませんでした。ところがある顧客が家族共用のアカウントで「先月の注文一覧を全部見せて」と尋ねると、ボットは親切に他の家族の注文まで表示しました。モデルは間違えていません。受け取ったデータを忠実に整理しただけです。チームは急いでプロンプトに「他人の情報は話すな」を追加しましたが、同じアカウントの家族の誰が今尋ねているのか、モデルには知るすべがありません。解決策はプロンプトではなく、照会ツールにありました。

第2章が「攻撃者の指示はどう入るか」を扱ったのに対し、この章は「入ったときに何までできるか」を扱います。モデルはコンテキストに入った内容を出力でき、手元のツールでできることをします。したがってデータと権限の削減は、インジェクション対策の半分を占めます。この章では機密情報の経路と最小化から始め、外部AIサービスのデータ条件、システムプロンプトとベクトルストア、過剰な代理権とツール権限の設計、委任と身元を順に扱い、最後にモデル出力を安全にレンダリング・処理する方法を学びます。

重要な概念

機密情報はどこで漏れるか：データライフサイクル

OWASP LLM02（Sensitive Information Disclosure）は、個人情報、金融情報、健康記録、機密業務データ、認証情報、法律文書がモデル出力を通して露出するリスクを扱います。ユーザーが入力したデータが後にモデル出力に再び現れる可能性も指摘しています。最終回答だけでは多くを見落とすため、ライフサイクル全体をたどります。

OWASPは、システムプロンプトで「この種のデータは返すな」と制限する方法は助けになるものの、常に守られるわけではなく、インジェクションで回避されうると警告しています。最も確実な保護は、初めからモデルに見せないことです。

最小化・マスキング・仮名化

データ最小化は、「業務に必要なフィールドだけを、必要なときに渡す」という原則です。配送の問い合わせに必要なのは配送状態と予定日で、住所全体ではありません。この原則をプロンプトではなくツール設計で実装します。顧客レコード全体を返すツールの代わりに、「この注文の配送状態」だけを返すツールを作ります。韓国の「個人情報の安全性確保措置基準」も、個人情報の出力時は用途を特定し、用途に応じて出力項目を最小化するよう求めています。LLMコンテキストへの受け渡しも、同じ考え方で設計できます。

渡さざるをえない値はマスキングします。

トークン化を使うと、対応表が新たな重要資産になります。モデルと同じストアには置かず、暗号化して保管し、アクセスを別途制御・記録します。外部に送る前にマスキングし、応答を受けた後で必要な箇所だけ元の値に戻します。

外部AIサービスへ送るデータの条件

外部の提供元のモデルを使うと、データは組織の境界を越えます。確認すべき質問は、学習に使われるか、不正利用の監視のためにどれくらい保管されるか、アプリケーションの状態（会話、ファイル、ベクトルストア）はいつまで残るか、保管を減らすオプションをどのような条件で使えるか、どの地域に保存されるか、です。

OpenAIのデータ管理文書を例にすると、次のようになります。APIを通じて送ったデータは、ユーザーが明示的に同意しない限り、モデルの学習には使われません。不正利用を監視するログは最大30日間保管されますが、法律によって要求される場合や、サービスと第三者を害から守るために必要な場合は、それより長く保管されることがあります。データの保管を減らすZero Data RetentionとModified Abuse Monitoringは、事前に承認を受けなければ利用できません。一部の機能は、ユーザーが削除するまでアプリケーションの状態を保管します。条件は機能や契約ごとに異なるため、公式文書と契約書を機能単位で確認し、確認した日付を記録します。国外の提供元に個人情報を送る場合は、韓国の個人情報保護法第28条の8の国外移転要件（別途の同意、または法律で定める例外）についても、個人情報保護責任者と一緒に確認します。

システムプロンプトは秘密ではない

OWASP LLM07の要点は、「システムプロンプトを秘密とみなしたり、セキュリティ統制として使ったりしてはならない」です。同じ文書は、文言の露出自体よりも、その中に置いた機密情報と権限構造が本当のリスクだと説明しています。

権限分離と認可検査は、モデルの外で、決定的かつ監査可能な方法で行います。アクセス水準の異なる作業は、最小権限の複数エージェントに分けます。目標は「プロンプト全体が公開されても何も起こらない設計」です。OWASPの2026年版はこの項目をHidden Context Exposure（LLM08:2026、隠れたコンテキストの露出）に広げ、開発者の指示、検索して取り込んだポリシー文言、ツールスキーマまで同じ原則で扱っています。

RAGとベクトルストアの権限

OWASP LLM08（Vector and Embedding Weaknesses）は、アクセス制御の失敗とデータ漏洩、複数のユーザー集団がストアを共有する際のコンテキストをまたぐ漏洩、埋め込みから原文の相当部分を復元する埋め込みの逆変換、索引データの汚染を挙げています。緩和策は、権限を認識するベクトルストアと厳格な分割、知識ソースの検証、結合データのレビューと分類、検索活動の変更不能なログです。

設計原則は「権限は生成前の検索段階で適用する」です。権限のない文書をモデルが読んでから「この文書は話すな」と指示するのは、プロンプトを統制に使う誤りです。検索クエリ自体に要求者の権限条件を付ける事前フィルタリングで、許可された断片だけを受け取ります。文書の権限変更や削除時は、インデックスの断片とキャッシュも更新しなければなりません。原本から消した文書がインデックスに残って検索され続けることはよくあります。埋め込みも原文と同等に機微なデータとして扱ってください。数値配列であることは保護にはなりません。

過剰な代理権：3つの根本原因と8つの予防策

OWASP LLM06（Excessive Agency）は、予想外、曖昧、または操作されたモデル出力に応じて有害な行動を実行できてしまう脆弱性です。原因がハルシネーションでもインジェクションでも、モデルの判断が誤ったときに何まで起こるかが要点です。根本原因は3つあります。

2025年版が示す予防策は8つです。拡張機能（ツール）数の削減、各ツールの機能の削減、汎用ツールの回避、ツール権限の削減、ユーザーのコンテキストでの実行、ユーザー承認、完全仲介、入出力のサニタイズです。2026年版（LLM03:2026）は入出力のサニタイズを外して7つに整理しました。ログ・モニタリングとレート制限は被害を小さくするものの、過剰な代理権自体の予防にはならないとして別に分類しています。

完全仲介（complete mediation）は、「許可の判断はモデルではなく下位システムがリクエストごとに行う」という原則です。入館証の確認を案内係の記憶ではなく、入口の装置が行うようなものです。モデルは入館証を偽造できなくても、案内係を説得できるかもしれません。

ツール権限の最小化を設計に落とし込む

ツール権限の最小化は、原則だけでなくツール仕様として示す必要があります。OWASP AI Agent Security Cheat Sheetは、ツールごとに読み取りと書き込み、対象リソースを分けて権限を定め、信頼水準が異なるエージェントには別々のツール群を与え、未知のツールが指定されたり承認要件が欠けたりする場合には、実行を拒否するフェイルクローズ（fail closed）にすることを勧めています。

{
  "name": "reschedule_my_booking",
  "description": "ログイン中のユーザー本人の予約1件の日付を変更する。実行前にユーザー確認が必要。",
  "input_schema": {
    "type": "object",
    "properties": {
      "booking_id": { "type": "string", "pattern": "^BK-[0-9]{8}$" },
      "new_date": { "type": "string", "format": "date" }
    },
    "required": ["booking_id", "new_date"],
    "additionalProperties": false
  }
}

スキーマはモデルが不適切な形の引数を作らないよう助ける仕組みで、本当の統制はサーバーにあります。サーバーは、その予約がログインユーザーのものか、新しい日付が許容範囲か、ユーザーが確認したかをリクエストごとに再検査します。

委任と身元：誰の権限で実行するのか

エージェントがユーザーに代わって他のシステムを呼ぶときは、「誰の権限で」が明確でなければなりません。すべての呼び出しが強い権限を持つ共用サービスアカウントから行われると、モデルをだましたユーザーはそのアカウントが届くすべてのデータに届き、ログには要求者が残りません。OWASP Agentic Top 10は、エージェントに管理された固有の身元がなければ真の最小権限を強制できないとし、ASI03（Identity and Privilege Abuse）の原因に挙げています。OWASP LLM06は、代理行動をそのユーザーのコンテキストで、たとえば最小限のOAuthスコープによる認証を使って最小権限で実行するよう求めています。MCPのセキュリティベストプラクティスは、委任構造の落とし穴を具体的に示しています。

トークンをそのまま転送すると下流APIのレート制限や監査記録が無効になり、盗んだ人が中継サーバーを漏洩経路に使えます。最初から広いスコープを得ておくと、1つのトークンが漏れた瞬間にすべてのツールが開きます。

出力は信頼しない入力である

OWASP LLM05（Improper Output Handling）は、モデル出力を下流の構成要素へ渡す前に検証・サニタイズ・処理しない欠陥です。出力はプロンプトで操作できるので、そのまま使うことはユーザーに下流機能への間接アクセスを与えるのと同じです。OWASPはモデルを「他のユーザーと同じように」扱うゼロトラストの考え方を勧めています。

モデルの特権がユーザーより大きい場合、間接インジェクションに弱い場合、出力が文脈に合わせてエンコードされていない場合に影響が拡大します。モデルが架空のパッケージ名を出し、その名前で攻撃者が公開した悪意あるパッケージをインストールするリスクも、OWASPはこの項目とLLM09で扱っています。

出力の安全なレンダリング

モデル出力を画面に描く際は、ユーザー入力を描くときと同じルールに従います。OWASP XSS Prevention Cheat SheetをLLM出力に適用すると、次のようになります。

1. 基本はテキストで描画します。innerHTMLの代わりにtextContentなど、データをテキストとしてだけ扱う方法を使います。
2. 書式が必要ならMarkdownレンダラーの生HTMLを無効にし、許可リスト方式のサニタイザーで結果を処理します。OWASPはHTMLのサニタイズにDOMPurifyを勧めています。
3. フレームワークのエスケープを迂回する機能（ReactのdangerouslySetInnerHTMLなど）は、サニタイズなしで使いません。
4. リンクと画像を許可リストに限定します。外部画像を自動取得しなければ、画像URLにデータを載せる持ち出し経路を塞げます。リンクはスキーム（javascript:など）とドメインを検査し、必要ならクリック前に実際のURLを表示します。
5. CSP（Content Security Policy）は追加の防御層です。OWASPはCSPを主要な防御手段にしないよう求めています。
6. ストリーミング出力は全断片がそろう前に描画されるため、未処理の途中結果が画面に出ないかを確認します。

<!-- 悪い例：モデル出力をそのままHTMLとして解釈 -->
<div id="answer"></div>
<script>answer.innerHTML = modelOutput;</script>

<!-- 改善例：テキストとして描画し、書式はサニタイズ済みの結果のみ -->
<script>answer.textContent = modelOutput;</script>

モデルが選ぶURLとコード：SSRFとコード実行

モデルが作った値でサーバーがリクエストを送ったりコードを実行したりすると、出力処理のリスクがサーバー内部に入ります。モデルの選んだURLをサーバーがそのまま取得すると、インジェクションによって内部管理ページやクラウドのメタデータURLに変えられます。サーバーサイドリクエストフォージェリ（SSRF、Server-Side Request Forgery）です。MCPのセキュリティベストプラクティスは、OAuth関連URLを取得するクライアントに対し、本番ではHTTPSを要求し、プライベート・ループバック・リンクローカルのアドレス帯を遮断し、リダイレクト先も同じ基準で検査し、内部宛先を止めるエグレスプロキシを使うよう勧めています。エンコードの細工を見落としやすいため、IP検証を自作しないようにも警告しています。この原則はモデルがURLを選ぶすべてのツールに適用できます。

生成したコードや命令を、十分な検証と隔離なしに実行すると、OWASP Agentic Top 10のASI05（Unexpected Code Execution）につながります。基本原則は「実行せずに済むなら実行しない」です。必要なら、最小権限の専用コンテナか仮想マシンで、ネットワークとファイルへのアクセスを制限し、シークレットなしで動かします。Anthropicのcomputer useツールの文書も、最小権限の専用仮想マシンやコンテナ、ドメイン許可リスト、ログイン情報などの機密データの隔離を予防策に挙げています。

さらに深く

承認と実行を結びつける

人による確認を設けても、「ユーザーが見たもの」と「実際に実行されるもの」が異なれば、確認は意味を失います。承認画面には「会議日程の変更」と表示されていたのに、実際の呼び出しの引数には参加者10人の追加が含まれているかもしれません。また、長いタスクの途中でユーザーの権限が取り消されたにもかかわらず、タスクの開始時に得た承認を使って最後まで実行してしまう場合もあります。これは、検査する時点と使用する時点がずれる問題（TOCTOU、Time-of-Check to Time-of-Use）です。

実行に結び付いた承認には、次の仕組みを備えます。承認の依頼には、対象、引数、予想される効果を元の値で含めます。承認はその引数のハッシュとあわせて保存し、実行の直前に引数が同じかどうかを比較して、異なる場合は改めて確認します。承認には有効期間と1回限りの使用制限を設けます。そして、実行の直前にユーザーの現在の権限を再確認します。OWASP AI Agent Security Cheat Sheetが勧める「実行前の行動のプレビュー」と「取り消し」も、この設計と組み合わせます。

派生データの隔離：キャッシュ・メモリ・要約・エクスポート

原本ストアの権限が完璧でも、派生経路でデータが混ざります。応答キャッシュのキーにユーザーや組織の識別子がなければ、似た質問をした別組織に前の組織の回答が届きます。共有要約を複数チームで再利用すると、要約に含まれる機密が無権限のチームに届きます。会話のエクスポートや共有リンクは、元の会話の権限検査を通らないことも多くあります。

点検する質問は1つです。「この派生物は原本の権限境界を継承しているか」。キャッシュキー、メモリストア、要約ストア、出力ファイル、埋め込みのインデックスごとに答え、「いいえ」の場所はユーザー・組織の範囲を付けるか、再利用を禁止します。OWASP AI Agent Security Cheat Sheetも、ユーザー間・セッション間のメモリ隔離を独立項目にしています。

実務の場面

オンセミロ病院：予約エージェントから診療記録を取り除いた理由

総合病院「オンセミロ病院」は、診療予約エージェントを導入しようとしています。初期案では、病院全体の患者DBに読み書きできるサービスアカウントを使い、回答の質のために患者の最近の診療記録すべてをコンテキストに入れ、予約変更を即時実行していました。アプリ画面には案内文をHTMLで描き、システムプロンプトには内部予約APIのURLとキーがありました。

レビュー担当者は3つの根本原因で診断しました。機能面では予約に診療記録照会が必要かを問い、必要なのは予約可能時間と本人の予約一覧だけだとわかりました。診療記録照会ツールは外しました。権限面では書き込みを予約テーブルに縮め、ログイン患者本人のトークンで呼び出すようにしました。予約サーバーが毎回「この患者がこの予約を変更できるか」を直接検査します。自律性面では、キャンセルと他の診療科への変更は、患者が日付・診療科・医療スタッフを画面で確認してから実行するようにしました。

出力とシークレットも点検しました。案内文はテキストとして描画し、太字とリストだけを許すサニタイザーを通し、リンクと画像は病院ドメインだけにしました。プロンプト内のAPIのURLとキーはサーバー設定とシークレットストアへ移し、すでに露出していたキーは無効化して再発行しました。

「診療記録があれば、よりよく医師を推薦できる」という反論には、診療科と担当医の2フィールドだけを返すツールで対応しました。結果として、エージェントがだまされてもできることは「本人の予約を見せ、確認を得て変更すること」に縮まりました。残余リスクは「患者が画面を読まずに承認すること」と記録し、キャンセル後24時間以内の取り消し機能を次四半期の課題に残しました。

くじらマーケット：同じ1文が3か所で異なる危険を持つ

中古品取引プラットフォーム「くじらマーケット」は、販売者が写真と短いメモを投稿すると、モデルが出品のタイトルと説明を書く機能を作りました。説明の行き先は3つです。公開出品ページにMarkdownで描画され、運営チームの検品画面に表示され、毎週の運営報告用CSVとして出力されてスプレッドシートで開かれます。

ベータ期間に2つのことが見つかりました。販売者がメモに入れたHTML断片をモデルがそのまま説明に転記し、検品画面の書式が崩れ、スクリプトタグが画面に混ざりました。幸い画面はテキストとして描画していたため実行されませんでした。また、一部の説明には販売者がメモで誘導した外部決済サイトへのリンクがありました。運営チームは「モデルにHTMLとリンクを書かないよう指示しよう」と提案しました。

セキュリティ担当者はその指示を補助手段としてのみ採用し、到着先ごとに統制を置きました。公開ページは生HTMLを無効にしたMarkdownレンダラーと許可リスト方式のサニタイザーを通し、リンクはプラットフォームのドメインだけ、画像はアップロードした写真だけにします。検品画面はテキスト表示で、元のメモと生成した説明を並べます。CSV出力は数式文字で始まるセルに単一引用符やタブを前置してテキストとして解釈させました。スプレッドシートごとに挙動が違い、万能なサニタイズ方法はないというOWASPの警告に従い、実際に運営チームが使うソフトで結果を試験しました。

教訓は「同じ出力でも到着先によってリスクと統制は違う」ということです。モデルへの1行の指示に頼っていれば、無視された日に3か所が同時に開いていたでしょう。

間違えやすいポイント

1. 「プロンプトに禁止ルールを書けば、権限制御になる」。そのルールを守る主体は、依然としてモデルです。許可するかどうかは、下位システムがリクエストごとに判断する必要があります。
2. 「自社のモデルが作った出力なので、信頼してよい」。出力には、モデルが読んだ外部コンテンツとユーザーの入力が反映されます。レンダリングと実行の前に、ユーザー入力とまったく同じように扱います。
3. 「ユーザーには見えないので、システムプロンプトにキーを置いてもよい」。見えないことは、保護の手段ではありません。キーは、モデルが直接アクセスできない場所に置きます。
4. 「精度のためには、データを多く入れるほどよい」。データを入れた分だけ、露出する範囲が広がります。必要なフィールドだけを返すツールを作ってください。
5. 「埋め込みは数値なので、安全である」。埋め込みの逆変換によって、原文の相当な部分が復元される可能性があります。原文と同じ水準でアクセスを制御します。
6. 「ロギングとレート制限を導入したので、過剰な代理権は解決した」。OWASPは、この2つを被害を小さくする手段として分類しています。予防に当たるのは、機能・権限・自律性を減らすことです。
7. 「スキーマ検証を通過したので、安全な引数である」。形式が正しくても、対象や金額が誤っている可能性があります。サーバーが業務ルールを再確認し、リクエストごとにそのオブジェクトへのアクセス権限も再確認します（OWASP Authorization Cheat Sheet）。
8. 「CSPがあるので、出力のエンコードは省略してもよい」。CSPは追加の防御層です。文脈に応じたエンコードとサニタイズが先に必要です。

ひと目でわかるまとめ

公式ドキュメントで確認する

• OWASP LLM02:2025：機密情報の露出とサニタイズ・マスキング。
• OWASP LLM06:2025：過剰な代理権の3つの根本原因と予防策。
• OWASP LLM05:2025：出力先ごとのリスクと統制。
• OWASP LLM07:2025：システムプロンプトに置いてはいけないもの。
• OWASP LLM08:2025：権限を認識する検索と分割。
• OWASP XSS Prevention Cheat Sheet：エンコード、サニタイズ、CSPの位置づけ。
• MCP Security Best Practices：委任トークン、SSRF、スコープ最小化。
• OpenAI — Data controls：学習利用と保存条件。

セルフチェック

3-1. 最終回答以外に機密情報が残るか漏れるライフサイクル上の場所を3つ挙げ、それぞれの基本統制を1つずつ書いてください。

3-2. OWASP LLM06が予防策と分けて「被害を小さくする手段」とする2つを挙げ、予防策ではない理由を説明してください。

3-3. 完全仲介の原則を1文で定義し、違反する設計の例を1つ挙げてください。

3-4. 外部LLM APIの提供元のデータ条件を検討するとき、機能単位で確認すべき項目を4つ書いてください。

3-5. モデル出力をWeb画面に描く基本方式、書式付きHTMLが必要な場合の方式、CSPとこの2つとの関係を、それぞれ1文で書いてください。

3-6. MCPのセキュリティベストプラクティスが状態ハンドルについて禁止することと、代わりにサーバーが行うことを書いてください。

3-7. 設計課題：社員の予定を読み、会議室を予約する社内アシスタントがあります。ツールを3つ以内で設計し、それぞれの機能・権限・ユーザー確認の有無を1行ずつ書いてください。

実習課題