MCP Authentication, Explained: Inbound Identity, Outbound Credentials, and Delegation

ゲートウェイに対する呼び出し元を識別するトークンと、ダウンストリームサービスへのアクセスに使用される資格情報は、それぞれ異なる問題を解決するためのものです。セキュアなMCPシステムでは、この違いが明確に維持されます。

認証は単一のホップではない

MCPリクエストがビジネスシステムに到達するまでに、複数の信頼境界を越える場合があります。個人またはサービスがアプリケーションに対して認証を行います。エージェントは独立したソフトウェア主体（Principal）として動作する場合があります。クライアントはMCP Gatewayに対して認証を行います。ゲートウェイは、その呼び出し元がサーバーまたはツールを使用できるかどうかを判断します。その後、ゲートウェイはダウンストリームのMCPサーバーに対して認証を行い、そのMCPサーバーが別の信頼できるサービスを呼び出す場合もあります。

すべての資格情報に対して「トークン」という言葉を使用すると、これらの境界が見えなくなってしまいます。インバウンド資格情報は「誰がゲートウェイを呼び出しているか」に答えます。アクセス制御ポリシーは「そのアイデンティティがどのゲートウェイリソースを使用できるか」に答えます。アウトバウンド認証は「ダウンストリームサーバーがどの資格情報と権限を受け取るか」を決定します。これらの答えは、意図的に異なるものにすることができます。

TrueFoundryのドキュメントでは、アーキテクチャをインバウンド認証、アクセス制御、アウトバウンド認証の3つに分離しています。この分離は、委任、属性付与、およびConfused Deputy攻撃のリスクについて検討するための適切な出発点となります。

ゲートウェイは意図的に3つの検証に分割されています。インバウンド認証が成功すると呼び出し元が特定されますが、アクセス制御ポリシーによって許可されるツールが選択され、アウトバウンド認証によってMCPサーバーから認識される主体が決定されます。

インバウンド認証によるゲートウェイ呼び出し元の解決

TrueFoundryのドキュメントでは、いくつかのインバウンド方式が説明されています。TrueFoundryアカウントを持つユーザー向けのPersonal Access Token、サービス間呼び出し向けのVirtual Accountトークン、組織のJWT発行体を使用する顧客またはサービス向けのIdentity Providerトークン、そして互換性のあるIDEクライアント向けのTrueFoundry OAuthです。

資格情報を検証した後、ゲートウェイはTrueFoundryアイデンティティを解決し、MCPサーバーおよび個々のツールに対してアクセス制御を適用します。該当するアイデンティティは、ユーザー、チーム、またはVirtual Accountの可能性があります。ベータ版としてドキュメント化されているAgent Identityは、エージェント起点のリクエスト用に独立して登録されたエージェントアクターを追加します。これは、背後に人間が存在しないサービスやアプリケーションを表すVirtual Accountとは異なります。

アイデンティティの解決では、発行体、オーディエンス、署名、有効期限、およびサブジェクトの選択に使用されるクレームマッピングを検証する必要があります。誤ったオーディエンスに対して有効に署名されたトークンは、ゲートウェイに対する正当な権限とは言えません。2つのサービスが誤って同一のエージェントアイデンティティとして解決されないよう、マッピングは十分に具体的である必要があります。

アウトバウンド認証によるダウンストリーム主体の選択

ゲートウェイは、ユーザーごとのOAuth Authorization Code、アプリケーションレベルのOAuth Client Credentials、ドキュメント化されているOktaトークン交換/OBO構成、共有または個別のAPI Key、パブリックサービス向けの認証なし、Token Passthrough、Token Forwarding、あるいはサポートされているAWSエンドポイント向けのAWS SigV4を使用してMCPサーバーに対して認証を行うことができます。

