エンタープライズMCPガバナンス：大規模なMCPサーバーアクセスを制御、監査、保護する方法

今すぐセキュリティチームに、組織全体で稼働しているMCPサーバーの数を尋ねてみてください。もし彼らが自信を持って答えられるなら、あなたはほとんどの企業よりも先行しています。もし答えられないなら、すでに本番環境でガバナンスの問題を抱えていることになります。

MCPの導入は急速に進みました。チームは、ITレビューなし、認証情報ポリシーなし、そしてセキュリティチームがそれらのサーバーが何にアクセスできるかを確認する手段がないまま、MCPサーバーを介してエージェントをGitHub、Slack、社内データベース、サードパーティAPIに接続しました。このプロトコルは、ツール接続を容易にするため、まさに有用です。その容易さが、管理されていないMCPの導入を真のセキュリティリスクにしているのです。

MCPサーバーは受動的なAPIではありません。それらはAIエージェントに機密システムへの直接的かつプログラム的なアクセスを提供します。これらのエージェントは、レビューされたコードパスではなく、自律的な推論に基づいて動作します。メドトロニックのあるエンタープライズセキュリティリーダーは、「MCPは非常に迅速に多くの損害を引き起こす多くの機会を生み出す」と述べています。ガートナーは、マルチモーダルアプリケーションを構築するソフトウェアエンジニアリングチームの70%が2028年までにAIゲートウェイを使用すると予測しており、これは2025年の25%から増加します。今ガバナンスを構築しているチームこそが、安全に規模を拡大できるチームとなるでしょう。

このガイドでは、企業向けMCPガバナンスに何が必要か、標準的なセキュリティツールではなぜ不十分なのか、コンプライアンスチームが信頼できる4つの柱からなるフレームワークを構築する方法、そしてTrueFoundryがこれらすべてを独自のクラウド内でどのように実装するかについて説明します。

企業向けMCPガバナンスに求められるもの

企業向けMCPガバナンスとは、組織内にどのMCPサーバーが存在するか、誰がそれらにアクセスできるか、何を許可されているか、そして使用時に何が記録されるかを管理するための完全な運用フレームワークです。それはポリシー文書ではありません。それは強制力のあるインフラです。

ほとんどのチームはその範囲を過小評価しています。ガバナンスは環境内のすべてのMCPサーバーを対象とします。開発者がITレビューなしで接続したサードパーティツール、製品チームが構築・展開した社内ツール、そしてCursor、Claude Code、および同様のツールにおけるIDE構成内に組み込まれたMCPサーバーが含まれます。MCPサーバーが本番システムに到達できる場合、それは対象範囲内です。

MCPガバナンスは、その構築方法において重要な点で、標準的なAPIガバナンスとは異なります。REST API呼び出しは、開発者が記述しレビューした決定論的なコードパスを実行します。対照的に、MCPツールの呼び出しは、AIエージェントが実行時にその推論に基づいて行う自律的な決定です。脅威モデル、監査要件、および説明責任を維持するために必要な制御はすべて異なります。MCPを従来のAPI統合のように扱うと、組織は規制当局に説明できない監査ギャップを抱えることになります。

• 範囲： すべてのMCPサーバー。これには、製品チームが構築した社内サーバー、CI/CDパイプラインで稼働するサーバー、そして開発者がIDEでローカルに設定したものすべてが含まれます。

• メカニズム： すべてのクライアントとすべてのMCPサーバー間の集中型ゲートウェイ。ゲートウェイがポリシーを強制します。個々のMCPサーバーは独自のアクセス制御を実装しません。これにより、このアプローチは何百ものサーバーにわたってスケーラブルになります。

• 結果： すべてのツール呼び出しは、検証済みのIDに対して認証され、コンプライアンスレビューやインシデント調査に耐えうる構造化されたクエリ可能な形式でログに記録されます。

企業が無視できないMCPセキュリティリスク

