MCPサーバーは、スコープされたファイルシステムマウント、最小権限のシークレット、明示的なネットワークポリシー、エージェント単位のワークスペース境界、ログを備えて実行されるべきです。そうすることで、ツールアクセスがエージェントの信頼境界を黙って拡大することがなくなります。サンドボックスは、MCPサーバーがファイルの読み取り、サブプロセスの生成、パッケージのインストール、内部APIの呼び出し、または長時間実行されるエージェントセッションの状態保持を行う場合に有効です。難しいのは、MCPに分離が必要だと判断することではなく、どの境界を各ツールの周りに置くか、どのデータがその境界を越えるか、そしてどのアクションに依然として人間のレビューが必要かを決定することです。
MCPがエージェントの信頼境界を変える理由
モデルコンテキストプロトコル（MCP）は、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は狭くする必要があります。サンドボックスの外にあるという理由だけで、広範な内部管理サーフェスを公開しないでください |
同じサンドボックス内でサーバーを実行することは、コーディングエージェントにとって便利です。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、構造化ツール応答、トレースログからシークレットを編集します。
- 生の環境変数をモデルに返さないでください。
- エージェントにどのシークレットをロードするかを決定させないでください。
- 高リスクサーバーで使用される認証情報、およびプロンプトインジェクションの露出が疑われる場合はローテーションします。
よくあるアンチパターンを避けてください。すべてのエージェントセッションにマウントされる1つの汎用環境ファイルです。これによりローカル開発は簡単になりますが、本番でのレビューは難しくなります。ツールがシークレットを必要としない場合、そのシークレットを読み取ることができてはいけません。
ネットワークエグレスとトランスポートの選択
MCPはローカルおよびリモートのトランスポートパターンをサポートしています。仕様では、ローカルプロセス通信用のstdioと、HTTP経由のサーバー対クライアント通信用のStreamable HTTPを説明しています。古いSSEベースの設計もエコシステムに残っていますが、新しい統合では、特定のトランスポートに依存する前に現在のMCPドキュメントと選択したSDKを確認する必要があります。
トランスポートの選択とサンドボックスネットワークポリシーは異なる問題を解決します。
| 質問 | トランスポートの答え | ネットワークポリシーの答え |
|---|---|---|
| MCPクライアントはサーバーとどのように通信するか？ | stdio、HTTPベースのトランスポート、または別のサポートされているパターン | 該当なし |
| サーバーはどの外部ホストを呼び出せるか？ | それだけでは不十分 | 許可リスト、拒否リスト、プロキシ、DNSポリシー、またはエグレスなし |
| サーバーはパッケージやWebページを取得できるか？ | それだけでは不十分 | レジストリ許可リスト、URL許可リスト、キャッシング、ログ |
| 別のプロセスがサーバーに到達できるか？ | バインディングと認証の詳細 | インバウンドファイアウォールとサンドボックスネットワーク境界 |
ローカルのstdioサーバーの場合、リスクは継承されたホストアクセスであることがよくあります。サーバーはホストアプリケーションの子プロセスとして実行され、ローカルファイル、環境変数、ネットワークルートを参照する可能性があります。そのサーバーがコードを実行したり機密ファイルを読み取ったりする場合は、サンドボックス化されたプロセスに移動するか、ホストとワーカーのペア全体を使い捨てワークスペース内で実行します。
HTTPベースのMCPサーバーの場合、リスクは認証、ネットワーク露出、クロステナント分離に移ります。サーバーサイドの認可、TLS、必要に応じたオリジンチェック、クライアントごとの認証情報を使用します。誰がどのツールを呼び出せるかについて明確なポリシーなしに、リモートMCPサーバーを広範な内部ネットワーク上に公開しないでください。
ネットワークエグレスについては、デフォルト拒否の方がデフォルト許可よりも推論が容易です。ツールがパッケージインストールを必要とする場合は、パッケージレジストリまたはプルスルーキャッシュを許可します。Web調査が必要な場合は、要求されたドメインをログに記録し、内部メタデータエンドポイントをブロックするプロキシを経由させます。内部APIが必要な場合は、プライベートネットワーク全体ではなく、狭いAPIを公開します。
パッケージインストール、サブプロセス、長時間実行状態
多くの便利なMCPツールはサブプロセスを必要とします。コーディングエージェントはテストを実行します。データエージェントはライブラリをインストールします。ブラウザエージェントはブラウザを起動します。ビルドエージェントはコンパイラを呼び出します。サブプロセスサポート自体は問題ではありません。目に見えないサブプロセスサポートが問題です。
パッケージインストールやシェル実行を許可する前に、以下を定義します。
- どのコマンドが許可、拒否、または承認ゲートされるか。
- パッケージマネージャーがパブリックインターネットに到達できるかどうか。
- 依存関係のバージョンを固定する必要があるか、ロックファイルベースにする必要があるか。
- ビルドキャッシュとインストールされたパッケージの保存場所。
- バックグラウンドプロセスを実行できる期間。
- クリーンアップ後に保持される出力ファイル。
- エージェントがネットワークリスナーを起動できるかどうか。
長時間実行されるMCPサーバーは、2つ目の問題である状態ドリフトを導入します。何時間も存続するサーバーは、ファイル、認証情報、ブラウザCookie、シェル履歴、依存関係の変更、バックグラウンドジョブを蓄積する可能性があります。この状態はマルチステップワークフローに役立つ可能性がありますが、適切なエージェント、ユーザー、タスクに属している必要があります。
ライフサイクル制御を使用します。
| 制御 | なぜ重要か |
|---|---|
| エージェント単位のサンドボックス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の背後でサンドボックスの外側に配置します。ツールのデータ、シークレット、サブプロセス、ネットワークニーズに一致する配置を選択してください。
FAQ
すべてのMCPサーバーをサンドボックスで実行する必要がありますか？
いいえ。コードを実行したり、ファイルを読み書きしたり、シークレットを使用したり、プライベートサービスを呼び出したり、ブラウザを起動したり、パッケージをインストールしたり、外部状態を変更したりするサーバーを優先してください。リスクの低い読み取り専用サーバーでも認証、ログ、ネットワーク制御が必要な場合がありますが、リクエストごとに専用のサンドボックスは必要ないかもしれません。
MCPサーバーではstdioはHTTPよりも安全ですか？
自動的にはそうではありません。Stdioはローカルサーバーにはシンプルですが、サーバーはローカルファイルシステム、環境、ネットワークアクセスを継承する可能性があります。HTTPベースのサーバーはより強力な認証と露出制御を必要とします。安全な選択は、プロセスがどこで実行され、どのランタイム権限を受け取るかによって異なります。
MCPルートはファイルシステムサンドボックス化を置き換えることができますか？
いいえ。ルートはクライアントとサーバー間で意図されたワークスペースの場所を伝えるのに役立ちますが、完全なランタイム境界ではありません。パス検証とサンドボックスレベルのファイルシステム制御を使用して、サーバーを意図されたワークスペース内に維持します。
サンドボックス化されたMCPツールのシークレットはどこに保存すべきですか？
ツールが必要とする認証情報のみを注入し、できれば短命の環境変数またはスコープされたランタイムシークレットとして注入します。広範な開発者認証情報フォルダをマウントしたり、プロンプトを介してシークレットを渡したりしないでください。ログとツール応答からそれらを編集します。
MCPツールが人間の承認を必要とするのはいつですか？
本番デプロイ、顧客向けメッセージ、請求またはアクセス制御の変更、大規模データエクスポート、インフラストラクチャ書き込み、および通常のワークスペースポリシー外のコマンドまたはネットワークアクションの場合に承認を要求します。
