MCPサーバーサンドボックス: ファイルシステム、シークレット、ネットワーク制御による隔離されたMCPサーバー

MCPサーバーは、スコープされたファイルシステムマウント、最小権限のシークレット、明示的なネットワークポリシー、エージェントごとのワークスペース境界、そしてツールアクセスがサイレントにエージェントの信頼境界を拡大しないようにするためのログを備えて実行されるべきです。サンドボックスは、MCPサーバーがファイルの読み取り、サブプロセスの生成、パッケージのインストール、内部APIの呼び出し、または長時間実行されるエージェントセッションの状態を保持する可能性がある場合に有用です。難しいのは、MCPに分離が必要だと判断することではありません。各ツールの周りにどの境界を設定するか、どのデータがその境界を越えるか、そしてどのアクションに依然として人間のレビューが必要かを判断することです。

MCPがエージェントの信頼境界を変える理由

Model Context Protocolは、AIアプリケーションがモデルをツール、プロンプト、リソースに接続するための共通の方法を提供します。これにより統合はよりクリーンになりますが、同時に各MCPサーバーがポリシー境界になります。サーバーがread_file、run_command、query_database、deploy_previewなどを公開する場合、エージェントはモデルコンテキストウィンドウを超えてアクションを要求できるようになります。

これらのツールをより広範なワークフローに接続する場合は、まずAIでタスクを自動化する方法から始め、その後、外側のループにコーディングエージェントが必要か、それともより軽量なインタープリタで十分かを判断してください。

MCP仕様は、サンドボックス設計に重要なセキュリティ期待事項をいくつか説明しています。ユーザーは公開されたツールを理解し同意する必要があること、ホストはツール呼び出しの前に同意を要求すべきこと、ツールの説明は検証されない限り信頼できないこと、機密データは適切なアクセス制御で保護されるべきことなどです。これらのルールはアプリケーションレベルの制御です。サンドボックスはそれらの下にランタイム制御を追加し、エージェント、ツールの説明、プロンプトチェーンが不正なリクエストを行った場合でも、MCPサーバープロセスが触れることができるものを制限します。

信頼境界を3つの層で考えてみましょう。

層	制御するもの	一般的な障害モード
ホストまたはMCPクライアント	どのサーバーが接続され、どのツール呼び出しが承認されるか	広範なツールが一度承認され、より機密性の高いコンテキストで再利用される
MCPサーバー	ツールの実装、認証、入力検証、リソースアクセス	ツールが予想以上に多くのファイルを読み取ったり、データを送信したり、コマンドを実行したりする
サンドボックスランタイム	ファイルシステム、プロセス、ネットワーク、シークレット、ライフサイクル、ログ	サーバープロセスが本番リソースに近すぎる場所で実行されているため、ホストアクセスを継承する

目標は、すべてのMCPサーバーを同じように信頼できないものにすることではありません。カレンダー検索ツール、ローカルコード実行ツール、デプロイツールではリスクプロファイルが異なります。目標は、各サーバーのランタイムアクセスを、それが実行するジョブよりも広くしないことです。

最初に何を隔離するか

外部の状態を変更したり、機密データに触れたり、コードを実行したりする可能性のあるMCPサーバーから始めてください。これらのサーバーは、通常のプロンプトのミスをより大きなインシデントに変える可能性が最も高いものです。

サンドボックス化の優先度が高い候補は以下の通りです。

• シェルコマンド、Python、Node.js、コンパイラ、テスト、ノートブックを実行するコード実行ツール。
• リポジトリ、ユーザーアップロード、マウントされたデータセット、資格情報ファイル、生成されたアーティファクトを読み書きするファイルシステムツール。
• クッキー、セッション状態、ダウンロードファイル、スクリーンショットを保持するブラウザおよびコンピュータ使用ツール。
• 顧客レコード、分析エクスポート、チケット、プライベートドキュメントをクエリできるデータコネクタ。
• ブランチを作成したり、プレビューを公開したり、設定をローテーションしたり、インフラを変更したりできるデプロイおよびCIツール。
• レジストリ、Gitリモート、任意のURLからコードをフェッチできるパッケージおよび依存関係ツール。

リスクの低いMCPサーバーにも制御が必要な場合があります。読み取り専用の公開ドキュメント検索サーバーはリクエストごとにマイクロVMを必要としないかもしれませんが、許可リスト化されたネットワークパス、ログ、レート制限は必要です。分離は、「MCPサーバー」というラベルではなく、ツールの実際の爆発半径に従うべきです。

MCPサーバーを実行する場所