MCPサーバーはAIエージェントの推論ループ内で動作します。従来のAPI呼び出しは、アプリケーションコードによって決定論的にトリガーされます。対照的に、MCPツールの呼び出しは、エージェントが実行時に特定のタスクに適したツールであると判断したときにトリガーされます。その決定は、明示的に定義された制御フローではなく、モデルの推論によって影響を受けます。これにより、開発者が通常持つ、ツールがどのように、なぜ呼び出されるかについての可視性が低下します。このモデルでは、推論が実質的に制御パスの一部となりますが、標準的なアプリケーションセキュリティツールでは直接観測できません。

セキュリティ研究者は、これを本番環境で文書化しています。MCPツール記述を介して行われるプロンプトインジェクション攻撃は、コードを一行も変更することなくエージェントの動作をリダイレクトします。不適切に設定されたMCPサーバーを介した認証情報の漏洩は、境界制御が監視するように設計されていなかったアクセスパスを作成します。これらは研究論文からの理論的な攻撃シナリオではありません。これらは、実際の企業導入における文書化されたインシデントです。

シャドウMCPサーバーのデプロイは標準的なアクセス制御をバイパスする可能性がある

開発者がITレビューなしにMCPサーバーをデプロイまたは接続すると、通常新しいシステム統合に適用されるあらゆる管理プロセス（ベンダーのセキュリティ評価、データアクセス分類、アクセスプロビジョニングワークフローなど）がスキップされます。その結果、サーバーは他のすべてのエンタープライズシステムが備えるべきドキュメント、監視、制限が一切ない状態で本番稼働に入ります。

中央レジストリがないと、基本的なセキュリティに関する質問に信頼できる答えが得られません。どのMCPサーバーが稼働しているのか？どのような認証情報を持っているのか？どのデータベースにクエリできるのか？どの外部サービスを呼び出せるのか？このような可視性の欠如により、これらのサーバーは脆弱性評価、ベンダーリスクレビュー、ペネトレーションテストの対象から完全に外れてしまいます。

内部CRMやコードリポジトリへの読み取りアクセス権を持つ未承認のMCPサーバーが1台あるだけで、境界防御では捕捉できない監査されていないデータパスが生まれます。トラフィックはネットワーク内部、つまり本来そこにあるべき開発者マシンから発信されるためです。

ツール説明ポイズニングによるネットワーク層防御の迂回

エージェントがMCPサーバーに接続してtools/listを呼び出すと、サーバーはツール名、説明、パラメータスキーマを応答します。エージェントはそのメタデータを使用して、どのツールを呼び出すか、どのように呼び出すかを決定します。このメタデータを操作すれば、コードの脆弱性を悪用することなくエージェントの動作をリダイレクトできます。

ツール説明ポイズニングは、ツールメタデータ内に悪意のある指示を埋め込み、エージェントに意図しない動作（データの持ち出し、意図された範囲外のツールの呼び出し、安全チェックの迂回など）を実行させます。これは、割り当てられたタスクを実行しているように見せかけながら行われます。悪意のあるコンテンツは、MCPサーバーからのHTTPレスポンスボディ内、特にtools/listペイロード内に含まれて伝送されます。標準的なWebアプリケーションファイアウォールやAPIセキュリティツールはHTTPレスポンスボディを可視化できますが、既知のエクスプロイトシグネチャや不正なヘッダーのような構文上の異常ではなく、意味的に埋め込まれた自然言語であるため、この攻撃を捕捉することはできません。この攻撃は、エージェントがツール説明を正当な指示として解釈し、それに基づいて行動する推論層で成功します。

TrueFoundryのMCP Pre Toolガードレールは、モデルベースのプロンプトインジェクション検出を使用して、実行前にツールパラメータと呼び出し引数を検査します。ツール呼び出し引数にリダイレクトされた指示が含まれている場合、ツールが実行される前に実行がブロックされ、検出はリクエストトレースに記録されます。

共有MCPサーバー認証情報によるコンプライアンス説明責任の喪失

共有APIキーやサービスアカウントトークンを使用するMCPサーバーは、コンプライアンスフレームワークが要求する帰属可能な監査記録を生成できません。10個のエージェントが1つの認証情報セットを共有している場合、特定のツール呼び出しを特定のユーザー、エージェントインスタンス、またはチームに紐付ける方法はありません。規制された環境において、このギャップは単なる不便ではなく、直接的なコンプライアンス違反となります。

