AI API ゲートウェイを介した MCP コネクタ ガバナンス: OAuth トークン、ツール スコープ、およびユーザーごとのアトリビューション

エージェントが Gmail、ドライブ、Stripe、内部システム、またはリモート MCP サーバーを呼び出す場合、モデル リクエストはセキュリティ イベントの一部にすぎません。実際の運用上の問題は、誰がコネクタを承認したか、どの OAuth スコープが付与されたか、どのツールが呼び出されたか、どのデータがモデル プロバイダーの境界から出たか、そしてインシデント中にアクセスをどのように取り消すことができるかということです

モデル呼び出しのみをプロキシする AI API ゲートウェイでは、これらの質問に答えることはできません。テナント、モデル、API キー、プロンプトのサイズ、コストがわかっている可能性があります。モデルが人間のユーザーの OAuth トークンの下で動作するコネクタに作業を委任したことを認識していない可能性があります。このギャップにより、帰属、承認ポリシー、取り消し、監査への対応が弱まります。

実際的なパターンは、MCP コネクタの承認をファーストクラスのゲートウェイ コントロール プレーン オブジェクトとして扱うことです。コネクタのガバナンスをツール名の許可リストに落とし込まないでください。 API キー管理、モデル アクセス、テナント ポリシー、使用状況分析をすでに処理している同じガバナンス層の一部として、コネクタの登録、OAuth トークンの来歴、ツール スコープの分類、承認ポリシー、失効状態、監査ログを管理します。

事実、推奨事項、予測

事実: OpenAI は、リモート MCP を応答 API ツール カテゴリとして文書化し、アプリケーションがリモート MCP サーバーに OAuth アクセス トークンを提供できるようにします。 OpenAI は、Gmail、Google Drive、Google Calendar、Dropbox、Microsoft Teams などのホストされたサービス コネクタも識別します。 OpenAI のデータ管理ドキュメントには、リモート MCP サーバー ツールで使用される MCP サーバーはサードパーティ サービスであり、そこに送信されるデータはそれらのサービスの保持ポリシーの対象になると記載されています。 Anthropic のコネクタのドキュメントでは、リモート MCP サーバーを使用するカスタム コネクタについて説明しており、ユーザーは一般に OAuth を通じてコネクタを承認し、後で取り消すことができる権限を備えていることに注意してください。 MCP 認可仕様は、HTTP ベースの MCP トランスポートに OAuth スタイルの認可を使用します。 OAuth RFC 9700 のセキュリティ ガイダンスは、トークン処理、認可コード フロー、およびクライアント セキュリティに関連しています。

推奨事項: ゲートウェイは、運用環境で使用する前にコネクタを登録し、各コネクタ呼び出しをテナント、キー、ユーザー、トークン サブジェクト、およびサーバー ID にバインドし、読み取り/書き込みリスク別にツールを分類し、ディスパッチ前に承認ポリシーを適用し、失効状態を一元管理する必要があります。

予測: リモート MCP の導入により、AI ゲートウェイはモデル ルーティングやトークン メータリングを超えたものになるでしょう。コネクタ ID、OAuth スコープ、承認決定、下流の保持境界を確認できないゲートウェイは、規制された環境、エンタープライズ環境、パートナーが運用する環境では使用することが難しくなります。

ガバナンスの問題はアイデンティティの分裂である

コネクタ呼び出しには少なくとも 3 つの ID が含まれるため、ログやポリシー チェックにマージしないでください。

• ゲートウェイ呼び出し元: API モデル リクエストを送信したキー、サービス アカウント、ワークロード、またはパートナー アプリケーション。
• 委任されたユーザー: Gmail、ドライブ、CRM、カレンダー、支払い、内部データ、またはその他の保護されたリソースへのアクセスを承認した人間またはエンド ユーザー。
• コネクタ ターゲット: ツール呼び出しを受信し、別のシステムに転送する可能性があるリモート MCP サーバーまたはホスト型サービス コネクタ。

これらの ID が user という 1 つのフィールドに集約されると、監査証跡があいまいになります。運用サービス アカウントは、20,000 人のエンド ユーザーに代わってリクエストを送信できます。 1 人の人間が、異なるスコープを持つ複数のコネクタを承認する場合があります。リモート MCP サーバーは、複数のダウンストリーム サービスによってサポートされるツールを公開する場合があります。ゲートウェイには、3 つすべてに個別のフィールドが必要です。

