エージェントにツールの鍵を渡さない:MCPゲートウェイの設計

AIエージェントがツールを直接呼ぶ構成では、エージェントのプロセス自身がデータベースのパスワードや内部APIのトークンを保持します。プロンプトインジェクションやログの漏えいが、そのまま認証情報の漏えいになります。

Model Context Protocol(MCP)はツール呼び出しの形式を標準化しましたが、「誰が鍵を持つか」は解決しません。そこを担うのがゲートウェイです。

呼び出しをプロキシする

nRouterのMCP Gatewayでは、エージェントはMCPサーバーへ直接接続しません。ツール呼び出しはゲートウェイのエンドポイント(共有の /mcp と、サーバーごとの /mcp/{server_id})を経由します。

ヘッダーを除去し、秘密をサーバー側で注入する

プロキシはまず、呼び出し元の Authorization、Cookie、X-Api-Key ヘッダーを厳格な許可リストに基づいて除去します。そのうえで、ツール側の認証情報を保管庫(vault)からサーバー側で付与します。エージェントは秘密を受け取らず、記録もできず、漏らすこともできません。ローテーションは保管庫の1か所で完結します。

呼び出し自体を検証する

パラメータはスキーマで検証され、不正なSQLやコマンドインジェクションの形状をした呼び出しは実行前に止まります。タイムアウトとサーキットブレーカーは暴走したエージェントのループを遮断します。権限は仮想キーごとに設定でき、読み取り専用と変更系のスコープ分離、危険なシェル実行の禁止、機微な操作への承認ゲートが可能です。

モデルを替えてもツールはそのまま

ゲートウェイは OpenAI の function calling、Anthropic の tool use、ネイティブMCP(JSON-RPC)の形式変換を行います。ネイティブ対応していないモデルでもMCPツールが使え、モデル変更でツールを書き直す必要がありません。

1つのトレースで追う

各ツールの実行は、レイテンシ、ペイロードサイズ、戻りコード、エラーとともに記録され、原因となったLLMリクエストと単一のリクエストIDで結ばれます。障害調査は2つのシステムの突き合わせではなく、1つのタイムラインを読む作業になります。

MCPサーバー自体は移行不要で、自社VPC内、トンネル経由、公開エンドポイントのいずれでも運用できます。設計の詳細は nRouter の MCP Gateway ページにあります: https://nrouter.ai/product/mcp