HIPAAは、保護された医療情報へのすべてのアクセスについて、識別可能なユーザーまたはサービスに帰属する監査証跡を要求しています。SOC2 CC6は、実施の証拠を伴うアクセス制御を要求しています。GDPRの説明責任原則は、組織がデータ処理が承認され文書化されていることを実証することを要求しています。共有認証情報によるMCPデプロイメントは、これらのいずれも満たすことができません。TrueFoundryは、共有認証情報を個々のユーザーに紐付けられたパーソナルアクセストークンと、アプリケーションレベルのアクセス用の仮想アカウントトークンに置き換えることで、すべてのツール呼び出しが検証可能なIDを持つようにします。

エンタープライズMCPガバナンスの4つの柱

完全なエンタープライズMCPガバナンスフレームワークには、連携して機能する4つの機能が必要です。それは、一元化されたカタログ、IDベースのアクセス制御、構造化された監査ロギング、およびリアルタイムのポリシー適用です。それぞれが互いに依存しています。どのサーバーが存在するかを知る前にアクセスポリシーを適用することはできません。IDの帰属なしに監査証跡を構築することはできません。そして、リアルタイムの適用を伴わない事後的な監査ログは、セキュリティ制御ではなく、フォレンジック記録に過ぎません。

4つの柱：主要機能、TrueFoundryの実装、およびコンプライアンスカバレッジ

柱1：一元化されたMCPサーバーカタログ

このカタログは、組織内の承認されたすべてのMCPサーバーの信頼できるレジストリです。各エントリには、情報セキュリティチームがリスクを評価するために必要な情報（サーバー名、所有チーム、データアクセス範囲、認証方法、承認ステータス、接続パラメータ、承認済みユーザーグループやレート制限などの使用制限）が含まれています。

新しいサーバーは、審査ワークフローを経て登録されます。ツール説明のレビューは、サーバーが開発環境に到達する前にポイズニングのリスクをスクリーニングします。データアクセス評価は、サーバーがアクセスできる範囲を決定します。明示的な承認サインオフが配布をゲートします。これらのいずれもMCPサーバー自体への変更を必要としません。これらはカタログ層で発生し、個々のサーバーの実装は手つかずのままです。

カタログは配布も担当します。開発者は、サーバーを手動で設定するのではなく、事前に承認されたサーバー構成をIDE統合に直接取り込みます。カタログで承認されたサーバーのみが開発者マシンに到達します。TrueFoundryの仮想MCPサーバー機能はこれを拡張し、プラットフォームチームが複数の登録済みサーバーから厳選されたツールのサブセットを構成し、新しいインフラストラクチャをデプロイすることなく、特定のチームやユースケースが必要とするものだけを公開できるようにします。

柱2：ゲートウェイ層でのSSOとMCPサーバーアクセス制御

MCPアクセスは、組織内の他のすべてを管理するのと同じIDプロバイダーを介して行われる必要があります。TrueFoundryは、OAuth2の2レッグおよび3レッグフロー、SAML 2.0、およびOkta、Azure Active Directory、Auth0、Cognito、および任意のJWKS互換IdPとの直接統合をサポートしています。MCPアクセスは、メール、リポジトリ、クラウドコンソールをカバーするのと同じオンボーディングおよびオフボーディングワークフローを通じてプロビジョニングおよびデプロビジョニングされます。開発者が退職すると、MCPアクセスも自動的に削除されます。

ゲートウェイは、呼び出し元に応じて3つのインバウンド認証方法をサポートしています。パーソナルアクセストークン（PAT）は、TrueFoundry UIの「設定」>「APIキー」から生成され、個々のユーザーに紐付けられ、開発ワークフローの標準的な選択肢です。仮想アカウントトークン（VAT）は、定義された権限を持つサービスアカウントであり、本番エージェントやサーバー間ワークフローに適しています。外部IdPトークンは、TrueFoundryアカウントを持たないユーザーが自身のIDプロバイダーを使用して認証することを可能にし、B2B SaaSや顧客向けエージェントのデプロイメントをカバーします。