有用なイベント モデルは次のようなフィールドで始まります:

{
  "request_id": "req_01J...",
  "tenant_id": "tenant_acme",
  "gateway_key_id": "key_support_bot_prod",
  "workload_id": "support_agent",
  "end_user_id": "user_7421",
  "connector_id": "conn_google_drive_support",
  "mcp_server_url_hash": "sha256:...",
  "oauth_subject": "google-oauth-sub:...",
  "tool_name": "drive.files.search",
  "tool_action_class": "read",
  "approval_decision": "auto_allowed",
  "retention_class": "third_party_standard",
  "downstream_request_id": "optional_provider_or_connector_id"
}

この構造により、セキュリティ、財務、プラットフォームの各チームが同じレコードから異なる質問に答えることができます。どのテナントがツールを起動したか?どのアプリケーション キーがそれを実行したのでしょうか?どのエンド ユーザーがアクセスを委任したか?どのコネクタがデータを受信しましたか?アクションは読み取り専用でしたか、それとも破壊的でしたか?承認は必要でしたか?

コネクタをゲートウェイ リソースとしてモデル化する

コネクタは実稼働環境で使用する前に登録する必要があります。登録は遅くする必要はありませんが、ポリシーが参照できる耐久性のあるオブジェクトを生成する必要があります。

最小限のコネクタ リソースには次のものを含めることができます:

• tenant_id: コネクタの使用を許可されたテナントまたは組織。
• connector_id: サーバーの表示名に依存しない、安定した内部識別子。
• server_url: リモート MCP サーバーの URL またはホストされたコネクタの識別子。
• owner_user_id: 登録した管理者またはユーザー。
• authorization_server: 発行者または認可サーバーのメタデータ（利用可能な場合）。
• allowed_tools: ツール名とバージョンまたはフィンガープリントを確認しました。
• tool_classes: 読み取り、書き込み、エクスポート、管理、支払い、メッセージング、または不明。
• approved_scopes: OAuth スコープがコネクタに対して承認されました。
• retention_class: 内部、モデルプロバイダー、サードパーティ標準、または機密性の高いワークロードでは禁止されています。
• revocation_status: アクティブ、user_revoked、tenant_disabled、期限切れ、隔離、または拒否されました。

これは、モデル プロファイルまたはプロバイダーの資格情報レコードと精神的に似ていますが、コネクタの承認はアップストリーム モデル キーと同じオブジェクトではありません。プロバイダーのランタイム資格情報により、ゲートウェイはモデル API を呼び出すことができます。コネクタ トークンは、サードパーティまたは内部システムへの委任された権限を表します。これらには、個別の出所、保管管理、および監査ポリシーが必要です。

OAuth 個のトークンを意図的にブローカーまたは検証する

一般的な実装パターンは 2 つあります。

ゲートウェイ仲介型 OAuth

このモデルでは、ゲートウェイは OAuth フローを開始または調整し、リフレッシュ トークンまたはアクセス トークン マテリアルをボールトに保存し、有効期間の短いコネクタ セッションを作成し、リモート MCP 呼び出しをディスパッチするときにアクセス トークンを添付します。これにより、ゲートウェイは同意、トークンの有効期間、取り消し、監査結合を強力に制御できるようになります。

トレードオフは複雑さです。ゲートウェイは、同意画面、認可コード フローのセキュリティ、トークンの更新、トークンのローテーション、暗号化ストレージ、リダイレクト URI 管理、発行者の検証、およびテナント固有の OAuth アプリケーション構成を処理する必要があります。このパターンではゲートウェイが OAuth クライアントの責任に近づくため、RFC 9700 がここで重要になります。

アプリケーション管理 OAuth

このモデルでは、アプリケーションは OAuth トークンを取得し、リモート MCP コネクタを呼び出すときにモデルまたはゲートウェイ パス経由でそれを渡します。既存の製品にはすでにコネクタ認証フローがある可能性があるため、これにより出荷が早くなる可能性があります。

その代償として、ガバナンスが断片化されます。ゲートウェイが不透明なトークンのみを認識する場合、ゲートウェイはトークンのサブジェクト、スコープ、発行者、鮮度、失効ステータス、または同意の出所を認識できない可能性があります。このパターンのより安全なバージョンでは、アプリケーションが各呼び出しで署名付きコネクタ メタデータを提供する必要があり、ゲートウェイはディスパッチ前に発行者、対象者、有効期限、コネクタ登録、ユーザー バインディング、承認されたスコープを検証する必要があります。