3つの一般的な配置パターンがあります。どれが普遍的にも正しいわけではありません。

配置	使用時期	注意点
エージェントワークスペースと同じサンドボックス	サーバーがエージェントの現在のファイル、シェルコマンド、ブラウザセッション、または生成されたアーティファクトと密に結合している場合	サーバとエージェントが状態を共有するため、マウントとシークレットがスコープされていないと、侵害されたツがルが同じワークスペースを見ることができる
MCPサーバーまたはツールグループごとに個別のサンドボックス	ツールがエージェントワクスぺースからのより強力な分離を必とし、異なっる認証情報を扱う、またはよりリスクの高い実を実行する場合	サンドボクス間のフファイル転送と待ち時間が生成品デザインの一部になる
スコープされたAPIの背後でサンドボックス外	ツールが独自の認証、認可、ロギング、およびレート制限を備えた安定した本番サービスである場合	APIは狭くなければならい。サンドボックス外にあるというだけで広範な内部管理面を公開しないこと

コーディングエージェントにとっては、同じサンドボックスでサーバーを実行するのが便利です。MCPサーバーはリポジトリを参照し、テストを実行し、アーティファクトを検査し、環境間でファイルを移動することなく結果を返すことができます。これは、ワークスペース自体がすでに使い捨て可能であり、エージェントが使用すべきファイルのみを含んでいる場合に最も効果的です。

ツールに異なるポリシーが必要な場合は、個別のサンドボックスの方が適しています。たとえば、パッケージ分析MCPサーバーはパブリックレジストリへのインターネットアクセスを必要とするかもしれませんが、メインのコーディングエージェントはそうすべきではありません。ブラウザMCPサバはテスとアウントのクッキーを必とすかもしれませんが、コード実サーバーはれらのクキーを見るべきではなりません。

外部サービスは、実際には「ランタイムツール」ではないツールに適しています。請求照会、フィーチャーフラグ読み取り、課題トラッカー検索などは、エージェントのコンピューティング環境内の自由形式のサーバーとしてよりも、サーバー側の認証を備えた通常のバックエンドAPIとして安全である可能性があります。

ファイルシステムマウントとエージェントごとのワークスペース

ファイルシステムアクセスは、MCPの利便性がしばしば偶発的な特権に変わる場所です。./srcを読み取る必要があるサーバーが、デベロッパーのホームディレクトリを継承してはいけません。生成されたチャートを書き込むツールが、デプロイ設定を上書きできてはいけません。

明示的なワークスペース境界を使用します。

• 各エージェント実行に独自のワークスペースディレクトリを割り当てます。
• タスクに必要なリポジトリ、アップロードフォルダ、データセット、またはアーティファクトディレクトリのみをマウントします。
• ソースマテリアルには読み取り専用マウントを、出力には読み取り/書き込みマウントを優先します。
• 生成された出力を信頼されたソースファイルから分離します。
• .ssh、クラウド設定ディレクトリ、ブラウザプロファイル、ローカルパッケージマネージャ認証ファイルなどの認証情報フォルダをマウントしないでください。
• 無関係なユザー、テナント、まはタスクの間でワクスぺスをリセットまたはスナップショットします。

MCPルーツは、クライアントがサーバーが操作すべきファイルシステムの場所を伝えるのに役立ちますが、ルーツ自体は完全なセキュリティ境界ではありません。クライアントとサーバー間の調整メカニズムとして扱ってください。ランタイムには依然としてファイルシステムレベルの制限が必要であり、サーバーはシンボリックリンク、相対パス、またはアーカイブ抽出のトリックによってリクエストが意図されたワークスペースから逃げ出せないようにパスを検証する必要があります。

実用的なパターンは、役割ごとにワークスペースアクセスを分割することです。

ディレクトリ	アクセス	目的
/workspace/input	読み取り専用	ユーザーアップロード、シードリポジトリ、ベンチマークフィクスチャ、テストデータ
/workspace/output	読み取り/書き込み	生成されたファイル、レポート、パッチ、チャート、スクリーンショット
/workspace/tmp	読み取り/書き込み、使い捨て可能	ビルドキャッシュ、パッケージインストールキャッシュ、スクラッチファイル
/workspace/secrets	可能な限りファイルマウントを避ける	やむを得ない場合は、厳格な有効期間と編集を備えたスコープされた1つのシークレットファイルをマウントする

正確なパスは重要ではありません。原則が重要です。

シークレットと環境変数