これらのモードは、それぞれ異なる権限体系をモデル化しています。ユーザーごとのOAuthでは、各個人が自身のサードパーティアカウントを個別に認可できます。Client Credentialsはアプリケーションを表し、通常は共有されたサービス権限を付与します。トークン交換またはOBOは、アイデンティティシステムに対し、呼び出し元のアイデンティティから派生し、別のオーディエンスをターゲットとしたダウンストリームトークンの発行をリクエストします。共有API Keyは、ゲートウェイ内部で属性識別が保持されている場合であっても、すべての呼び出し元を1つのアップストリーム主体に統合してしまいます。

最も導入が容易な連携方式を選択すると、認可モデルが意図せず変更されてしまう可能性があります。Gmail MCPサーバーが1つの共有サービス資格情報を使用している場合、アップストリーム側では各従業員の個人のメールボックス権限を識別できません。内部MCPサーバーが組織のIdPトークンを直接検証する場合、Passthroughによってサブジェクトを維持できますが、これは発行体、オーディエンス、およびスコープが意図的に受け入れられている場合に限られます。

この図では、プロトコルのラベルではなく、権限のセマンティクスによってモードをグループ化しています。ユーザーごとおよびOBOのフローではサブジェクトのコンテキストを維持できますが、Client Credentialsおよび共有キーは、ダウンストリームサービスがサブジェクトを認識する追加の制御を適用しない限り、アプリケーションの権限を表すことになります。

PassthroughとForwardingは同義語ではない

TrueFoundryのドキュメント用語において、Token Passthroughはインバウンド認証に使用されたものと同一のトークンをMCPサーバーに転送します。サーバーは、そのTrueFoundryまたはIdentity Providerのトークンを検証できる必要があります。Token Forwardingは、専用のヘッダーを介してクライアントから提供される別のサーバー固有の資格情報を保持します。この場合、アウトバウンド資格情報はインバウンドのベアラーとは異なります。

この違いは、ログ記録、マスキング、失効処理、および脅威モデリングにおいて重要です。Passthroughはゲートウェイ境界を超えて単一の資格情報を維持するため、ダウンストリームにおける正確なオーディエンスの信頼関係が必要となります。Forwardingは、クライアントが取得して保護しなければならない別のシークレットを導入します。どちらの方式も、最終的なビジネスAPIが意図された人間とエージェントの関係性を正しく認識できたことを自動的に証明するものではありません。

OAuthトークン交換およびOBOは、これとは異なるパターンを提供します。ゲートウェイまたはアイデンティティ層が、委任された権限を表す新しいオーディエンス固有のトークンを取得します。これにより、ベアラートークンの再利用を削減し、ダウンストリームシステムがそのリソース向けに設計されたスコープを適用できるようになります。提供される具体的な保証内容は、Identity Provider、クレーム、検証、およびダウンストリームアプリケーションに依存します。

ヘッダーだけでなく主体をモデル化する

Confused Deputy攻撃の防止

ゲートウェイが広大なダウンストリーム権限を持ち、同等の許可を持たない呼び出し元のためにその権限を使用した場合、ゲートウェイはConfused Deputy（混同された代理）となります。インバウンド認証が完全に有効であっても、構成されたアクションに対して過剰な権限が付与されている状態が発生し得ます。ゲートウェイは、呼び出し元のアイデンティティ、エージェントのアイデンティティ、リクエストされたサーバーとツール、アウトバウンド資格情報モード、およびダウンストリームのスコープを適切に結合させる必要があります。

共有資格情報を使用する場合、MCPサーバーまたはバックエンドアプリケーションは、サブジェクトを意識した認可を再適用するのに十分な信頼できるコンテキストを受信するか、ツールが許容されたすべての呼び出し元にとって安全なリソースのみを公開するように設計されている必要があります。広範なクエリを実行した後に、モデル側で結果をフィルタリングさせるような設計に依存してはなりません。ユーザーごとの資格情報を使用する場合は、認可が意図したサブジェクトに正しく紐付けられており、オーバーライド等によって他のユーザーに差し替えられないことを確認してください。