電子メール、カレンダー、ストレージ、CRM、支払いなどのユーザー データ コネクタの場合は、ユーザーごとの OAuth トークンを優先します。共有の長期有効ベアラー トークンは、テナントを範囲とする明示的なサービス アカウント ワークフローに限定し、リスクの高いリソースとしてレビューする必要があります。

ディスパッチ前にツール スコープを正規化する

MCP サーバーはツール名とメタデータを公開でき、一部のエコシステムは読み取り専用のアノテーションなどのヒントを提供します。これらのシグナルを使用しますが、サーバーが提供するメタデータを完全に信頼できるものとして扱わないでください。ツールのメタデータは、間違っている、古い、曖昧である、または敵対的である可能性があります。 OWASP の MCP ガイダンスでは、最小権限、許可リスト、認証、認可、監視が強調されています。 MCP トップ 10 の研究は、ツール汚染のリスクにも注意を喚起します。

ゲートウェイは、独自の正規化されたアクション クラスを維持する必要があります:

• 読み取り: 既存のコンテンツを検索、リスト、取得、フェッチ、取得、要約します。
• 書き込み: 作成、更新、編集、ラベル付け、移動、コメント、スケジュール。
• 送信: 電子メール、チャット メッセージ、Webhook、チケット応答、通知。
• 削除: 削除、パージ、アーカイブ、取り消し。
• エクスポート: 一括ダウンロード、ファイル転送、データセット抽出。
• 財務: 請求、払い戻し、請求書、支払い、サブスクリプションの変更。
• 管理者: 権限の変更、ユーザーの招待、役割の更新、ポリシーの編集。
• 不明: レビューされていないもの、または自信を持って機密扱いされていないもの。

次に、生のツール名の代わりに正規化されたクラスにポリシーを適用します。例:

policy connector_default {
  allow read when tenant.connector_risk in ["low", "medium"]
    and user.authorization_age_days <= 90
    and connector.retention_class != "prohibited";

  require_approval send, write when connector.risk != "low";
  require_approval export, delete, financial, admin;
  deny unknown;
}

これにより、コネクタが gmail.search の名前を mail.messages.query に変更しても、ポリシーが安定した状態に保たれます。未加工のツールはまだレビューが必要ですが、承認システムは運用カテゴリに基づいて判断できます。

発送前のコネクタ チェックを実行する

ゲートウェイは、モデルによって開始されたコネクタ呼び出しを許可する前に、コンパクトなディスパッチ前の決定を実行する必要があります。ここでは、AI 使用状況分析、セキュリティ ポリシー、承認ワークフロー、保持ポリシーが連携します。

実際のシーケンスは次のとおりです:

1. テナントとキーを解決します: ゲートウェイ キー、テナント、ワークロード、環境、モデル リクエストを特定します。
2. エンド ユーザーを解決します: 委任されたコネクタには安定したエンド ユーザー ID が必要です。明示的に許可されていない限り、匿名の委任された呼び出しを拒否します。
3. コネクタを解決します: サーバー URL またはホストされたコネクタ ID を登録されたコネクタ リソースと照合します。
4. トークンの検証: 発行者、該当する場合は対象者、有効期限、サブジェクト、テナント バインディング、失効状態、および必要なスコープを確認します。
5. 分類アクション: 読み取り、書き込み、送信、削除、エクスポート、財務、管理、または不明のマップ ツール名とメタデータ。
6. 保持境界を確認する: ワークロードがサードパーティ MCP サーバーの処理とログを許可するかどうかを判断します。
7. 承認ポリシーを適用する: 自動許可、ユーザーの承認が必要、管理者の承認が必要、ブロック、または隔離。
8. 請求可能な場合は予算を予約します: コネクタの実行に直接または間接的な料金がある場合は、ディスパッチ前に予算を予約します。
9. 決定を書き込みます: 成功後だけでなく、コネクタを呼び出す前にも決定を保持します。

最初に決定を書くことが重要です。コネクタがタイムアウトした場合、部分的な出力をストリーミングした場合、またはダウンストリーム エラーをトリガーした場合でも、ゲートウェイが特定の試行アクションを許可または拒否したことが監査ログに表示されます。

承認はワークフローを意識する必要があります