シークレットは通常、ファイルよりもリークしやすいです。なぜなら、環境変数、ログ、スタックトレース、パッケージスクリプト、シェル履歴、ブラウザセッション、ツール応答を通じて移動するからです。MCPサーバーが資格情報を必要とする場合、ツールアクションを完了できる最も狭い資格情報を付与します。

異なるMCPサーバーには個別の資格情報を使用します。GitHubの課題検索サーバーは読み取り専用の課題アクセスを必要とするかもしれません。PR作成サーバーはブランチ書き込みアクセスを必要とするかもしれません。デプロイサーバーは、権限モデルが本当にそれを必要としない限り、どちらかのトークンを共有すべきではありません。

MCPサーバー向けの適切なシークレット処理は次のようになります。

• シークレットはプロンプトではなく、サンドボックスまたはプロセス起動時に注入する。
• プロバイダーがサポートしている場合は、短命または失効可能なトークンを使用する。
• 資格情報をツール、テナント、環境、アクションごとにスコープする。
• stdout、stderr、構造化ツール応答、トレースログからシークレットを編集する。
• 生の環境変数をモデルに返さない。
• エージェントがどのシークレットをロードするかを決定させない。
• リスクの高いサーバーで使用される資格情報、およびプロンプトインジェクションへの露出が疑われる後にローテーションする。

一般的なアンチパターンは避けてください：すべての目的のための1つの環境ファイルをすべてのエージェントセッションにマウントすること。これによりローカル開発は容易になりますが、本番レビューは難しくなります。ツールがシークレットを必要としないのであれば、それを読み取ることができてはいけません。

ネットワークエグレスとトランスポートの選択

MCPはローカルおよびリモートのトランスポートパターンをサポートしています。仕様では、ローカルプロセス通信のためのstdioと、HTTPを介したサーバー対クライアント通信のためのStreamable HTTPについて説明しています。古いSSEベースの設計もエコシステムにまだ存在しますが、新しい統合では、特定のトランスポートに依存する前に、現在のMCPドキュメントと選択したSDKを確認する必要があります。

トランスポートの選択とサンドボックスネットワークポリシは、別の問題を解決します。

質問	トランスポートが答えること	ネットワークポリシーが答えること
MCPクライアントはサーバーとどのように通信するか？	stdio、HTTPベースのトランスポート、またはその他のサポートされているパターン	適用外
サーバーはどの外部ホストを呼び出せるか？	それだけでは不十分	許可リスト、拒否リスト、プロキシ、DNSポリシー、またはエグレスなし
サーバーはパッケージやウェブページをフェッチできるか？	それだけでは不十分	レジストリ許可リスト、URL許可リスト、キャッシュ、ロギング
別のプロセスがサーバーに到達できるか？	バインディングと認証の詳細	インバウンドファイアウォールとサンドボックスネットワーク境界

ローカルstdioサーバーの場合、リスクは多くの場合、継承されたホストアクセスです。サーバーはホストアプリケーションの子プロセスとして実行され、ローカルファイル、環境変数、ネットワークルートを参照する可能性があります。そのサーバーがコードを実行したり機密ファイルを読み取ったりする場合は、サンドボックス化されたプロセスに移動するか、ホストとワーカーのペア全体を使い捨て可能なワークスペース内で実行します。

HTTPベースのMCPサーバーの場合、リスクは認証、ネットワーク露出、クロス テナント分離に移ります。サーバー側の認証、TLS、必要に応じてオリジンチェック、およびクライアントごとの資格情報を使用します。誰がどのツールを呼び出せるかについて明確なポリシーなしに、リモートMCPサーバーを広範な内部ネットワークに公開しないでください。

ネットワークエグレスの場合、デフォルト拒否の方がデフォルト許可よりも推論しやすいです。ツールがパッケージインストールを必要とする場合は、パッケージレジストリまたはプルスルーキャッシュを許可します。ウェブリサーチが必要な場合は、リクエストされたドメインをログに記録し内部メタデータエンドポイントをブロックするプロキシを経由します。内部APIが必要な場合は、プライベートネットワーク全体ではなく、狭いAPIを公開します。

パッケージインストール、サブプロセス、および長時間実行状態

多くの便利なMCPツールはサブプロセスを必要とします。コーディングエージェントはテストを実行します。データエージェントはライブラリをインストールします。ブラウザエージェントはブラウザを起動します。ビルドエージェントはコンパイラを呼び出します。サブプロセスサポート自体は問題ではありません。目に見えないサブプロセスサポートが問題です。

パッケージインストールやシェル実行を許可する前に、以下を定義します。

