エンタープライズMCPアクセス制御：ツール、サーバー、エージェントの管理

現在、本番環境で実際に起こっているシナリオをご紹介します。

標準のオープンソースGitHub MCPサーバーをデプロイします。目標は単純です。エンジニアリングサポートエージェントに課題のコメントを読み込ませ、チームのために要約させたいのです。それは完璧に機能します。エージェントは接続し、list_toolsハンドシェイクを実行して、データの取得を開始します。

2日後、その同じエージェントがハルシネーションを起こします。スレッドを要約する代わりに、誤解したコメントに基づいてリポジトリが「非推奨」であると判断し、delete_repoを呼び出します。

なぜこのようなことが起こったのでしょうか？プロンプトインジェクション攻撃ではありませんでした。悪意のある内部犯行でもありませんでした。それは根本的なアーキテクチャの欠陥でした。

GitHubで見られるStripe、Postgres、Kubernetesサーバーのような標準のGitHub MCPサーバーはバイナリです。それはラップするすべてのAPIエンドポイントを公開します。サーバーがdelete_repoをサポートし、エージェントに接続文字列を与えれば、エージェントはdelete_repoを実行できます。ツール機能のためのネイティブな.gitignoreはありません。JSON-RPCツール定義のためのchmodもありません。

しかし、標準のMCP実装には粒度が欠けているため、私たちは最も重要なインフラストラクチャに「ルートアクセス」を持つエージェントを日常的にデプロイしています。

これは企業での導入には不向きです。これ以上「AIポリシー文書」やシステムプロンプトでの厳しい警告は必要ありません。私たちが必要としているのは、MCPサーバーを安全でスコープが限定されたインターフェースに分割するアーキテクチャパターンです。

私たちはこれを仮想MCPサーバーと呼んでいます。

アーキテクチャ：アグリゲーター vs プロキシ

これを解決するには、LLMとツールの間でトラフィックをどのようにルーティングするかを検討する必要があります。現在、エコシステムには2つの主要なパターンが出現しています（GartnerやTrueFoundryのドキュメントでよく引用されています）：アグリゲーターとプロキシです。

• アグリゲーターパターン これは「入門」アプローチです。単一のエンドポイントを設定し、それが複数の基盤となるサーバーに分散されます。
  
  • トラフィックフロー： Agent -> Aggregator -> [Server A, Server B, Server C]
  • 問題点： 設定は簡単ですが、単一障害点となります。さらに悪いことに、通常は完全な機能リストをそのまま渡してしまいます。 すべての 接続されたサーバーの情報をエージェントに返します。これにより、スタック内のすべてのツールを認識する「ゴッドモード」エージェントが作成されます。
• プロキシパターン（エンタープライズ標準） ここが重要です。プロキシは、エージェントと実行レイヤーの間に位置するスマートなサイドカーまたはゲートウェイとして機能します。厳密な1対1または1対Nのマッピングを作成しますが、決定的な違いがあります。それは、単にパケットをルーティングするだけではないということです。

プロキシは、リクエストがバックエンドに到達する前にペイロード検査を実行し、危険なツールを検出時に削除できるようにします。これにより、tools/list JSON-RPC応答を傍受し、エージェントが知るべきではないツールを厳密に削除することができます。

実装：「仮想サーバー」パターン

ここから、中核となる実装パターンである仮想MCPサーバーについて説明します。

仮想MCPサーバーは論理的な構成要素です。物理MCPサーバーから特定のツールを参照しますが、その実行ロジックを複製したり、インフラストラクチャを再デプロイしたりすることはありません。ここで、 MCPとAPI がエンタープライズチームにとって実用的になります。従来のAPIは通常、エンドポイントレベルでアクセスを制限しますが、MCPは、エージェントが呼び出しを行う前に、検出時にどのツールを表示するかを決定する必要もあります。SQLのVIEWのように考えてみてください。基盤となるテーブル（物理サーバー）を変更することなく、特定のユーザー（エージェント）にデータの制限されたサブセット（この場合は機能）を提示できます。

本番環境のゲートウェイアーキテクチャでこのパターンを実装する方法は次のとおりです。

ステップ1：バックエンド接続（「サービスアカウント」） まず、生の、高権限のMCPサーバーをゲートウェイに接続します。