MCPサーバーへのアウトバウンド認証に関して、TrueFoundryは6つのパターンで認証情報のライフサイクル全体を管理します。OAuth認証コードフローは、GitHubやSlackなどのサービスへのユーザーごとのアクセスを処理し、ゲートウェイが同意、トークンストレージ、自動更新を管理します。OAuthクライアントクレデンシャルフローは、サーバー間のアクセスを処理します。共有および個別APIキーモードは、ゲートウェイがリクエストごとに適切な認証情報を挿入する、よりシンプルなケースに対応します。トークンパススルーは、MCPサーバーが直接検証できる場合、インバウンドトークンを変更せずに転送します。x-tfy-mcp-headersヘッダーを介したトークン転送は、MCPサーバーが別の認証情報システムを使用するシナリオを処理します。

MCPサーバーアクセス制御：一般的なエンタープライズシナリオにおける認証パターン

RBACポリシーは、どのチームまたは個人がどのサーバーやツールを呼び出せるかを決定します。これらのポリシーは個々のMCPサーバー内ではなくゲートウェイに存在するため、ポリシーの更新はサーバーの再デプロイなしにすべてのクライアントに即座に適用されます。データサイエンスチームは分析ツールへのアクセス権を得ますが、デプロイサーバーへはアクセスできません。セキュリティチームは監査目的ですべてのサーバーへの読み取り専用アクセス権を得ます。

柱3：すべてのツール呼び出しに紐付けられた構造化監査ロギング

すべてのMCPツール呼び出しには、タイムスタンプ、呼び出し元ID、MCPサーバー識別子、ツール名、入力パラメータ、応答概要、理由付きポリシー決定、実行時間と検出結果を示すフックごとのガードレール結果、および合計レイテンシといった完全な呼び出しコンテキストをキャプチャするログエントリが必要です。これらのフィールドは、SIEMシステムやコンプライアンスレポートツールがクエリできるように、構造化されたJSONである必要があります。

TrueFoundryは2つのレベルでロギングを制御します。リクエストレベルでは、<code>enabled: true</code> を含む <code>X-TFY-LOGGING-CONFIG</code> ヘッダーが完全なリクエストをキャプチャします。セルフホスト型デプロイメントのゲートウェイレベルでは、<code>REQUEST_LOGGING_MODE</code> 環境変数がグローバルな動作を設定します。<code>ALWAYS</code> はヘッダーに関係なくすべてのリクエストをログに記録し、これは規制された本番環境に適した設定です。<code>HEADER_CONTROLLED</code> はリクエストごとの設定に委ねます。<code>NEVER</code> は、適切な環境ではすべてのロギングを抑制します。

リクエストログは、TrueFoundry UIの「AI Gateway > Monitor > Requests」で確認できます。個々のガードレール実行スパンは、「AI Gateway > Monitor > Request Traces」に表示され、どのフックでどのガードレールが実行されたか、合否ステータス、実行時間、適用された変更が示されます。ログを自社インフラにルーティングする組織向けに、TrueFoundryはOpenTelemetryを介してGrafana、Datadog、Splunk、およびOTLP互換のあらゆる宛先にエクスポートします。セルフホスト型デプロイメントでは、ログデータはParquet形式で独自のAWS S3、GCS、またはAzure Blobストレージに書き込まれ、Spark、DuckDB、またはAthenaを介してクエリ可能です。

HIPAAは、セキュリティ関連文書の6年間の保持を義務付けています。実際には、監査ログはコンプライアンスとインシデント調査をサポートするために、同様の期間保持されることがよくあります。多くの財務記録は7年間の保持基準に従っています。ログは改ざん防止機能があり、ログを生成するチームによる変更を防ぐアクセス制御が必要です。TrueFoundryのセルフホスト型デプロイメントオプションは、すべてのログデータを顧客のクラウドアカウント内に保持し、保持と改ざん防止の両方の要件をサポートします。

柱4：ツール実行前のリアルタイムMCPポリシー適用

何が起こったかをログに記録することと、それを防ぐことは同じではありません。ポリシー適用は、ツール呼び出しがMCPサーバーに到達する前の呼び出し時に機能する必要があり、事後に記録するのではなく、不正アクセスをブロックします。

