> ## Documentation Index
> Fetch the complete documentation index at: https://ai.brokenguardrail.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Token Vault

> ユーザーごとの認証情報を保管し、要求者との対応づけを強制してConfused Deputy Problemを防ぐ仕組み

Token Vaultは、ユーザーごとの認証情報を保管し、どのユーザーがどの認証情報を使えるかという対応づけを強制するシステムです。マルチユーザー環境でAIエージェントを運用するとき、既存のアクセス境界をエージェントにそのまま引き継がせる土台になります。

## 背景にあるConfused Deputy Problem

[Confused Deputy Problem](/ja/risks/confused-deputy-problem)は、権限を持たない要求者がより強い権限を持つ主体を経由して自分の代わりにその権限を行使させてしまう問題です。複数ユーザーが利用するエージェント基盤では、サードパーティサービスへのアクセストークンを共有のクレデンシャルストアに保管することがあります。どのユーザーがどの認証情報を使えるかの制御を欠くと、あるユーザーが他ユーザーの認証情報を指定してセッションを開始できてしまいます。

このときエージェントは要求者ではなく認証情報の持ち主の権限で外部サービスへアクセスします。Machine UserやAPIキーのような共有クレデンシャルを使う構成では、対応づけを正確に管理しないとアクセス境界が迂回されるリスクが高まります。

## OAuthの位置づけ

OAuthは、ユーザーが自分のアカウントが持つ権限の一部をアプリケーションへ委譲するための認可プロトコルです。ユーザーはブラウザの認可画面で許可する範囲を確認し、アプリケーションはその範囲だけを表すアクセストークンを受け取ります。トークンはそのユーザーの既存権限のサブセットであることが保証されるため、エージェントがこのトークンだけを使ってバックエンドへアクセスすれば元のアクセス境界が保たれます。

エージェントが接続するサービスは複数あり、トークンには有効期限があります。ユーザーごとに取得したトークンをどこに置き、実行時にどう使わせるかをToken Vaultが管理します。

## アーキテクチャ

Token Vaultは3つの部品で構成されます。

### 保管庫

ユーザー単位でVaultを分け、OAuthのアクセストークンとリフレッシュトークン、あるいはAPIキーのような固定トークンを格納します。リフレッシュトークンとトークンエンドポイントを登録しておけば、アクセストークンの更新を保管庫側で自動化できます。[Claude Managed Agents](https://hi120ki.github.io/ja/blog/posts/20260413/)のCredential Vaultはこの層の実装で、認証情報は実行中も定期的に再解決されるためセッションを再起動せずローテーションが反映されます。

### 登録インターフェース

エンドユーザーが自身のクレデンシャルのみを登録・更新できる画面を提供し、他ユーザーの認証情報に触れる経路を塞ぎます。ユーザーから見ればサービスごとのOAuthボタンを押して権限を付与するだけです。裏側では認証基盤で識別したユーザーとVaultを対応づけ、Vaultのメタデータにユーザー識別子を記録します。

### トークン取得

エージェントがツールを呼び出すと、セッションに紐づくユーザーのVaultからトークンが解決され、外部サービスへのリクエストに使われます。これによりリソースの取得・更新・削除がユーザーの既存権限の範囲内に収まります。

## 運用上の注意

### リクエストごとに要求者とVaultの対応を検証する

要求者のidentityをリクエストごとに確認し、その人物のVaultだけを解決します。

### Scopeを最小権限に揃える

OAuthの権限制御はScopeという単位で行われるため、読み取りだけでよいエージェントには読み取りのみのScopeを設定し、トークンを取得するようにします。

### Scopeの粗さを補う

Cloud IAMと違い、一般にサポートされる範囲のOAuthのScopeは大まかな権限区分しか表現できず、リソース単位のアクセス制御ができません。慎重な扱いを要するリソースは別テナントへ切り出し、トークンから到達できない場所に置きます。

## 得られるもの

既存のサードパーティサービスに設定済みのアクセス境界が、エージェント経由でもそのまま機能します。ユーザーは自分の権限の範囲でしかエージェントを使えず、Confused Deputy Problemが構造的に成立しなくなります。認証情報の管理はエージェントのコードから分離され、失効とローテーションは保管庫の一箇所で完結します。監査ではVaultとセッションの対応から、誰の権限でどの操作が行われたかを追えます。

## Cross App AccessとID-JAG

Token Vaultにも残る手間があります。ユーザーはサービスごとにOAuthフローを踏み、管理者はVaultとユーザーの対応づけを自前で維持します。

これに対してOktaの[Cross App Access](https://oauth.net/cross-app-access/)は、Identity Assertion Authorization Grant、いわゆるID-JAGを中核とするOAuthの拡張です。ユーザーがIdPへログインすると、以降はブラウザを介さずIDトークンからAssertionを経て各サービスのアクセストークンが取得されます。ユーザーはサービスごとの同意画面を踏みません。

IdPがトークン発行のハブになり、管理者はどのクライアントがどのサービスのトークンを取得できるかを中央で制御し発行状況から可視性を得ます。導入することですべての接続が中央のIdentityポリシーを経由しログに残り、どのエージェントがどのサービスへアクセスしたかを管理・監視できます。

## 普及までの現実解

Cross App AccessとID-JAGは、IdP・各サービスの認可サーバー・クライアントのすべてが対応して初めて機能します。対応を待つ間の現実解がToken Vaultです。権限の中央管理・失効・監査の運用をToken Vaultで先に確立しておけば、Cross App Accessが行き渡ったときに変わるのはトークンの取得経路だけです。誰の権限で動くかという原則はそのまま維持できます。

## 参考文献

* [Cross-App Access - OAuth 2.0](https://oauth.net/cross-app-access/)
* [Identity Assertion Authorization Grant](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/)
* [Claude Managed Agentsはどこまで安全か？](https://hi120ki.github.io/ja/blog/posts/20260413/)
* [MCPの認証と認可の現在と未来](https://hi120ki.github.io/ja/blog/posts/20250728/)
* [2026年後半のAI Securityでやるべきこと](https://hi120ki.github.io/ja/blog/posts/20260701/)