• 接続： ゲートウェイは、postgres-masterまたはgithub-admin MCPサーバーへの永続的な接続を確立します。
• 認証情報管理： ゲートウェイは、これらのサーバーで認証するために必要な「サービスアカウント」または管理者認証情報を保持します。
• 分離： 決定的に重要なのは、エージェントは 決して これらの認証情報を見ることはありません。エージェントはツールではなくゲートウェイに接続します。ゲートウェイが金庫の役割を果たします。

ステップ2：スライス（マニフェスト） 次に、仮想サーバーマニフェストを定義します。これは、物理サーバーのどのツールが特定のAgentスコープに公開されるかを正確に定義する設定ファイル（通常はYAMLまたはJSON）です。

github-allへのアクセスを許可する代わりに、スライスを作成します。典型的な仮想サーバー構成は次のようになります。

ステップ3：クライアントビュー（ハンドシェイク） Agentが接続を初期化する際、Gatewayと標準のJSON-RPC tools/listハンドシェイクを実行します。

Agentがsupport-agent-scope仮想サーバーに接続されているため、Gatewayはこのリクエストを傍受します。ステップ2で定義されたマニフェストに対してマスターリストをフィルタリングし、サニタイズされたリストを返します。

その結果は？Agentがdelete_repoの呼び出しを幻覚することは技術的に不可能です。その関数は、そのコンテキストウィンドウには存在しないからです。モデルに「それをするな」と指示しただけでなく、それを行うために使うであろう「手」を取り除いたのです。

TrueFoundryの役割 

では、TrueFoundryはこのアーキテクチャのどこに位置するのでしょうか？

ホスティング層としてでも、便利なラッパーとしてでもありません。本番のMCPスタックでは、TrueFoundryはプロトコルゲートウェイおよびコントロールプレーンとして機能します。LLMランタイムとツールの間の実行パスに直接位置し、そこで強制的な制御が可能です。

この位置付けは重要です。ゲートウェイがMCP接続を終端するため、JSON-RPCペイロードをリアルタイムで解析し、推論することができます。単にリクエストを転送しているだけではありません。ツールが実行される前に、意図、ID、スコープを解釈しています。

これにより、3つの具体的なエンジニアリング機能が実現します。

• IDインジェクション（代理実行）。

ほとんどのDIYエージェントスタックは、「汎用キー」の問題に悩まされています。エージェントは共有APIトークンで実行されるため、問題が発生した場合、ログには「エージェントが実行した」としか表示されません。責任の所在が不明確です。TrueFoundryのゲートウェイは、受信したクライアントJWTを検査し、認証された人間ユーザーにマッピングし、適切なOAuthまたはサービスキーをダウンストリームに注入します。アリスがリポジトリを削除できない場合、彼女に代わって動作するエージェントも削除できません。エージェントの権限はもはや理論的なものではなく、暗号学的に拘束されます。

• 仮想サーバーのランタイム強制。

ゲートウェイは、仮想MCPサーバーが現実のものとなる場所です。TrueFoundryは、仮想サーバーのスコープを物理MCPサーバーと許可されたツールにマッピングするルーティングテーブルを維持します。エージェントが宣言されたスライスの外部にあるものを呼び出そうとすると、ゲートウェイは構造化されたJSON-RPCエラーを返します。モデルはサイレントな失敗を受け取ることはありません。明確な「ツールが見つかりません」というメッセージを受け取り、幻覚を起こす代わりに自己修正するのに役立ちます。

• トラフィックの検査とリプレイ。

ゲートウェイが接続を終端するため、MCPトラフィックをバッファリングし、トレースすることができます。これにより、ツールインタラクションのPCAPスタイルの検査が可能になります。エージェントがループに陥ったり、誤った判断を下したりした場合でも、それに至った高価な推論ステップを再実行することなく、正確なツール呼び出しシーケンスをリプレイできます。デバッグは推測から検査へと移行します。

‍

これらを総合すると、エージェントが適切に動作することを期待することと、エージェントが不正な動作をできないように強制することの違いです。アクセス制御はプロンプトから、本来あるべきインフラストラクチャへと移行します。

多層防御：プロトコル層でのガードレール

仮想サーバーはエージェントがどのツールを使用できるかを制御し、ガードレールはそれらのツールの使用方法を制御します。エージェントが単に 許可されているからといって `sql_query`を呼び出すことが許可されているからといって、`SELECT * FROM users`を実行して顧客データベース全体をコンテキストウィンドウにダンプすることが許可されるべきだという意味ではありません。

