LLMアプリケーションにおけるAuthorization

(osohq.com)

12 ポイント投稿者 GN⁺ 2025-07-31 | まだコメントはありません。 | WhatsAppで共有

大規模言語モデル（LLM）は人間のユーザーによる不確実な入力を処理する予測不可能なシステムであるため、最小権限の原則（least privilege）の適用が不可欠
LLMは実際には社内検索・自動化などさまざまな業務に活用されており、最小限の権限だけが付与された「実効権限（effective permissions）」 の範囲でのみ動作させることで、セキュリティ事故や誤用を防止できる
RAG（検索拡張生成）アーキテクチャでは、データの埋め込みと権限チェックをデータソースから分離するため、リソースレベルでの精密な権限制御が必要
外部（3rd party）データ/RAG、Agent、MCP など複雑な活用が増えるほど、実際にどこでどのように権限を適用するかがセキュリティの中核的な課題として浮上する
OAuth などのトークンベース認証には、リソース単位の細かな権限制御に限界があるため、実際の権限ロジックはアプリケーションレイヤーで直接実装する必要がある

用語と基本概念

Prompt: LLMに渡すユーザーのリクエスト（命令文、質問など）
RAG（Retrieval-Augmented Generation）: プロンプトに追加データを添付して LLM の応答精度を高めるワークフロー（例: 会社の休暇一覧を自動で添付）
Context: プロンプトに添付される補助データ（検索された関連資料など）
Embedding: テキストを数値化したベクトル表現で、データ検索やマッチングに活用される
Agent: プロンプトに応じてアクションを実行する LLM ベースの実行エンジン（ツールの自動呼び出しなど）
Tool: LLM が直接呼び出せる API / アプリケーションなどの外部機能
Model Context Protocol（MCP）: Anthropic が提案した、LLM のツールアクセス向け標準プロトコル

Golden Rule:

LLM は、ユーザーのリクエストを処理するのに本当に必要な最小権限だけで動作すべき
人間のユーザーには「慣行的な過剰権限」がある程度許容されることもあるが、LLM は予測不可能で高速に動作し、ミスをすると大規模な被害を生む可能性がある。
→ LLM の「実効権限（effective permissions）」は、ユーザー・LLM・タスク権限の積集合に限定すべき

LLMアプリケーションの実効権限 =
1. LLM が持つ権限
2. ユーザーが持つ権限
3. 要求されたタスクに必要な権限
  この3つの積集合
ユーザーは LLM（チャットボットなど）に自分の役割を「委任（impersonation）」するが、
LLM とユーザーが持つ権限範囲のどちらも超えてはならない
権限のベン図で直感的に説明できる
- タスク権限が積集合に完全に含まれるときにのみ実行を許可

例: 社内チャットボットが社内ソースコードから「秘密鍵が含まれたファイル」を見つけるケース
Embedding: すべてのファイルをベクトルに変換して DB に保存し、プロンプトもベクトル化して類似度ベースでマッチング
権限の適用箇所:
- 検索結果として返された「ファイル」の実際の所有組織、種類、リポジトリ、ユーザー権限を即時に確認
- ユーザーがそのファイルにアクセス可能かを確認（リソースレベル権限）
- 埋め込み → ソースデータの接続過程でアプリケーション層で権限チェック
LLM 自体に権限ロジックを組み込むのは不安定（確率的な特性上、保証できないため）
整理:
- RAG の核心は、埋め込みと元データを結びつけた後にユーザー別 / リソース別の権限を強力に適用すること

外部 API / システム（例: Wiki、チケットシステムなど）のデータを埋め込んで活用
問題点: 埋め込みと元データが別々のシステムに存在するため、どこで権限を適用するかが曖昧
権限処理の3つの方法
1. 外部システムに権限を委譲する（API の各リクエストごとに実際の権限を確認するため、応答が遅くレート制限の問題もある）
2. ACL（アクセス制御リスト）をアプリケーションに同期する（精度と信頼性は高いが、ACL の管理・同期コストが増える）
3. 外部の権限ロジック自体を内部に再実装する（管理・同期負担が増え、ロジックも複雑になる）
結論: 実際の状況に応じて「権限を適用する場所」と方式の trade-off が重要
（性能と簡潔さ、管理コストと精度などの選択が必要）

例: チャットボットがリポジトリのブランチ削除や Issue のクローズなど、自動メンテナンス作業を行うケース
MCP（Model Context Protocol）により、ツール（関数 / API）を標準化された方法で LLM に公開する
MCP の各リクエストごとに実効権限モデルを適用する必要がある
（ユーザー / エージェント / タスク権限の積集合）
OAuth などのトークンベース認証の限界
- 権限情報はトークンに含められるが、リアルタイムの資源 / リソース単位の権限まではカバーできない
- 実際にはトークンに一部の情報だけを入れ、残りはアプリケーション層で別途権限ロジックを実装する必要がある

LLM / RAG / Agent 環境における権限管理の核心は「どこで、どのように権限を適用するか」を選定すること
実効権限モデルによって、LLM が「ユーザー + LLM + タスク」の積集合の中でのみ動作するよう制限する
OAuth などの認証トークンは「誰がリクエストしたか」を識別するためにのみ使い、
実際のリソース別権限検証は必ずアプリケーションで実行する
外部システム連携時には、
1) 権限を委譲（性能低下）、2) ACL 同期（運用複雑化）、3) 権限ロジック再実装（高い保守負担）
など、さまざまな trade-off を考慮して設計する必要がある
最終要約:

LLM は、ユーザーのリクエストを処理するのに本当に必要な最小権限の範囲内でのみ動作すべきであり、
実効権限（effective permissions）は LLM の権限、ユーザーの権限、タスク権限の積集合として定義される
実際の権限検証は、リソースごとにアプリケーション層で必ず実行しなければならない