また、すべてのホップにおいて、ベアラートークンをログにコピーすることなく、監査相関識別子（Audit Correlation Identifier）を維持する必要があります。資格情報モード、解決されたアイデンティティ、発行体、オーディエンス、スコープクラス、ポリシーバージョン、およびダウンストリームのレスポンスメタデータを記録してください。シークレット値はトランスクリプトやトレースではなく、保護されたストアに保管されるべきです。

このチェーンは、ゲートウェイの決定を通じて人間のサブジェクトとソフトウェアアクターの両方を保持します。アウトバウンドモードは、そのアイデンティティコンテキストを保持、交換、または統合できますが、ダウンストリームシステムが最終的なリソースおよびアクションの認可を実行することに変わりはありません。

具体的な適用例：カスタマーサポートCRMアクセス

サポート担当者が認証済み従業員からリクエストを受け取ります。アプリケーションは従業員のIdentity ProviderトークンをMCP Gatewayに送信し、同時に登録済みのAgent Identityを提示します。ゲートウェイのポリシーにより、このユーザーとエージェントのペアに対してCRM検索ツールの呼び出しが許可されます。

この構成がTrueFoundryのドキュメントにあるOkta OBO構成を使用していると仮定します。ゲートウェイは、インバウンドのユーザー個人トークンを、ケースの参照専用スコープを持つCRMオーディエンス向けトークンに交換します。CRMは新しいトークンを検証し、独自の行レベル認可を適用します。エージェントは従業員に許可されたケースを取得できますが、変更を加えることはできません。個別の更新ツールを実行するには、より限定されたダウンストリームスコープと承認が必要です。

構成で代わりに共有API Keyが使用されている場合、アーキテクチャ側で補償制御を行う必要があります。CRM側のサービスは、ゲートウェイから解決・処理された信頼できるサブジェクト属性を受信して検証し、サーバー側でレコードをフィルタリングします。サービスがサブジェクトのコンテキストを強制適用できない場合、ユーザー固有の認可が必要なデータに対して共有キーを使用することは不適切です。

権限のセマンティクスによるアウトバウンド認証の選択

• アップストリームのリソースが各個人によって所有または権限設定されている場合は、ユーザーごとの認可を使用します。
• ユーザー認可の回避策としてではなく、真にアプリケーション自身が所有するリソースに対してのみClient Credentialsを使用します。
• ダウンストリームで委任されたオーディエンス固有のユーザートークンが必要な場合は、トークン交換またはOBOを使用します。
• ダウンストリームがインバウンドトークンを意図的に信頼し検証している場合にのみPassthroughを使用します。
• MCPサーバーが個別の資格情報スキームを持っている場合はForwardingを使用し、それに伴うクライアント側のシークレット管理の負荷を受け入れます。
• 認証なしのサーバーはパブリックな機能として扱い、機密データやデータの変更を伴う操作を配置しないようにします。

認証チェーンの障害テスト

• 誤ったオーディエンス、発行体、テナント、またはマッピングされたサブジェクトを持つ有効なトークンをリプレイする。
• ユーザーを固定したままエージェントアイデンティティを変更し、有効なツールアクセス範囲が設計通りに変更されるか検証する。
• エージェントを固定したままユーザーを変更し、ダウンストリームデータが要求通り人間のサブジェクトに追従するか検証する。
• 別のユーザーの認可オーバーライドを介して個人の資格情報を差し替える。
• ゲートウェイのアクセス権限とアップストリームのOAuth権限を独立して取り消し、それぞれの影響の違いを検証する。
• ゲートウェイを介さずにMCPサーバーを直接呼び出し、必要に応じてネットワークおよびサーバーのポリシーによってバイパスが防止されるか検証する。
• ログ、トレース、エラー、およびモデルコンテキストを検査し、ベアラートークンや転送シークレットの漏洩がないか確認する。

資格情報のライフサイクルはデータパスの一部である