TrueFoundryのガードレールシステムは、ツール呼び出しごとに2つのフックを実装しています。MCPプレツールガードレールは、ツールが実行される前に動作します。いずれかが失敗した場合、ツールは実行されず、不正な呼び出しによるコスト、副作用、データ漏洩を完全に回避します。組み込みのプレツールガードレールには、SQLサニタイザー（WHERE句のないDROP、TRUNCATE、DELETE、UPDATE、およびインジェクションリスクを示す文字列補間パターンを検出）、プロンプトインジェクション検出（ツール呼び出しパラメータにおけるジェイルブレイクおよびインジェクション試行に対するモデルベース分析を使用）、シークレット検出（APIキー、AWS認証情報、JWTトークン、秘密鍵がバックエンドサービスに到達する前に捕捉）、および特定のツール引数に至るまで宣言的で詳細なアクセス制御を行うCedarおよびOPAポリシーガードレールが含まれます。

MCPポストツールガードレールは、ツールが結果を返した後、その結果がエージェントに到達する前に実行されます。組み込みのポストツールガードレールには、コード安全リンター（ツール出力におけるeval、exec、os.system、subprocess呼び出し、および危険なシェルコマンドをフラグ付け）、PII検出（設定可能なエンティティカテゴリで個人情報を検出および編集）、および支払いカード、内部識別子、ドメイン固有の機密データをカバーするカスタムパターン用の正規表現パターンマッチングが含まれます。AWS Bedrock Guardrail、Azure Content Safety、Azure Prompt Shield、CrowdStrike、Google Model Armorなどの外部プロバイダーはすべて、同じフックシステムを介して統合されます。

適用戦略はガードレールごとに設定可能です。「Enforce」は違反時およびガードレールエラー時にブロックします。「Enforce But Ignore On Error」は違反時にブロックしますが、ガードレールプロバイダーが利用できない場合はリクエストを通過させます。これは本番環境での推奨デフォルトです。「Audit」はブロックせずに違反をログに記録します。これは初期展開時の適切なモードです。推奨されるシーケンスは、まず「Audit」、次に「Enforce But Ignore On Error」、そして信頼が高まるにつれて完全な「Enforce」です。

エンタープライズMCPゲートウェイのデプロイ：4段階の実装計画

MCPガバナンスは段階的なプログラムです。各ステップは前のステップの上に構築されます。どのようなサーバーが存在するかを知る前に、アクセスポリシーを適用することはできません。ID帰属が確立される前に、意味のある監査証跡を構築することはできません。

ステップ1：既存のすべてのMCPデプロイメントの棚卸し

開発環境、CI/CDパイプライン、本番エージェントデプロイメント、IDE構成にわたる、稼働中のすべてのMCPサーバーの完全な監査から始めます。これには、開発者がIT部門の関与なしにCursorやClaude Codeでローカルに構成したサーバーも含まれます。クラウド環境の自動スキャンと、ローカル開発者構成の自己申告プロセスを組み合わせることで、大規模組織にとって最も完全な全体像が得られます。

各サーバーについて、名前と目的、所有チーム、データアクセス範囲、認証方法（もしあれば）、および稼働期間を記録します。目標は、ガバナンスが導入される前に何が存在していたかの正確な全体像を把握することであり、すでに承認されたものの厳選されたリストを作成することではありません。

ステップ2：承認済みMCPサーバーカタログの構築

サーバーを移行する前に、メタデータスキーマと承認ワークフローを定義します。主要な決定事項は、異なるリスクティアに対する承認権限を持つのは誰か、レビューチェックリストは何をカバーするか、そしてどのような発見がカタログ登録をブロックするかです。サーバーを分類する前にこれらの基準を確立し、一貫して適用されるようにします。

インベントリを確認し、各サーバーを「カタログ承認済み」「レビュー保留中」「修正待ちでブロック」に分類します。すべての本番サーバーがカタログ登録される厳守期限を設定し、その日以降はカタログ未登録のサーバーがゲートウェイでブロックされることを明確に伝えてください。この期限が、チームを動かすための切迫感を生み出します。

ステップ3：MCPゲートウェイをデプロイし、SSOを適用する

