本記事は「Is your auth ready for AI? Why identity is the first thing developers need to fix」を翻訳した記事です。
多くのエンジニアリングチームは、最初にLLMプロバイダーのスケーリング問題に直面するわけではありません。アイデンティティプロバイダーのスケーリング問題に直面します。
AI機能がサイドバーのチャットボットからアクションを実行するエージェントへ移行するにつれて、異なる時代に構築されたアプリケーションアーキテクチャの上に組み込まれています。既存のシステムは予測可能な世界に向けて設計されていました。人間のユーザーがボタンをクリックし、フロントエンドがセッションCookieとともにリクエストを送信し、バックエンドがデータベースと照合してCookieを検証します。処理は直線的かつ同期的であり、監査も容易です。
AIエージェントは従来のルールに従いません。非同期で動作し、イベント駆動型のワークフローをトリガーし、人間が何もクリックしなくても分散サービス間で連携します。アイデンティティ層が依然としてブラウザを操作する人間を前提としたモデルにとらわれている場合、AI機能が制限されるだけでなく、重大なセキュリティリスクになります。
AIはデータモデルを破壊する前に、認証を破綻させます。コンバージョンと信頼をもたらすアプリケーションを構築するには、アイデンティティを周辺機能から主要なアーキテクチャの柱へ移行する必要があります。
認証はもはや機能ではなくインフラストラクチャ
認証はかつてアプリケーションの境界に存在していました。セッション開始時に一度だけ対応するゲートキーパーでした。しかし、分散システムや自律型エージェントへ移行するにつれて、アイデンティティはすべてのマイクロサービスのリクエストパスに組み込まれるようになりました。
状況は3つの基本的な方向で変化しました。
- アプリから分散システムへ: もはや単一のモノリスを保護するわけではありません。API、Lambda、コンテナが相互接続されたネットワークを保護します。
- ユーザーからアクターへ: システムは現在、人間、マシンツーマシン(M2M)サービスアカウント、委任された権限で動作するAIエージェントの混在を処理します。
- リクエストから継続的なインタラクションへ: 単一のユーザーの意図が、1時間にわたって10個のバックグラウンドアクションをトリガーする可能性があります。
多くの開発環境では、アイデンティティは変化に合わせて進化していません。ミドルウェアにロールをハードコードし、複数の異なるサービス間で認証ロジックを複製し、サービストークンの処理方法が曖昧になっている可能性があります。結果として、単一の権限を変更するだけで完全な再デプロイが必要になる脆弱なシステムになります。
アイデンティティを機能として扱うと、認証の負債が生じます。インフラストラクチャとして扱うと、拡張のための基盤を構築できます。アイデンティティがインフラストラクチャになれば、説明責任の基盤になります。新しいAI時代において、AI機能を追加するのは簡単ですが、説明責任を果たすのは困難です。
アイデンティティがスピードのボトルネックになる理由(セキュリティだけではない)
「アイデンティティを正しく実装する」と開発が遅くなるという根強い誤解があります。しかし、事実は逆です。不適切なアイデンティティアーキテクチャこそが、チームが機能をリリースする際に苦労する原因になることがよくあります。
新機能の負担
レガシーな環境では、新機能を開発するたびに誰が利用できるかを定義する必要があります。ロジックがif (user.role == 'manager' && user.dept == 'sales')のようにハードコードされている場合、実質的にすべてのルートに対してカスタム認証エンジンを構築していることになります。そして、すぐにメンテナンスの問題に発展します。
最新のアイデンティティアーキテクチャではPolicy-as-Codeを使用します。中央エンジンでルールを一度定義すれば、コードは単に「アクターはリソースに対してアクションを実行できるか」と問い合わせるだけです。セキュリティをデプロイから切り離し、認証ロジックに触れることなく機能をリリースできます。
AI統合の壁
AIエージェントが機能するには、トークン、スコープ付きアクセス、コンテキストの3つが必要です。アイデンティティの基盤がCookieとセッションだけの場合、AIにアクセス権を付与するためにサービスアカウントを無理やりつなぎ合わせることになります。アイデンティティシステムが限定的なトークンを発行する柔軟性を持たないという理由だけで、本来アクセスすべきでないデータまで閲覧できる過剰な権限を持つエージェントを生み出します。
メンテナンスの負担
断片化されたアイデンティティは、重複した作業を意味します。誰がアクセスできるかという事実が複数の異なるリポジトリに散在しているため、セキュリティレビューに時間がかかります。アイデンティティをアーキテクチャの柱として一元化することで、開発者の認知的負荷を軽減できます。開発者は認証の仕組みを心配する必要はなく、信頼できるサービスからユーザー情報を取得するだけで済みます。
AIは認証を完全に変える
AIはリクエストの量を増やすだけでなく、呼び出し元の性質を変化させます。従来のアイデンティティは、ユーザーとデバイスの一時的な結びつきであるセッションの概念に基づいて構築されています。
AIエージェントはセッションの概念を破壊します。
エージェントは非同期かつ継続的
AIコパイロットは、ユーザーがオンラインのときにタスクを開始し、3時間後に完了する場合があります。認証モデルが有効期限の短いユーザートークンに依存している場合、エージェントはタスクの途中で失敗します。エージェントに有効期限の長い管理者トークンを付与すると、セキュリティホールが生じます。ユーザーが特定のタスクと特定の時間枠でのみ有効なスコープ付き資格情報をエージェントに付与できる、委任された認可をサポートする仕組みが必要です。
スタックの新しい要件
AIをサポートするには、アイデンティティ層がリアルタイムで4つの質問に答えられる必要があります。
- アクターは何か。(特定のモデルまたはエージェントのバージョンを特定する。)
- 人間か機械か。(直接的なユーザーアクションとエージェントによる自動化を区別する。)
- 現在何にアクセスできるか。(現在のコンテキストに基づいて動的な権限を評価する。)
- 誰の権限に基づいているか。(アクションをトリガーした元の人間までさかのぼる。)
重要な違いがあります。アイデンティティはアクセスを強制し、AIが実行できる境界を定義します。AIが何をすべきかを決定するわけではありません。それはモデルロジックの役割です。アイデンティティはガードレールとして機能します。LLMがデータベースを削除するリクエストをハルシネーション(幻覚)で生成したとしても、エージェントのトークンにスコープが含まれていないため、システムはリクエストを確実に拒否します。
「AI対応認証」の実際の姿
「AI対応認証」を構築するには、ユーザーとエージェント間の信頼のギャップを解決するために、初期段階からアイデンティティを組み込む必要があります。ハルシネーションによる誤った権限付与やトークンの漏洩は、一夜にしてブランドの評判を失墜させる可能性があります。ユーザーが信頼できるAIシステムを構築するには、アイデンティティ層をセキュアバイデザインで設計し、以下の機能を提供する必要があります。
1. 摩擦の少ない適応型アクセス
人間にとっては、パスワードレスフローやパスキーを意味します。AIエージェントにとっては、シームレスなM2M認証を意味します。目標は、ユーザーとエージェント間のハンドシェイクが暗号学的に安全であることを保証しつつ、離脱を最小限に抑えることです。
2. 統合されたアイデンティティコンテキスト
ユーザーデータベースとAPIキーリストを別々の場所で管理することはできません。アクター、セッション、権限を単一のビューで管理する必要があります。コンテキストはすべてのサービス間で共有する必要があります。これにより、AIエージェントがダウンストリームAPIを呼び出した際に、APIは元のユーザーが誰であるかを正確に把握できます。
3. 動的で関係ベースの認可
ロールベースアクセス制御(RBAC)はAIには大雑把すぎます。ユーザーが編集者だからといって、AIエージェントがすべてのファイルを編集できるべきではありません。関係性を評価するきめ細かな認可(FGA)が必要です。たとえば、「ユーザー(C)が作成したドキュメント(B)を、エージェント(A)は編集できるか」といった制御が求められます。
4. トレーサビリティと説明可能性
エージェントシステムでは、「誰が実行したか」が最も頻繁に問われます。アイデンティティ層は、すべてのマシンアクションを人間の意図に紐付ける不変の監査ログを提供する必要があります。セキュリティのためだけでなく、デバッグの目的でも重要です。AIエージェントが設定を変更した場合、それを許可したトークンチェーンを確認できなければなりません。
開発者が直面している現実世界のパターン
アプリ内のAIコパイロット
メールの要約やCRMの更新を実行できるコパイロットを開発する場合、コパイロットはユーザーの代理として機能します。本記事でのパターンは委任された権限です。開発者は、AIエージェントがメールの読み取り専用や特定のCRMフィールドの書き込み専用に制限されたトークンを受け取るように設計する必要があります。適切な制限がない場合、プロンプトインジェクション攻撃によってAIがデータベース全体を流出させる危険性があります。
バックグラウンドエージェントと自動化
クラウドのコストを最適化するために毎晩実行されるエージェントを考えてみましょう。エージェントにはユーザーセッションが存在しません。そのため、非人間アイデンティティ(NHI)が必要です。ここでのリスクは目に見えないアクションです。アイデンティティ層がエージェントの動作を監視していない場合、監査証跡を残さずに高価なインスタンスを起動し始める可能性があります。
AI機能を備えたマルチテナントSaaS
これは適切に実装するのが最も難しいパターンです。A社とB社のデータを同時に処理するAIモデルを実行しているとします。アイデンティティアーキテクチャが最も深いレベルでテナントを認識していない場合、テナント間でデータが漏洩するリスクが生じます。アイデンティティ層は強固な障壁として機能し、AIエージェントのコンテキストが単一のテナントのデータに厳密にロックされるように保証する必要があります。
アイデアから実装へ
AIに対応するためにスタック全体を再構築する必要はありません。しかし、アイデンティティをライブラリとして扱うのをやめ、サービスとして扱う必要があります。
- アイデンティティの一元化: 個々のマイクロサービスから認証ロジックを切り離し、共有アイデンティティ層に移行します。重複を排除し、単一の信頼できる情報源を確保します。
- ポリシーベースの認可への移行:
ifステートメントのハードコーディングをやめます。コードをプッシュせずにリアルタイムでルールを更新できるポリシーエンジンを使用します。 - 複数のアイデンティティタイプの設計: システムは、サービスアカウントと人間のユーザーを、同様のガバナンス要件を持つ第一級市民として扱う必要があります。
- アイデンティティの拡張性を高める: 新しいAIモデルやサードパーティの統合を追加する際、システム間でコンテキストをより安全に受け渡しできるように、アイデンティティ層はToken Exchange (RFC 8693)をサポートする必要があります。
- 標準規格に基づく構築: OIDC、OAuth 2.0、およびFGAのパターンに準拠します。ベンダーロックインを引き起こし、監査を不可能にする独自の認証ハックは避けてください。
アイデンティティはAI対応システムの基盤
AIは複雑さを増大させるだけでなく、すでに存在していた複雑さを浮き彫りにします。AI導入前にアイデンティティ層が整理されていなかった場合、導入後には破綻してしまいます。
アイデンティティはコントロール層であり、安全層であり、開発者にとって最も重要な開発速度を支える層です。アイデンティティをインフラストラクチャとして扱えば、「エージェントを保護する方法」を心配する必要がなくなり、「エージェントがユーザーのために何を実行できるか」に集中できます。
断片化された認証基盤の上にアプリを構築すると、スプリントの半分をログインのバグやセキュリティのギャップの修正に費やすことになります。アイデンティティを後付けではなくアーキテクチャの柱として位置づければ、開発スピードが向上し、自信を持って拡張できます。すべてのアクションが検証可能な人間の意図に基づいているため、ユーザーが信頼できるAIシステムを提供できます。
本番環境に対応したAIアプリを構築する方法について詳しく知りたい場合は、本番環境に対応したアプリとAIエージェントのための開発者ブループリントを確認してください。
About the author
Saad Rahman
Staff Product Marketing Manager, Auth0 Solutions