AgentGatewayで学ぶRFC 8693トークン交換の仕組み

AIエージェントが複数のAPIを呼び出す際、認証トークン（認証情報を格納した署名済み文字列）をそのまま各サービスに渡し続けるのは、セキュリティ上の大きなリスクになります。2026年7月12日にリリースされたAgentGatewayは、RFC 8693に基づくトークン交換をプロキシレイヤーで自動的に処理する機能を搭載しました。この記事では、その仕組みを技術的に整理します。

なぜ「トークンをそのまま渡す」設計が危険なのか

OIDC（OpenID Connect：認証情報をJWT形式で発行する標準プロトコル）が発行するIDトークンは、通常ユーザーのブラウザセッション全体を対象に発行されます。スコープ（許可する操作の範囲）が広く、有効期限も数時間に設定されることが珍しくありません。

AIエージェントがこのトークンをそのまま受け取った場合、エージェントはそのトークンを使ってユーザーが許可したすべてのサービスへアクセスできてしまいます。エージェント自身が侵害されたとき、あるいはプロンプトインジェクション（外部データを通じてエージェントの動作を操作する攻撃）を受けたときの被害範囲が、ユーザー権限全体に広がります。

RFC 8693はこの問題に対するOAuth 2.0の標準解答です。グラントタイプ（認可の取得方法を示す区分）として urn:ietf:params:oauth:grant-type:token-exchange を定義し、既存のトークンを別の用途に特化した新しいトークンへ交換できるようにします。交換後のトークンはaudience（受け取り側のサービスを示すクレーム）を絞り込み、有効期限を短くし、scopeも最小化できます。

AgentGatewayにおけるトークン交換の流れ

AgentGateway（Rustで書かれたAIエージェント向けプロキシサーバー）は、Keycloakなどのアイデンティティプロバイダーとの間でトークン交換を透過的に処理します。処理の流れは以下の通りです。

ユーザー → [IDトークン] → AgentGateway
                             ↓ RFC 8693リクエスト
                           Keycloak（IdP）
                             ↓ 交換済みトークン
                         上流サービス（MCPサーバー等）

上流サービスが受け取るトークンは、AgentGatewayがKeycloakに対して発行リクエストを送った結果です。元のユーザートークンは上流サービスには届きません。subクレーム（ユーザーの識別子）は引き継がれるため、上流サービス側でもどのユーザーからの要求かは判別できます。

AgentGatewayの設定では backendAuth.oauthTokenExchange ポリシーを使います。2026年7月のリリース時点で、3種類の交換グラントが用意されています。

RFC 8693トークン交換（デフォルト）: Keycloak / Okta / ZITADEL / Auth0 向け。subject_tokenとして元のJWTを渡す
RFC 7523 JWTベアラー: JWTをassertionとして使うKeycloak JWT Authorization Grant向け
Microsoft Entra OBO（On-Behalf-Of）: Entra IDのjwt-bearerバリアントで、assertionを使う

キャッシュと設定のポイント

トークン交換のたびにIdPへリクエストを投げると、レイテンシが積み重なります。AgentGatewayは交換済みトークンをキャッシュする仕組みを内蔵しており、同じユーザーから短時間に繰り返しリクエストが来る場合はIdPへの往復を省略できます。

KeycloakをIdPとして使う場合、ローカル検証の手順は次のようになります。

# 交換後のトークンをデコードして確認する例
export EXCHANGED_TOKEN=$(curl -s -X POST http://localhost:8080/realms/demo/protocol/openid-connect/token \
  -d grant_type=urn:ietf:params:oauth:grant-type:token-exchange \
  -d subject_token=$USER_TOKEN \
  -d requested_token_type=urn:ietf:params:oauth:token-type:access_token \
  -d audience=upstream-service | jq -r .access_token)
jwt decode $EXCHANGED_TOKEN

audience パラメーターで交換先のサービス名を明示することが重要です。Keycloakはaudience検証を行うため、登録していないサービスへの交換リクエストは拒否されます。

類似ツールとして、Envoy ProxyのExternal Authorization（外部の認可サーバーへ委譲する仕組み）もトークン変換に使えます。ただしEnvoyの場合はLua/Wasmフィルターを自前で実装する必要があり、RFC 8693の交換フローをゼロから組む手間がかかります。AgentGatewayはエージェント向けユースケースに特化し、MCPサーバー（Model Context Protocol：AIエージェントがツールを呼び出す標準プロトコル）との接続を前提とした設計になっている点が異なります。

Microsoft Entra IDを使うチームには、OBOフローを使う選択肢があります。OBO（On-Behalf-Of）はAzure ADが長年提供してきたフローで、サービスAがユーザーの代わりにサービスBを呼び出す際にトークンを取得する仕組みです。RFC 8693とは別仕様ですが、AgentGatewayは同じ backendAuth.oauthTokenExchange ポリシーの中でEntra OBOをサポートしているため、IdPを切り替えても設定の構造は統一できます。

トークン交換はゲートウェイを「セキュリティ境界」として機能させる設計です。各エージェントやMCPサーバーが独自にIdP認証を実装する代わりに、ゲートウェイが一元的に交換と検証を担います。この構造が持つ意味は、証明書管理をサービスメッシュに委ねるのと本質的に同じです。複雑さをインフラレイヤーへ移譲し、アプリケーションコードを認証ロジックから切り離すことにあります。