• どのコマンドが許可され、拒否され、または承認ゲートされるか。
• パッケージマネージャーがパブリックインターネットに到達できるかどうか。
• 依存関係のバージョンを固定するか、ロックファイルベースにする必要があるかどうか。
• ビルドキャッシュとインストールされたパッケージがどこに存在するか。
• バックグラウンドプロセスをどのくらいの時間実行できるか。
• クリーンアップ後に保持される出力ファイルはどれか。
• エージェントがネットワークリスナーを起動できるかどうか。

長時間実行されるMCPサーバーは、2番目の問題である状態のドリフトをもたらします。何時間も存続するサーバーは、ファイル、資格情報、ブラウザクッキー、シェル履歴、依存関係の変更、バックグラウンドジョブを蓄積する可能性があります。この状態はマルチステップワークフローに有用ですが、正しいエージェント、ユーザー、およびタスクに属している必要があります。

ライフサイクル制御を使用します。

制御	なぜ重要か
エージェントごとのサンドボックスID	あるエージェントのツール状態が別のエージェントのコンテキストになるのを防ぐ
アイドルタイムアウト	放棄されたツールセッションをクリーンアップする
一時停止および再開ポリシー	不必要なコンピューティングをアクティブに保たずに長時間ジョブをサポートする
スナップショットまたはテンプレートポリシー	既知のベースラインから再現可能な環境を開始する
明示的なティアダウン	ジョブ後にファイルを削除し、プロセスを強制終了し、資格情報を解放する

ツールが耐久性のあるアーティファクトを生成する場合は、それらのアーティファクトのみをサンドボックスからコピーします。製品が完全なセッションリプレイを明示的に必要としない限り、ワークスペース全体を保持しないでください。

ロギング、クリーンアップ、および人間によるレビュー

MCPツールのログは、新しいシークレットストアにならずに、セキュリティとデバッグの質問に答えるべきです。有用なログには、ツール名、呼び出し元ID、サンドボックスID、ワークスペースID、コマンドカテゴリ、読み取りまたは書き込みされたファイル、連絡先となった外部ドメイン、インストールされたパッケージ名、終了ステータス、アーティファクトパスが含まれます。

デフォルトでは、生のプロンプト、生の顧客データ、トークン、ファイルの完全な内容、コマンドの完全な出力をログに記録しないでください。機密性の高いトレースは、より厳格なアクセス制御と保持ポリシーの背後に保管してください。

サンドボックス内であっても、一部のMCPアクションは人間によるレビューを必要とします。

• 本番環境への公開またはデプロイ。
• 電子メール、チャット、チケット、請求書、顧客向けメッセージの送信。
• アクセス制御、請求、ユーザーデータ、インフラ構成の変更。
• 大規模ファイル、プライベートリポジトリ、データベースエクスポート、資格情報のような文字列の持ち出し。
• ワークスペースポリシー外でのコマンドの実行。
• 書き込み権限ありの内部APIの呼び出し。

サンドボックスは爆発半径を減らすべきです。機感なビジネスアクションからレビューを除する理由になってはなりません。

Novita Agent Sandboxの適合方法

Novita Agent Sandboxは、コード実行、ファイル、プロセス、ブラウザスタイルのワークフロー、および長時間実行セッションのために隔離されたランタイムを必要とするエージェントワークロード向けに設計されています。ツールサーバーがデベロッパーのラップトップ、本番ホスト、または共有CIマシンへの直接アクセスの代わりに使い捨て可能なワークスペースを必要とするMCPアーキテクチャに適合できます。

以下を必要とするサーバーのランタイム境界として使用します。

• 生成されたコードまたはコマンドを実行する。
• 一時ファイルと生成されたアーティファクトを扱。
• マルチステップタスク間でエジエンとごとのワクスぺース状を保する。
• ェジエントが後で確認できるバックグラウンドワクを実行する。
• ェジエントの実験をアプリケーションホストから分離する。

製品の境界を明確に保ちます。MCPサーバーは依然としてあなたのアプリケーションコードです。ツールの権限、資格情報のスコープ、ネトワークポリシ、承認フロ、ロギングスキーマ、クリーンアップ動作をま設計します。サンドボックスは、れらの決定が執行される隔離された環境を提供します。

製品固有のセットアップには、古いチュートリアルの使い回しではなく、現在のNovitaドキメントを使用します。概論的には、形は次のようになります。