ブロックポリシーを適用する前に、すべてのMCPトラフィックをゲートウェイ経由でルーティングします。REQUEST_LOGGING_MODEをALWAYSに設定して開始してください。すべてのトラフィックは通過し、すべての呼び出しが記録されますが、まだ何もブロックされません。このモードで2〜4週間運用することで、適用開始前の実際のトラフィックパターンのベースラインが得られます。

TrueFoundry UIの「Access > External Auth > Identity Provider」から、ゲートウェイを企業のIdPと統合します。デフォルトの認証サーバーを使用しているOktaの場合、JWKS URIは次のとおりです。 https://your-org.okta.com/oauth2/v1/keys。カスタムのOkta認証サーバーを使用している組織は、 https://your-org.okta.com/oauth2/{authServerId}/v1/keys を使用してください。Azure ADの場合は、https://login.microsoftonline.com/your-tenant-id/discovery/v2.0/keys となり、テナントIDとクライアントIDが発行者およびオーディエンスとして構成されます。適用に移行する前に、監査ログ内のすべての呼び出しが特定のユーザーまたはエージェントのIDを示していることを確認してください。ログに共有サービスアカウントのIDがある場合、IDの帰属が不完全であることを意味します。

ステップ4：適用を有効にし、アラートを設定する

ベースライン期間が終了したら、ポリシー適用を有効にします。具体的には、カタログ未登録のMCPサーバーをブロックし、RBACポリシーをアクティブ化し、レート制限を適用します。開発チームには、正当なツールをカタログ登録で迅速に進めるための十分なリードタイムを確保して、適用日を伝えてください。

エクスポートされたOpenTelemetryデータに対して、異常なパターン（単一のエージェントIDからの異常な呼び出し量、承認時間外の機密性の高いツールへのアクセス、MCPアクセスを持つべきではないIDからのポリシー違反など）のアラートを設定します。AI Gateway > Monitor > Request Tracesのガードレール結果は、時間の経過とともにしきい値を調整するために必要な詳細を提供します。MCPデプロイメントの拡大に合わせて、アラートルールを四半期ごとに見直してください。

業界別MCPセキュリティエンタープライズ要件

すべての規制環境において、以下の3つの要件が一貫して見られます。検証済みIDにリンクされた帰属可能なアクセス記録、機密データを定義された境界内に保持するデータレジデンシー制御、そしてガバナンスインフラストラクチャ自体のベンダーリスク文書です。

• ヘルスケア（HIPAA）： パラメータまたは応答で保護された医療情報（PHI）を受信する可能性のあるMCPサーバーには、VPC分離型ゲートウェイが必要です。PHIを含むツール呼び出しには、患者識別子が参照トークンに置き換えられたログが必要であり、アクセスは臨床ID管理を通じてプロビジョニングされなければなりません。TrueFoundryのAWS GovCloud上でのセルフホスト型デプロイメントは、HIPAA準拠のワークロードをサポートします。Innovaccerは、TrueFoundryを使用してAWS GovCloudの境界内で毎月約1,700万件の臨床AI推論リクエストを完全に処理しており、OpenTelemetryがGrafanaダッシュボードにデータを供給し、機密データがクラウド境界を離れることはありません。

• 金融サービス（SOC2、FINRA）： MCPガバナンスインフラストラクチャは、金融データを処理したり、記録システムにアクセスしたりする場合、SOC2 Type II監査の対象となります。必要な制御には、転送中および保存時の暗号化、文書化された証拠を伴う四半期ごとのアクセスレビュー、MCP固有の障害モードをカバーするインシデント対応手順が含まれます。TrueFoundryはSOC2 Type II認証を取得しており、監査人がCC6制御証拠を作成するために必要な形式で構造化されたMCP監査ログをエクスポートします。

• 保険およびグローバル企業（GDPR、データレジデンシー）： GDPRの対象となる組織は、第30条に基づき、AI支援処理（MCPツール呼び出しを含む）をカバーする処理活動の記録（RoPA）を維持しなければなりません。この記録は、処理目的、データカテゴリ、転送、および保護措置を記述する構造化されたコンプライアンス文書です。MCPゲートウェイ監査ログは、この記録に供給される基盤となるイベントデータを提供しますが、RoPA自体は組織のデータ保護機能によって別途維持される必要があります。ゲートウェイログはまた、データ主体アクセス要求をサポートし、ツール呼び出しを通じて発生する国境を越えた転送を文書化するために十分なメタデータをキャプチャする必要があります。データレジデンシー要件により、MCPトラフィックが特定の地理的地域から離れることが禁止される場合があり、地域ごとのゲートウェイデプロイメントが必要となります。

