AIエージェントと認証・認可：LLMにトークンを渡さない設計アプローチ
こんにちは。AWS AI League 1年生の人です。
少し前に「AIエージェントと認証・認可」をテーマにしたハッカソン「Authorized to Act: Auth0 for AI Agents」に参加しました。
このハッカソンの上位入賞者のプロダクトから学んだ「AIエージェントの設計原則」と「Auth0 Token Vaultの使いどころ」についてご紹介します。
本記事で紹介する構成は一例であり、実際のプロダクト適用時はシステムの要件やセキュリティ方針に応じた、適切な検討が必要です。また、本記事は筆者個人の学習と公開情報をもとに知見を整理したものであり、特定の製品や設計を推奨するものではありません。
この記事の対象
- AIエージェントの「利用」から「開発」へステップアップしようとしているエンジニア向け（入門者〜中級者）
- AIエージェントをプロダクトに組み込んで提供するケース
- そのAIエージェントが外部SaaSのAPIを実行するケースを想定しています
- AIエージェント開発におけるトークンの扱いを中心に、学んだことを記載しています
（対象外）
- AIエージェントを個人のPCのローカルで動かすケースは本記事の説明の対象外です
- AIエージェントを含むシステム開発のセキュリティ設計は「多層防御」が基本です。本記事は、そのすべてを網羅するものではありません。
AIエージェント開発の前提知識
- AIエージェントの基本構成
- LLM（脳）だけではなく、Tool（外部タスクを実行する手足）やMemory（記憶）などのコンポーネントを組み合わせて成り立っています
- 参考：Google Cloud : エージェントシステムのアーキテクチャコンポーネントの概要
この記事で1番お伝えしたいこと
- AIエージェントのLLMに生のトークンやクレデンシャル情報を直接渡さない設計を検討する
なぜLLMにトークンを直接渡さない設計が重要なのか
これまでのアプリケーション
- アプリケーションは明示された処理フロー、プログラムに従って動作します（ただし、脆弱性や設定ミスによって、設計者の意図と異なる動作をする可能性はあります）
AIエージェントのLLMに渡してしまうと起こりうる脅威
- 外部からのプロンプトインジェクションにより、第三者のアウトプットに秘匿情報が出力・漏洩してしまうリスクがあります
- LLMプロバイダー側のログなどにクレデンシャルが含まれ、意図せず保存されるリスクがあります
では、誰に実行させるのか？
ここで登場するのが、Toolです。Toolの実装や背後のサービスが、認証情報や実行主体を確認し、認可ポリシーにもとづいて実行可否を判断します。
バックエンドアプリケーションに実行を任せる最大のメリットとして以下が挙げられます。
- プログラムとして入力検証、認可、対象リソースの制限、エラー処理などを明示的に強制できること
- 実行の追跡が可能であること（可観測性、監査性の確保）
- エラー処理、デバッグが容易であること（障害対応の迅速化）
さらに、LLMからの実行指示さえも疑う
LLMは曖昧で不確定な動きをするため、LLMの指示をそのままバックエンドアプリケーションで実行すると、予期しない操作につながる可能性があります。
そのためLLMの出力やユーザー入力にもとづく操作を、評価・検証せずに実行することは避け、バックエンドで改めて「ユーザー、エージェント、対象リソース、操作内容」を確認した上で、Tool実行やAPIアクセスを許可・拒否する設計が必要になります。
そこで重要になるのが、誰の権限で実行するかを明確にすることです。
ユーザーの権限だけでなく、実行主体となるエージェントも識別した上で、認可する設計が必要になります。
ユーザーの権限管理：Token Vaultという選択肢
外部SaaSのAPIを呼び出すには、ユーザーごとのアクセストークン、リフレッシュトークンを安全に保管・管理する必要があります。これは実行主体がアプリケーションからAIエージェントになっても変わりません。
従来は、以下の実装が必要でした
- ユーザーごとのアクセストークン、リフレッシュトークンを安全に保管するためのデータベース設計
- 有効期限切れのリフレッシュトークンのライフサイクル実装と保守
しかし、外部連携先が増えていくにつれ、以下の問題が発生します
- 接続先SaaSごとのAPI仕様に合わせたトークン管理の実装コストや保守の負担増
- トークン管理データベースを自前で構築することによる機微情報の分散や管理不備による漏洩リスク増
その解決策のひとつが、Token Vaultです。
Token Vaultとはなにか
Token Vaultという言葉は、外部SaaSのAPIを呼び出すために必要なアクセストークンやリフレッシュトークンを、安全に保管・管理する仕組みを指して使われます。
製品によっては、トークンの更新、失効、短寿命トークンの発行なども提供します。
今回はAuth0 for AI Agentsというソリューションのひとつである、Auth0 Token Vaultの実装例を学びました。
Auth0 Token Vaultの活用例
マネージドサービスであるため、以下のようなメリットがあります
- トークン管理に必要なセキュリティ対策とソフトウエア保守の負担を軽減できる
- 複数の外部SaaSのトークンはAuth0を経由して統一的に管理でき、複数のSaaS連携におけるトークン保管・更新処理の実装負担を軽減できる
長時間稼働するAIエージェントと短寿命トークン
AIエージェントは、人が常時介在しなくても自律的に動き続けるため、バックエンドで長時間実行されるケースがあります。
今回の入賞者のプロダクトには、必要な時にだけ短寿命のアクセストークンをバックエンドが取得する設計を採用しているケースがありました。
このような設計により、トークンが漏洩した場合でも悪用可能な時間を短くし、影響を抑えられます。
まとめと学んだこと
- （再掲）AIエージェントのLLMにトークンやクレデンシャルを渡さない
- 外部SaaSのAPIリクエストはTool（バックエンドアプリケーション）が行う
- 「誰の代理で、どのエージェントが、どの権限で実行するのか」を追跡できる設計にする
- LLMのTool実行指示は信用せずに、「誰からの指示で、アクションの認可はされているのか」を確認する設計にする
ハッカソンに提出するプロダクトを作っている期間は、提出要件を満たす「動くソフトウエア」を作ることに必死でした。その結果「実装方法」を実体験として得ることはできましたが、「このユースケースにこのAIエージェントは合っていたのか？」、「そもそもこの認可設計でよかったのか？」など、もやもやしていました。
そして、改めて上位入賞者のプロダクトを参考にすることで、Token Vaultの使いどころや、AIエージェントの実装に伴うセキュリティ設計の考え方を学び、自分自身の中で不足していた設計観点や、曖昧になっていた機能の理解を深めることができました。
これからAIエージェント開発を始めようと思っているエンジニアのみなさんに、少しでもお役に立てれば幸いです。