認証の設計は、トークンが受け入れられた後も継続します。資格情報はさまざまなシステムで有効期限切れ、リフレッシュ、ローテーション、および失効処理が行われます。たとえば、TrueFoundryのドキュメントには、「すべてのトークンを失効（Revoke all tokens）」アクションを実行するとAI Gatewayから保存された資格情報は削除されますが、アップストリームのOAuthプロバイダーにおける許可までは失効しないと記載されています。運用担当者は、ゲートウェイ資格情報、Identity Providerセッション、アップストリーム認可、およびキャッシュされたダウンストリームトークンに対して、それぞれ個別の手順を用意する必要があります。

各資格情報をどのコンポーネントがリフレッシュするか、リフレッシュされたトークンがどのサブジェクトを表すか、そしてエージェントのタスクの途中でリフレッシュが失敗した場合にどうなるかを定義してください。一時停止した認可フローが、より広範なアクセス権限を持つアプリケーション資格情報へサイレントにフォールバックしてはなりません。ユーザーがアカウントを再接続した際、エージェントが処理を継続する前に、新しい認可が意図したサブジェクトおよびサーバーと正しく関連付けられる必要があります。

ローテーションは、もう1つの検証境界を作り出します。共有API Keyには二重キー期間が必要な場合があり、ユーザーごとのOAuthトークンは個別に無効化される場合があります。また、OBOトークンは有効期限までキャッシュされる一方で、再交換のためにインバウンドトークンは最新状態を保つ必要があります。運用担当者がシークレットを露出させることなく影響を受ける呼び出しを特定できるよう、保護された運用メタデータに資格情報モードとトークンファミリー識別子を記録してください。

失効処理は外部から内部に向かって検証する必要があります。ゲートウェイのコラボレーターを削除し、アップストリームの許可を取り消し、ダウンストリームのアカウントを無効化して、それぞれの効果を個別にテストします。完全なインシデント手順では、どのアクションが新しいゲートウェイ呼び出しを停止させ、どのアクションが直接アクセスを無効化し、どのアクションがローカルコピーのみを削除するかを明確に把握しておく必要があります。

また、モデルが参照するコンテキストからトークン処理を排除する必要があります。エージェントは、ベアラー情報自体を受け取ることなく、安定したアイデンティティラベル、認可結果、および再接続手順に基づいて推論を行うことができます。プロバイダーから返されるエラーは正規化し、デバッグ出力によってヘッダー、リフレッシュトークン、クライアントシークレット、または署名済みリクエスト要素がトランスクリプトに漏洩しないようにしてください。

運用上の原則

セキュアなMCP認証は、すべての主体とホップを明示的に定義することから始まります。インバウンドアイデンティティ、ゲートウェイアクセス、アウトバウンド資格情報、およびビジネス認可は、関連し合いつつも互いに置き換え不可能な制御機能です。最も安全な設計とは、主体やオーディエンスの変更をすべて明示的に行う設計です。

TrueFoundry MCP Gatewayは、ゲートウェイに対向する各レイヤーに対してドキュメント化されたメカニズムを提供しており、ガバナンス利用可能性マップにベータ版として記載されているAgent Identityによって、ソフトウェアアクターを人間のサブジェクトと明確に区別することができます。ダウンストリームアプリケーションは引き続き自身のドメイン認可を所有し、組織は資格情報の最小化を所有します。この境界は解説上の制限事項ではなく、セキュリティモデルの検証可能性を担保する核心部分なのです。

参考文献

1. TrueFoundry — MCP Gateway Authentication and Security.
2. TrueFoundry — Agent Identity.
3. TrueFoundry — MCP Gateway Overview.
4. IETF RFC 8693 — OAuth 2.0 Token Exchange.

免責事項： 本記事は、2026年9月17日時点で引用された公開資料に対するTrueFoundryのエンジニアリング上の解釈を反映したものです。製品機能はリンクされたドキュメントの範囲に限られます。例示および運用のデフォルト設定は説明を目的としたものであり、法的助言、監査意見、独立したベンチマーク、あるいはセキュリティ、安全性、コンプライアンスを保証するものではありません。

‍