AI認証と認可
この記事では、RAG、ツール使用、エージェントシステムの3つのユースケースを通じて、AIセキュリティの基本原則を説明します。それは、アイデンティティ層は決定論的であるべきであり、AIは確率的であるということです。銀行を例に、既存のOAuthと細粒度認可パターンをAIシステムの保護に活用する方法と、エージェントにおけるアイデンティティチェーンの重要性を強調しています。
AI認証と認可
著者：Dan Moore
人間のアイデンティティはAIの権限の源です。あなたはこう思っているでしょう：またAIセキュリティの記事？ちょっとお付き合いください。この記事が違うのは、業界がエージェントのリリースを急ぐ中で忘れ去られている単純でほぼ自明な真実に基づいているからです。それは、2010年代のAPIブームを保護したのと同じアイデンティティと認可パターンが、今日のAIシステムを保護するためにまさに必要だということです。
OAuth統合を構築したことがある、APIキーを管理したことがある、またはロールベースのアクセス制御を設定したことがあるなら、必要な知識のほとんどはすでに持っています。AI認証は新しい分野ではありません。既存のベストプラクティスの拡張です。
「乱数を生成する算術的方法を考える者は、もちろん罪の状態にある。」— ジョン・フォン・ノイマン
「決定論的な安全策なしにAIにリソースへのアクセスを許す者は、もちろん愚かさの状態にある。」— 著者
フォン・ノイマンの引用は、信頼できるものから非決定論的な出力を得られると仮定することへの古典的な警告です。逆の原理がここに当てはまります。AIシステムは確率的です——推論し、幻覚を見、即興で動きます——しかし、誰のために行動し、何を許可するかを統治するアイデンティティ層は決定論的でなければなりません。アイデンティティは「雰囲気」で決めるものではありません。
この記事では、3つのAIユースケース（検索拡張生成（RAG）、ツール使用（MCPおよびAPI）、エージェントシステム）を取り上げ、銀行を背景に、認証、認可、アイデンティティ管理の観点から検討します。FusionAuthの例を使用しますが、標準ベースのソリューションにも触れます。
ユースケースの概要
詳しく見る前に、何を扱うか定義しましょう。
検索拡張生成（RAG）は、クエリ時にAIモデルが利用できるデータを文書で拡張します。銀行の従業員や顧客が質問をすると、RAGシステムは関連する内部文書を取得し、それをLLMに提供して回答を裏付けます。重要な認証の懸念：すべてのユーザーがすべての文書を見られるわけではありません。顧客が見る文書は、出納係が見るものとは異なり、さらに副社長が見るものとも異なります。
ツール使用（MCPおよびAPI）は、データベースからの読み取り、顧客レコードの更新、外部サービスの呼び出しなどのアクションをAIシステムに許可します。Model Context Protocol（MCP）は、AIツールをサービスに接続するための新興標準ですが、豊富なドキュメントを持つプレーンなAPIでも問題なく動作します。重要な認証の懸念：各ツールが何をできるか、誰のために行うかを制御することです。
エージェントシステムは、半自律的なタスク指向のワークフローであり、データを読み取り、複数のシステムにまたがってアクションを実行し、必要に応じて人間の入力を求めることができます。これらは、推論ステップを連鎖させる非決定論的なソフトウェアコンポーネントです。重要な認証の懸念：ワークフローを承認した人間から実行されたすべてのアクションまでのアイデンティティチェーンを維持し、エージェントのアクセスを制限することです。
以下は、これらがアイデンティティプロバイダーの機能とどのように対応するかです：
シナリオ | 認可 | 認証 | アイデンティティ管理 RAG | はい | はい（フレームワーク固有） | はい（フレームワーク固有） ツール使用 | はい | はい | はい AIエージェント | はい | はい | はい
それでは、各ユースケースを詳しく見ていきましょう。
RAG：モデルが見るべきでないものを見せない
シナリオ：あなたは、ローン契約書、顧客契約書、コンプライアンスポリシー、ウェルスマネジメントプレイブック、詐欺調査手順書など、カスタマーサポートタスクに関連する銀行文書を持っています。これらをAIインターフェースを通じて顧客と従業員がクエリできるようにしたいと考えています。しかし、すべての文書がすべてのユーザーに利用可能であるべきではありません。カスタマーサポート、詐欺とセキュリティ、紛争とチャージバック、ローンサービシングの各チームは、異なる文書セットにアクセスする必要があります。そして、顧客自身も忘れてはいけません。
LinkedIn、DoorDash、Vimeoなどの企業はすでにRAGを本番環境で使用しています。このパターンは確立されています。
なぜアイデンティティがRAGにとって重要なのか：
クエリに答えるとき、LLMはユーザーがアクセス権のない文書を決して見るべきではありません。巧妙なプロンプトを工夫する必要はありません。モデルが秘密を守ることに頼っているわけではありません。適切な認可フレームワークを使えば、文書がモデルに到達する前にフィルタリングできます。これは主に認可の問題です。ユーザーを認証し（本人であることを証明）、クエリを処理し、ベクトルストアから文書を取得し、ユーザーがクエリを許可されている文書に基づいてフィルタリングします。モデルは認可チェックを通過した文書のみを受け取ります。
実装： 実装は単純明快なパイプラインに従います:
- 文書をベクトル検索に適したチャンクに分割します。
- ユーザーとロールを文書アクセスにマッピングする認可スキーマを構築します。
- ベクトルデータベース内の文書チャンクとともにメタデータを保存します。これには、各チャンクにアクセスできるロール、部門、またはユーザーが含まれます。
- 取得時に、ユーザーを認証し、アイデンティティクレームを取得します。
- 結果をLLMに渡す前に、ステップ3で保存したユーザーと文書属性でフィルタリングします。
認証に関しては、一部のフレームワークはJWTを使用し、他のものはAPIキーを使用します。フィルタリングメカニズムはRAGフレームワークにも依存します。例えば、LangChainでは、結果を返す前に認可サービスを呼び出すリトリーバーラッパーを構築できます。
認可チェックには、細粒度認可（FGA）システムを使用します。FusionAuth FGA by Permifyは一つの選択肢です。これは、データセーフティのためにオンサイトにデプロイでき、ニーズに応じてスケールする決定論的な認可を提供します。
認可ロジックは集中化され、単一の信頼できる情報源であるべきであり、使用するRAGフレームワークに関係なく同じです。これを活用するフィルターは、確率的ではなく決定論的である必要があります。
以下は、ドキュメントのロード中に適切なメタデータが保存されている場合のリクエストフローの簡略図です。
（フローチャート省略）
しかし、そのメタデータをキャプチャするのはどうでしょうか？文書は常に特定のアクセスレベルにきれいにマッピングされるとは限らず、一部の文書はチャンクごとに異なるアクセス権を持つ場合があります。チャンク化によりメタデータが失われる可能性があります。例えば、コンプライアンスPDFには、すべての従業員がアクセスできるセクションと、法務チームに制限されたセクションが含まれる場合があります。チャンク化パイプラインがこれを処理できることを確認してください。
したがって、RAGプロセスの一部としてユーザーとアクセスメタデータをキャプチャする計画を立ててください。LLMにユーザーがアクセスすべきでない文書を絶対に見せたくないのであれば、ユーザーとアクセスデータが利用可能であることを確認しなければなりません。
ツール使用：MCPとAPI
カスタマーサービスチームメンバーがAIツールを使用して銀行の顧客情報（連絡先詳細、アカウント設定、サービスリクエスト）を更新できるようにしたいとします。しかし、異なるロールには異なるツールが利用可能であり、同じツールでもユーザーによって制限が異なります。ティア1のサポートエージェントは電話番号を更新できても、与信限度額を調整できないかもしれません。
2つのパス：MCPとAPI
Model Context Protocol（MCP）は、あらゆるAPIやサービスを構造化された方法でAIツールにアクセス可能にする新興標準です。Block、Bloomberg、Amazonなどの企業はすでに内部でMCPを使用しています。しかし、MCPだけが選択肢ではありません。プレーンなAPIでも十分に機能します。AIモデルは優れたドキュメントからAPIセマンティクスを理解できます。
公開時点での最新バージョンのMCPは、AIシステムまたはツールの認証にOAuth 2.1と認可コードグラントを使用しています。クライアントクレデンシャルグラントの使用に向けた拡張も開発中です。
APIは従来の認証方法（APIキーまたはアクセストークン）を再利用します。REST API時代から使用してきた同じゲートウェイパターンを使用して、MCPまたはAPIサーバーへのアクセスをレート制限または監視できます。
MCP実装： アイデンティティを使用してMCPを設定する方法は次のとおりです:
- 既存のAPIとサービスの上にMCPサーバーを構築します。MCPサーバーがOAuth 2.1をサポートするアイデンティティプロバイダーを指すように設定します。MCPクライアントは事前登録するか、動的に作成する必要があります。
- MCPクライアントがMCPサーバーにアクセスしようとすると、MCPサーバーは設定されたアイデンティティプロバイダーにリダイレクトし、MCPクライアントを操作するユーザーを認証してトークンを発行します。そのトークンがMCPサーバーに提示されます。
（MCPと実装についての詳細）
OAuthスコープが提供する以上の細かい制御が必要な場合は、MCPサーバーがアクセスしているサービスに細粒度認可を追加する必要があるかもしれません。
API実装： APIアクセスの場合、パターンはさらに単純です:
- 既存のAPIとサービスを使用します。MCPサーバーは不要です。
- アイデンティティプロバイダーでユーザーを認証します。
- アクセストークンを取得します。
- AIがWebツールを持っている場合、REST呼び出しを使用してAPIにアクセスし、トークンを渡します。
- APIを使用するSDKも利用可能にすることを検討してください。繰り返しますが、OAuthスコープを超える細かい制御が必要な場合は、APIとサービスに細粒度認可を追加する必要があるかもしれません。
おそらく、認証とAPIに関する既存のインフラストラクチャがあり、それを再利用できるかもしれません。例えば、複数のAPIゲートウェイがFusionAuthと連携します。
エージェントシステム：行って仕事をせよ
ここからが面白いところであり、AI認証に新しい考え方が必要とされる場所です。
エージェントは、さまざまなレベルの自律性でタスクを完了するようにプロンプトできる非決定論的なソフトウェアコンポーネントです。それらは数十から数百のインスタンスにスケールし、人間、API、MCPツールと対話し、推論ステップを連鎖させます。
シナリオ： 銀行が新しいビジネスアカウントのセットアップを自動化したいと考えています。新しいビジネスには、当座預金口座、普通預金口座、マーチャントサービス、給与設定が必要です。エージェントは以下を行う必要があります:
- ビジネスタイプを評価し、パッケージを推奨する
- ドキュメントストアからビジネス書類（EIN、定款）を収集する
- APIを介して信用力を確認する
- カレンダーサービスを介してリレーションシップマネージャーとのオンボーディングミーティングをスケジュールする
これは複数ステップのワークフローであり、乱雑なデータと外部サービスを扱います。これはまさにエージェントが得意とする分野です。しかし、それはまた、エージェントが機密文書を読み、外部APIを呼び出し、人間に代わって会議をスケジュールすることを意味します。リスクは高いです。
アイデンティティチェーン：
エージェントを保護するための基本概念：誰がいつ何を承認したかを知る必要があります。
人間がエージェントワークフローを開始すると、その人間のアイデンティティはすべてのステップでエージェントと共に移動する必要があります。エージェントがファイルを読む場合、どの人間がその読み取りを承認したかを知る必要があります。エージェントが会議をスケジュールする場合、誰のために行っているかを知る必要があります。問題が発生した場合、発信者まで遡れる監査証跡が必要です。
この監査証跡がアイデンティティチェーンです。
人間のアイデンティティをどの程度深く保持するかは、ニーズによって異なります。各ステップで認可チェックを行う場合、必要なアイデンティティはルールに依存します。主にログ記録とデバッグを行う場合は、人間のアイデンティティと現在のエージェントのアイデンティティのみで十分かもしれません。スケジュールトリガーによるエージェントワークフローの場合、チェーンはサービスアカウントまたはcronジョブの作成者から始まる可能性があります。
署名付きJWTを使用してこれを実装し、アイデンティティチェーンがシステム全体で保持されることを保証します。
FusionAuthは現在OAuthトークン交換（RFC 8693）をサポートしていませんが、Vend JWT APIは同じアイデンティティチェーンセマンティクスを実現します。アイデンティティプロバイダーがトークン交換をネイティブでサポートしている場合、それは標準ベースの代替手段です。
FusionAuthのVend JWT APIを使用すると、元のユーザーを埋め込み、アイデンティティを伝播するトークンを作成できます。