通話ごとの承認は理由が簡単ですが、実際には使用できないことがよくあります。チケットの読み取り、ドライブの検索、メールの下書き、CRM レコードの更新を必要とするカスタマー サポート エージェントは、無害な読み取り操作ごとにユーザーにモーダルを強制すべきではありません。同時に、モデルがツールを選択したからといって、電子メールの送信、ファイルの削除、支払いの返金、またはフォルダーのエクスポートをサイレントに委任すべきではありません。

実行可能なポリシーは階層化されています:

• 低リスク テナント用のレビュー済み読み取り専用ツールと新規ユーザー認証を自動的に許可します。
• 送信、作成、更新、削除、エクスポート、財務、および管理アクションには承認が必要です。
• 名前付きワークフロー、スコープ、時間枠に対するグループ化された承認を許可します。
• 範囲が拡大する場合、ツール定義が大幅に変更される場合、またはコネクタがより高いリスク クラスに移行する場合は、再承認が必要です。
• レビューされるまで不明なツールをブロックします。

グループ化された承認は明示的に行う必要があります。ユーザーは、「今後 30 分間、このサポート ワークフローでドライブの検索と返信の下書きを許可しますが、送信する前に確認が必要です。」を承認できます。これは、バイナリ コネクタの許可/拒否スイッチよりも便利です。

保持境界には独自のフィールドが必要

リモート MCP 呼び出しは、モデル プロバイダーの保持および処理境界の外にデータを移動する可能性があります。それは自動的に間違いになるわけではありませんが、目に見えるものでなければなりません。 1 つのデータ保持設定でモデル エンドポイントの使用が許可されているワークロードでも、異なる保持期間を持つサードパーティ MCP サーバーに同じコンテンツを送信することは禁止される場合があります。

ワークロードとコネクタの両方に保持分類を追加します。クラスの例:

• internal_only: サードパーティのコネクタ呼び出しは許可されません。
• approved_processors_only: コネクタは承認されたベンダー リストに載っている必要があります。
• third_party_standard_allowed: 標準の SaaS コネクタ処理が許可されます。
• no_argument_logging: コネクタ呼び出しは許可されますが、引数は編集またはハッシュする必要があります。
• export_blocked: 読み取り/検索は許可されますが、一括エクスポートは拒否されます。

ここで、ゲートウェイが微妙な間違いからチームを保護します。つまり、モデル プロバイダーのデータ制御がエージェントが使用するすべてのツールに自動的に適用されると想定しています。これらは、データがリモート MCP サーバーまたは外部サービス コネクタに送信されると必ずしも適用されるわけではありません。

コネクタ監査台帳を構築する

コネクタ監査台帳は、モデルのリクエスト、ゲートウェイの承認、コネクタのディスパッチ、およびダウンストリームの結果を結合する必要があります。各プロバイダーがツール イベントを異なる方法で公開する可能性があり、アプリケーション ログでトークンまたは承認コンテキストが省略される可能性があるため、生のプロバイダー トレースのみに依存しないでください。

推奨される元帳フィールドは次のとおりです:

• model_request_id とトレース ID.
• tenant_id、gateway_key_id、ワークロード、環境、エンドユーザー ID。
• connector_id、サーバー URL ハッシュ、ホストされたコネクタ識別子、およびリスク クラス。
• tool_name、ツールのバージョンまたはメタデータのフィンガープリント、および正規化されたアクション クラス。
• OAuth 発行者、トークン サブジェクト、スコープ セット ハッシュ、有効期限バケット、およびトークンの出所。
• 引数ハッシュ、編集された引数、機密クラス、保持クラス。
• 承認決定、承認者、承認範囲、承認有効期限。
• ディスパッチ ステータス、応答ステータス、エラー クラス、レイテンシ、およびダウンストリーム リクエスト ID (可能な場合)。

完全な引数のログはインシデント対応に役立ちますが、プライバシーと保持のリスクも増大します。デフォルトでは、構造化フィールド、ハッシュ、選択的編集、機密タグが優先されます。明示的なインシデントまたは有効期限のあるデバッグ ポリシーの下でのみ、完全なキャプチャを許可します。

失効と隔離は製品要件です

取り消しはデータベースを手動で編集することはできません。ユーザーと管理者は、即時のポリシー状態に変換するワークフローを必要としています。

少なくとも次のアクションを実装してください:

• ユーザーの切断: 1 人のユーザーのコネクタ承認のすべてのトークンを取り消すか、非アクティブにマークします。
• テナントの無効化: 無関係なモデル トラフィックを無効にすることなく、テナント全体の 1 つのコネクタをブロックします。
• トークンの有効期限の処理: 更新が失敗した場合、または認証の鮮度がポリシーを超えた場合は、フェールクローズまたは再認証を行います。
• コネクタ隔離: 調査用に構成とログを保存しながらコネクタをブロックします。
• 緊急拒否リスト: サーバー URL ハッシュ、コネクタ ID、発行者、またはツール フィンガープリントによってブロックします。
• スコープのダウングレード: ワークフローが広範なアクセスを必要としなくなった場合、より少ないスコープで再承認します。

実装の重要な詳細は、ディスパッチ時に失効ステータスをチェックする必要があるということです。夜間の同期は調整には役立ちますが、インシデント対応には十分ではありません。

リモート MCP コネクタの適合プローブ

コネクタを運用テナントで使用できるようにする前に、管理された依存関係としてテストしてください。短いプローブ スイートは、多くの統合やポリシーの失敗を検出します。

• メタデータ検出により、安定したサーバー ID と予期されるツール定義が返されます。
• 保護されたリソースのメタデータと認可動作は、該当する場合、文書化された前提条件と一致します。
• 動的クライアント登録要件は理解され、サポートされているか、明示的に無効になっています。
• トークンのないリクエストは安全に失敗します。
• 期限切れのトークンは予想通り失敗し、制御されない再試行はトリガーされません。
• 読み取り/書き込み分類は、説明だけでなく観察された動作とも一致します。
• 不正なツールのメタデータは拒否されるか、不明としてマークされます。
• ツール リストの変更により、名前、範囲、説明、またはリスク クラスが変更されるとレビューが開始されます。
• コネクタ エラーは、機密の引数を汎用エラー フィールドに漏らすことなくログに記録されます。

これらのプローブはセキュリティ レビューに代わるものではありませんが、ゲートウェイにドリフトを検出する反復可能な方法を提供します。リモート MCP サーバーは、モデル プロバイダーやアプリケーションのリリース サイクルとは独立して変更できます。

実装チェックリスト

• テナント、サーバー、承認、スコープ、ツール、リスク、保持、取り消しフィールドを含むコネクタ レジストリを作成します。
• すべてのポリシー決定において、ゲートウェイ キー ID、委任されたエンドユーザー ID、コネクタ ID を分離します。
• コネクタ トークンは認証情報コンテナーに保存しますが、モデル プロバイダーの実行時認証情報とは区別してください。
• ユーザー データ コネクタにはユーザーごとの OAuth を優先します。共有サービス トークンを明示的なサービス アカウント ワークフローに制限します。
• ツールのアクションを読み取り、書き込み、送信、削除、エクスポート、財務、管理、不明に正規化します。
• コネクタの登録、トークンの有効性、スコープの一致、保持の互換性、承認状態、予算の予約についてディスパッチ前チェックを実行します。
• ディスパッチ前にコネクタの決定をログに記録し、応答またはエラー後に最終ステータスを確定します。
• ユーザーの切断、テナントの無効化、コネクタの隔離、緊急拒否リストのワークフローを構築します。
• 運用環境で使用する前に、コネクタのメタデータ、トークンの動作、ツールのドリフト、不正な形式のメタデータを調査します。

実用的な結論

MCP とサービス コネクタは、モデルを実際のシステム上で動作させるため、エージェントを便利にします。同じ便利さにより、コネクタの承認はプロンプト エンジニアリングの詳細ではなく、コントロール プレーンの問題になります。

ゲートウェイは、モデル、トークン数、API キー以上の情報を知っている必要があります。どのコネクタが呼び出されたか、どのユーザーがそれを承認したか、どのスコープが付与されたか、どのツール アクション クラスが要求されたか、承認が必要かどうか、保持境界に互換性があるかどうか、およびアクセスを取り消す方法を認識する必要があります。コネクタ レジストリ、ディスパッチ前のポリシー チェック、結合された監査台帳から始めます。次に、コネクタの使用量の増加に応じて、OAuth 仲介、グループ化された承認、適合調査、緊急隔離を追加します。

目標は、リモート MCP の導入をブロックすることではありません。目標は、コネクタ アクセスを帰属可能、取り消し可能、レビュー可能にし、チームがすでにモデル アクセスと OpenAI 互換の API ゲートウェイに適用しているのと同じガバナンス期待と互換性を持たせることです。

関連資料

• より広範なエージェント ツール ガバナンス パターン