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

MCPがエージェントの信頼境界を変える理由
最初に何を分離するか
MCPサーバーを実行する場所
ファイルシステムマウントとエージェントごとのワークスペース
シークレットと環境変数
ネットワーク出力とトランスポートの選択
パッケージインストール、サブプロセス、長期実行状態
ロギング、クリーンアップ、人間によるレビュー
Novita Agent Sandboxの適合方法
実装チェックリスト
FAQ
おすすめ記事

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

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

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

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

信頼境界は3つのレイヤーで考えてください。

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

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

最初に何を分離するか

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

サンドボックス化の優先度が高い候補は次のとおりです。

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

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

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

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

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

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

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

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

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

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

明示的なワークスペース境界を使用してください。

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

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

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

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

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

シークレットと環境変数

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

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

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

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

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

ネットワーク出力とトランスポートの選択

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

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

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

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

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

ネットワーク出力については、デフォルトで拒否する方が、デフォルトで許可するよりも合理的です。ツールがパッケージインストールを必要とする場合、パッケージレジストリまたはプルスルーキャッシュを許可します。ウェブ調査が必要な場合は、要求されたドメインをログに記録し、内部メタデータエンドポイントをブロックするプロキシを介してルーティングします。内部APIが必要な場合は、プライベートネットワーク全体ではなく、狭いAPIを公開します。

パッケージインストール、サブプロセス、長期実行状態

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

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

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

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

ライフサイクル制御を使用してください。

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

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

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

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

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

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

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

サンドボックスは爆発半径を縮小する必要があります。機密性の高いビジネスアクションからレビューを削除する理由になってはいけません。

Novita Agent Sandboxの適合方法

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

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

生成されたコードやコマンドを実行する必要があるサーバー。
一時ファイルや生成されたアーティファクトを扱うサーバー。
マルチステップタスク全体でエージェントごとのワークスペース状態を維持するサーバー。
エージェントが後で確認できるバックグラウンド作業を実行するサーバー。
エージェントの実験をアプリケーションホストから分離するサーバー。

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

製品固有の設定については、古いチュートリアルの古いスニペットをコピーするのではなく、現在のNovitaのドキュメントを使用してください。概念的には、形状は次のとおりです。

for each agent task:
  create sandbox from approved template
  mount only the task workspace
  inject only tool-specific secrets
  start the MCP server inside the sandbox or connect to a sandbox-backed tool API
  route tool calls through approval and policy checks
  collect logs and approved artifacts
  stop, reset, or pause the sandbox according to the task lifecycle

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

実装チェックリスト

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

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

MCPはツールの統合を容易にします。サンドボックス化により、その統合がモデルの特権の黙示的な拡大にならないようにします。適切な設計は通常、いくつかのサーバーは同じエージェントワークスペース内、いくつかは個別のサンドボックス内、いくつかは厳格な認可を備えたAPIの背後にあるサンドボックス外、という混合です。ツールのデータ、シークレット、サブプロセス、ネットワークのニーズに合った配置を選択してください。

FAQ

すべてのMCPサーバーをサンドボックスで実行する必要がありますか？

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

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

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

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

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

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

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

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

本番デプロイ、顧客向けメッセージ、請求またはアクセス制御の変更、大規模データエクスポート、インフラストラクチャへの書き込み、通常のワークスペースポリシー外のコマンドまたはネットワークアクションについては承認を必要とします。