ここでガードレールの出番です。TrueFoundryのアーキテクチャでは、ガードレールはプロトコル層でJSON-RPCペイロードを傍受し、実行前にトラフィックを検査するミドルウェアとして機能します。

入力ガードレール（エージェントのための「WAF」）Pythonミドルウェアやシンプルな正規表現ルールを記述して、ツール引数を検証できます。 前に リクエストがバックエンドコンテナに到達する

• シナリオ： エージェントがLIMIT句のないクエリを実行しようとし、データベースをクラッシュさせたり、トークン使用量で多大なコストを発生させたりする可能性があります。
• 解決策： 入力ガードレールが`sql_query`ツールを傍受します。引数ペイロードをチェックし、LIMITが欠落している場合、リクエストを拒否するか、自動的にデフォルトの`LIMIT 100`を挿入します。
• セキュリティのユースケース： 正規表現フィルターは、入力引数内のAPIキーや秘密鍵のようなパターンを検出でき、エージェントが誤って機密情報をサードパーティのロギングツールに漏洩するのを防ぎます。

出力ガードレール（データ損失防止） エージェントは「冗長な情報漏洩」を起こしがちで、必要以上のデータを取得し、それを要約してしまうことがあります。

• メカニズム： 出力ガードレールは、ツールからのJSONレスポンスをサニタイズします。 前に それがLLMに渡される
• 実装： データベースツールがssnまたはcredit_cardという名前の列を返した場合、ガードレールはこのデータをJSON-RPC応答でハッシュ化またはマスクできます（例：****-1234）。LLMは機密データをコンテキストウィンドウに保持することなく、必要なコンテキスト（「クレジットカードが存在します」）を取得します。

可観測性：「思考プロセス」の追跡

従来のソフトウェアでは、API呼び出しが失敗した場合、ログを確認します。そこには「500 Internal Server Error」とスタックトレースが表示されます。

エージェントシステムでは、「失敗」はしばしば表面化しません。エージェントはツールを呼び出し、結果を得ますが、それを誤って解釈します。あるいは、技術的には機能するものの、不正なデータを返すような、わずかに間違った引数でツールを呼び出すこともあります。標準的なアプリケーションログには「200 OK」と表示されますが、結果は間違っています。

これをデバッグするには、MCP用の分散トレーシングが必要です。

TrueFoundryは、エージェントの実行チェーンのウォーターフォール表示を提供します。「リクエスト失敗」と表示されるだけでなく、各ホップでのレイテンシーとペイロードを確認できます。

• スパンA（推論）： LLMは思考の生成に200ミリ秒を費やします。
• スパンB（ゲートウェイ）： ゲートウェイはJWTの検証とリクエストのルーティングに10ミリ秒かかります。
• スパンC（ツール実行）： Postgresコンテナはクエリの実行に1.5秒かかります。

これが重要な理由：スパンCにドリルダウンして、 まさにその エージェントが生成したSQLクエリを確認できます。エージェントが存在しないテーブル名を幻覚のように生成している、または非推奨のAPIパラメータを使用していることに気づくかもしれません。このプロトコルレベルの可視性がなければ、推測でブラックボックスをデバッグすることになります。

結論：イネーブラーとしてのセキュリティ

「チャットボット」から「エージェント」への移行は、実質的に「テキスト生成」から「リモートコード実行」への移行です。この現実こそが、ほとんどの企業パイロットがPoC段階で停滞する原因となっています。

TrueFoundryはそのギャップを埋めます。AIゲートウェイを介して仮想MCPサーバーパターンを実装することで、セキュリティチームに確率的モデルを信頼するよう求めるのをやめ、決定論的なアーキテクチャを示すようになります。単にツールをデプロイするだけでなく、スコープが限定され、IDを認識する、本質的に爆発半径を制限するインターフェースをデプロイするのです。

企業にとって、TrueFoundryはMCPの「パイプ」を提供するだけでなく、バルブ、ゲージ、ロックも提供します。無謀な「ルートアクセス」エージェントを、信頼できるデジタル従業員に変えるのです。RBACなしで本番Kubernetesクラスターを運用しないのと同じように、TrueFoundryなしでエンタープライズエージェントスタックを運用すべきではありません。