各エージェントタクについ:
  承認されたテプレからサンドボックスを作成
  タクのワクスぺスのみをマウント
  ール特のシークレットのみを注入
  MCPサバーをサンドボッ内で起するか、サンドボッでッされたールAPIに接続する
  ール呼び出を承認とポリシ確認に通す
  ログと承認されたアティファクを収集する
  タクのラフサクルにじ、サンドボックスを停止、リセット、または一時停止する

これにより、記事レベルのガイダンスを安定に保ちながら、正確なSDK呼び出しは最新のドキメントとプットフォームコードに委ねられます。

実装チェックリスト

MCPサーバーを自律的または半自律的なエージェントに接続する前に、このチェックリストを使用してください。

領域	答えるべき質問
ツールの範囲	サーバーはどのようなツールを公開し、それらのうちどれが外部状態を変更するか？
配置	サバーはエジエントサンドボクス内で実行されるべきか、別のサンドボクス内か、または狭いAPIの背後でサンドボックス外か？
ファイルシステム	どのディレクトリがマウントされているか、それらは読み取り専用か読み取り/書き込みか、パスエスケープはどのようにブロックされているか？
シクレット	どの資格情報が注入されるか、それらはどのようにスープされるか、ログや出力のどこに現れる可能性があるか？
ネットワーク	エグレスはデフォルト拒否か、プロキシ経由か、ドメイン、レジストリ、内部APIごとに許可リスト化されているか？
サプロセス	どのコマンド、パッケージマネージャ、バクグラウンドジョブ、リスナーが許可されているか？
状態	エージェントごとのワークスペース、スナップショット、アイドルタイムアウト、一時停止/再開動作、クリーンアップはどのように処理されるか？
ログ	シークレットを保存せずに、ツール呼び出し、ファイル変更、外部ドメイン、アーティファクトを再構築できますか？
人間によるレビュー	実行、エクスポート、デプロイ、または顧客向けアクションの前に、どのツール呼び出しに承認が必要か？
テスト	プロンプトインジェクション、シンボリックリンク/パストラバーサル、大きな出力、失敗したクリーンアップ、拒否されたエグレスパスをテストしましたか？

MCPはツール統合を容易にします。サンドボックスは、その統合がモデルの権限のサイレントな拡大にならないようにします。適切な設計は通常、組み合わせです。一部のサーバーは同じエージェントワークスペース内に、一部は個別のサンドボックス内に、一部は厳格な認証を備えたAPIの背後でサンドボックス外に配置します。ツールのデータ、シークレット、サブプロセス、およびネットワーク要件に一致する配置を選択してください。

よくある質問

すべてのMCPサーバーをサンドボックスで実行すべきですか？

いいえ。コードを実行する、ファイルを読み書きする、シークレットを使用する、プライベートサービスを呼び出す、ブラウザを起動する、パッケージをインストールする、または外部状態を変更するサーバーを優先してください。リスクの低い読み取り専用サーバーでも、認証、ロギング、ネットワーク制御が必要な場合がありますが、リクエストごとに専用のサンドボックスを必要としない場合があります。

MCPサーバーにとってstdioはHTTPより安全ですか？

自動的にはそうではありません。Stdioはローカルサーバーにとってはシンプルですが、サーバーはローカルファイルシステム、環境、ネットワークアクセスを継承する可能性があります。HTTPベースのサーバーはより強力な認証と露出制御を必要とします。どちらが安全かは、プロセスがどこで実行され、どのようなランタイム権限を受け取るかによって異なります。

MCPルーツはファイルシステムサンドボックスを代替できますか？

いいえ。ルーツはクライアントとサーバー間で意図されたワークスペースの場所を伝えるのに役立ちますが、完全なランタイム境界ではありません。パス検証とサンドボックスレベルのファイルシステム制御を使用して、サーバーを意図されたワークスペース内に保ってください。

サンドボックス化されたMCPツールのシークレットはどこに保存すべきですか？

ツールが必要とする資格情報のみを注入し、理想的には短命の環境変数またはスコープされたランタイムシークレットとして注入します。広範なデベロッパー資格情報フォルダをマウントしたり、プロンプトを介してシークレットを渡したりしないでください。ログやツール応答からそれらを編集してください。

MCPツールはいつ人間の承認を必要とすべきですか？

本番デプロイ、顧客向けメセージ、請やアクセス制の変、規模なデタ出、イフラへの込、おび通のワクスペースポリシ範でのコマンドやネトワークアクションについて承認を必要とします。

おすすめ記事

• 本番アプリケーション向けAI生成コードサンドボックス要件
• Claude MCP: Claude CodeおよびClaude DesktopでMCPサーバーを設定する方法
• NovitaのAgent Sandboxを使用したコーディングエージェントの構築