TrueFoundryが提供する企業MCPガバナンス

TrueFoundryのMCPゲートウェイは、顧客自身のクラウドアカウント内にデプロイされた単一のコントロールプレーンから、4つのガバナンスの柱すべてを提供します。プラットフォームチームは、個々のMCPサーバーの実装を変更することなく、単一のインターフェースを通じて完全なガバナンススタックを管理できます。MCPトラフィックが企業の境界を離れることはありません。

NVIDIA、Zscaler、Siemens Healthineers、Automation Anywhereなどの企業は、TrueFoundryを利用して、アドホックなMCPデプロイメントから、管理され統制された環境へと移行しています。大規模にAIエージェントワークロードを実行している企業にとって、TrueFoundryのポリシーによって強制されるコスト管理、予算制限、およびキャッシングレイヤーは、月間の推論およびツール呼び出し費用を大幅に削減しました。実際の呼び出し量とモデルの組み合わせに基づいた具体的な数値については、TrueFoundryにお問い合わせください。

• 一元化されたMCPカタログと審査ワークフロー： TrueFoundryコントロールプレーンは、承認されたMCPサーバーの信頼できるレジストリを、メタデータ、承認ステータス、および接続パラメーターとともに維持します。新しいサーバーは、開発者IDE構成に配布される前に、ポイズニングリスクに対するツール説明のレビューを含む審査プロセスを経て登録されます。仮想MCPサーバー機能により、プラットフォームチームは複数の登録済みサーバーから厳選されたツールサブセットを構成し、新しいインフラストラクチャをデプロイすることなく、特定のチームが必要とするもののみを公開できます。

• すべてのツール呼び出しにおけるOAuth2とRBAC： すべてのMCP呼び出しは、呼び出し元の企業IDを使用してOAuth2経由で認証されます。ゲートウェイは、6つのすべてのアウトバウンド認証パターンを処理し、認可コードフロー、クライアントクレデンシャルフロー、およびAPIキーインジェクションの完全なトークンライフサイクルを管理します。ゲートウェイで適用されるRBACポリシーは、更新時にすべてのクライアントに即座に適用され、サーバーの再デプロイは不要です。

• 呼び出しごとの設定可能なメタデータポリシー： TrueFoundryは、PII検出と正規表現ガードレールを介したデータマスキング、チームごとのレート制限、エージェントセッションごとのコスト上限、およびCedarまたはOPAポリシーを介した制限付きツールカテゴリのブロックルールを適用します。これらはすべて管理インターフェースで設定され、MCPサーバーコードの変更は不要です。

• SIEMにストリーミングされる監査ログ： すべてのMCP呼び出しの構造化されたJSON監査ログは、OpenTelemetryを介してGrafana、Datadog、Splunk、またはOTLP互換の任意の宛先にエクスポートされます。セルフホスト型デプロイメントでは、ログはParquet形式で独自のAWS S3、GCS、またはAzure Blobストレージに書き込まれ、Spark、DuckDB、またはAthenaを介してクエリ可能です。REQUEST_LOGGING_MODE: ALWAYSは、規制された環境での完全なキャプチャを保証します。

• 4つのオプションを備えたVPC分離デプロイメント： インフラストラクチャのオーバーヘッドがないフルマネージドSaaS。顧客所有のデータストレージを備えたSaaSゲートウェイ。インフラストラクチャコストが月額約600ドルのTrueFoundryコントロールプレーンを備えたセルフホスト型ゲートウェイプレーン。月額約800ドルから1,000ドルのフルセルフホスト型コントロールプレーンとゲートウェイ。最後の2つのオプションは、MCP呼び出しトラフィックが企業の境界を離れてTrueFoundryインフラストラクチャに到達しないことを保証します。

‍