Securing Model Context Protocol: Safer Agentic AI with Containers

モデル・コンテキスト・プロトコル(MCP)ツールは 、主にアーリーアダプターの手に委ねられていますが、より広範な採用が加速しています。この増加に伴い、MCPのセキュリティに関する懸念はますます緊急性を増しています。エージェントの自律性を高めることで、MCPツールは、エージェントの行動とユーザーの期待との間の不整合や制御不能な実行に関連する新たなリスクをもたらします。また、これらのシステムは新たな攻撃対象領域となり、新たなソフトウェアサプライチェーンの脅威を生み出しています。その結果、MCPの採用は、これらのシステムが本番環境に統合される前に、信頼性、分離性、ランタイム制御に関する重要な問題を提起します。

MCPツールがセキュリティに欠ける場所

私たちのほとんどは、以下に示すようなファイルを構成して、最初にMCPツールを試しました。このワークフローは、迅速で柔軟性があり、生産性が高く、初期の実験に最適です。しかし、それにはトレードオフも伴います。MCPサーバーは、インターネットから直接取得され、ホストマシン上で実行され、プレーンテキストの環境変数として渡される機密性の高い資格情報で構成されます。それはまるでリビングルームで花火を打ち上げるようなもので、スリル満点ですが、あまり安全ではありません。

{
  "mcpServers": {
    "command": "npx",
    "args": [
      "-y",
      "@org/mcp-server",
      "--user", "me"
    ],
    "env": {
      "SECRET_API_KEY": "YOUR_API_KEY_HERE"
    }
  }
}

MCPツールが本番環境での使用に近づくにつれて、私たちは一連の基本的な問題に直面することを余儀なくされます。

MCPサーバーを信頼できますか?

ホストに適切なソフトウェアがインストールされていることを保証できますか?そのベースラインがなければ、再現性と信頼性は崩壊します。MCP サーバー自体の出所と整合性をどのように確認しますか?それがどこから来たのかを追跡したり、何が含まれているのかを確認できなければ、安全に実行されるとは信頼できません。たとえ実行されていたとしても、それが私たちに到達する前、または実行中に改ざんされていないことをどうやって知ることができるのでしょうか?

シークレットとアクセスを安全に管理していますか?

また、秘密管理も喫緊の課題となっています。環境変数は便利ですが、安全ではありません。機密データを読み取りが許可されているランタイムにのみ安全に挿入し、それ以外の場所には挿入しない方法が必要です。アクセス制御についても同じことが言えます。チームがMCPツールの使用を拡大するにつれて、どのエージェントがどのサーバーと通信できるかを定義し、それらのルールが実行時に適用されるようにすることが不可欠になります。

図 1:シークレットを.envに保存しないことに関するディスカッション レディット(Reddit).信用： アミルシュク

脅威を早期に検出するにはどうすればよいでしょうか? 

そして、検出の問題があります。私たちは、MCPツールの周りに出現している脅威の種類を認識する準備ができていますか?プロンプトインジェクションから悪意のあるサーバー応答まで、新たな攻撃ベクトルがすでに出現しています。専用のツールと明確なセキュリティ基準がなければ、これらの脅威に盲目的に足を踏み入れるリスクがあります。最近の脅威パターンには、次のようなものがあります。

• MCP ラグプル – 悪意のある MCP サーバーは、ユーザーがツールを承認した後でツールの説明を変更することで「ラグプル」を実行できます。
• MCPシャドウイング – 悪意のあるサーバーが、信頼できるサービスまたはツールに対してエージェントの動作を変更するツールの説明を挿入します。 
• ツールポイズニング – MCPツールの説明にある悪意のある命令で、ユーザーには隠されていますが、AIモデルによって読み取ることができます。

明らかなのは、初期段階の実験で機能したプラクティスが安全に拡張できないということです。採用が拡大するにつれて、MCPサーバーをパッケージ化、検証、および実行するための安全で標準化されたメカニズムの必要性が重要になります。それらがなければ、MCPツールを強力にする自律性そのものが、MCPツールを危険なものにもする可能性があります。

なぜ MCP サーバー用のコンテナなのか

開発者はすぐに、クラウドネイティブ・アプリケーションの提供に使用されているのと同じコンテナ・テクノロジーが、エージェント・システムを安全に強化するためにも自然に適していることに気付きました。コンテナは単なるパッケージ化ではなく、ガードレールを追加してMCPサーバーの採用に向けたより安全な道筋を構築できる、制御されたランタイム環境を提供します。

MCP サーバーの移植性と安全性を確保 

私たちのほとんどは、コンテナを使用してソフトウェアを移動させ、ランタイムの一貫性と簡単な配布を提供する方法に精通しています。また、コンテナはワークロード間の強力な分離レイヤーを提供し、1 つのアプリケーションが別のアプリケーションやホストシステムに干渉するのを防ぐのに役立ちます。この分離により、侵害の影響範囲が制限され、最小特権アクセスの強制が容易になります。さらに、コンテナは、出所と完全性の両方の検証を提供できます。これは、ソフトウェアサプライチェーンのセキュリティから得られる重要な教訓の1つであり続けています。これらのプロパティを組み合わせることで、信頼できない MCP サーバーをホスト上で直接実行するリスクを軽減できます。

最初のステップとして、クラウドネイティブ配信についてすでに知っていることを使用して、MCPサーバーをコンテナに分散するだけです。 

{
  "mcpServers": {
    "mcpserver": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "org/mcpserver:latest",
        "--user", "me"
      ],
      "env": {
        "SECRET_API_KEY": "YOUR_API_KEY_HERE"
      }
    }
  }
}

しかし、サーバーのコンテナ化は話の半分にすぎません。開発者は、MCP サーバー ランタイムとシークレットの引数を指定する必要があります。これらの引数が誤って構成されていたり、さらに悪いことに意図的に変更されていたりすると、機密データが公開されたり、サーバーの実行が安全でなくなったりする可能性があります。 

次のセクションでは、これらのリスクを軽減するための主要な設計上の考慮事項、ガードレール、およびベスト プラクティスについて説明します。

MCPサーバーとクライアント用の安全なコンテナ化アーキテクチャの設計

コンテナは、MCPサーバーを安全に実行するための強固な基盤を提供しますが、それはほんの始まりに過ぎません。MCP サーバーとクライアントの数が増えるにつれて、シークレットの処理方法、脅威に対する防御方法、ツールの選択と承認の管理方法など、追加のガードレールと設計を検討することが重要です。 

安全なシークレット処理

これらのサーバーがランタイム構成シークレットを必要とする場合、コンテナベースのソリューションは、ユーザーがそのデータを提供するための安全なインターフェイスを提供する必要があります。その後、認証情報、API キー、OAuth アクセス トークンなどの機密情報は、承認されたコンテナ ランタイムにのみ挿入する必要があります。クラウドネイティブなデプロイと同様に、シークレットは分離されたままで、それを必要とするワークロードにスコープが設定されているため、偶発的な公開や誤用のリスクが軽減されます。

新たなMCPの脅威に対する防御

MCPエコシステムで新たに出現する脅威の多くは、悪意のあるサーバーがエージェントを騙し、MCPサーバーがユーザーの意図と矛盾するアクションを実行させようとするものです。これらの攻撃は、多くの場合、サーバーからクライアントに送信される有害なデータから始まります。

これを軽減するには、すべての MCP クライアント トラフィックを 1 つの接続エンドポイント、MCP ゲートウェイ、またはコンテナ上に構築されたプロキシ経由でルーティングすることをお勧めします。MCPサーバーを空港の乗客のように考えてください:1つの集中セキュリティチェックポイント(ゲートウェイ)を確立することで、飛行機に搭乗する前に全員がスクリーニングされることを保証します(MCPクライアント)。このゲートウェイは、MCP ラグ プル攻撃、MCP シャドウイング、ツール ポイズニングなどの脅威を早期に検出して阻止できる重要なインターフェイスになります。軽減策には以下が含まれます。

• MCP ラグプル: ユーザーの同意後にサーバーがツールの説明を変更できないようにします。新しいバージョンが導入された場合、クライアントは再認証する必要があります。
• MCP Shadowing: 意味的に近い説明を持つ一連のツールにアクセスできるエージェント セッション、または完全な競合を検出します。
• ツールポイズニング: ヒューリスティックまたはシグネチャベースのスキャンを使用して、ポイズニング攻撃でよく見られる操作プロンプトや誤解を招く機能など、ツールメタデータの疑わしいパターンを検出します。

MCP サーバーの選択と許可の管理

エージェントシステムが進化するにつれて、環境全体でどの MCP サーバーを信頼するか、特定のエージェントが実際に必要とする 2 つの決定を区別することが重要です。1 つ目は、信頼できる境界を定義し、使用できるサーバーを決定します。2つ目は、意図と範囲、つまり特定のクライアントがどのサーバーを使用すべきかを決定することです。

利用可能な MCP サーバーの数は急速に増加すると予想されるため、ほとんどのエージェントは、厳選された小さなサブセットのみを必要とします。これを管理するには、信頼性、選択的公開、および厳格なランタイム制御に関する明確なポリシーが必要です。理想的には、これらの決定は、ワークロードを保存、管理、および安全に共有するための組み込み機能と、意図しないアクセスを制限するために必要なガードレールを備えた、コンテナベースの配布を既にサポートしているプラットフォームを通じて実施する必要があります。

MCP セキュリティのベスト プラクティス

MCP 仕様の進化に伴い、readOnlyHint や destructiveHint などのツールレベルのアノテーションなど、便利な追加がすでに見られます。readOnlyHint は、ランタイムに読み取り専用モードでファイルシステムをマウントするように指示できるため、意図しない変更のリスクを最小限に抑えることができます。ネットワークのヒントを使用すると、MCP をインターネットから完全に分離したり、送信接続を限られたルートのセットに制限したりできます。これらのアノテーションをツールのメタデータで宣言することを強くお勧めします。コンテナの実行時に適用し、採用を促進するのに役立ちます - ユーザーは、明確に定義された境界を持つツールを信頼して実行する可能性が高くなります。

まず、開発者の生産性に焦点を当てます。しかし、これらのガードレールを簡単に導入してテストできるようにすることで、ガードレールが邪魔にならないようにし、これは、より安全で回復力のあるエージェントシステムをデフォルトで構築するための重要なステップです。

Docker がどのように役立つか  

コンテナは、MCPツールをパッケージ化して分離する自然な方法を提供し、MCPツールをより簡単かつ安全に実行できます。Dockerは、最新の MCPカタログとツールキットでこれをさらに拡張し、信頼できるツールの検出、共有、実行の方法を合理化します。

多くの開発者は、Docker がコンテナ化されたワークロード用の API を提供することを知っていますが、Docker MCP Toolkit は、MCP クライアントが MCP カタログにリストされている任意の信頼できるサーバーに安全に接続できるようにすることで、それに基づいて構築されています。これにより、エージェントとツールの間に制御されたインターフェイスが作成され、コンテナベースの配信でおなじみの利点である移植性、一貫性、分離性が得られます。

図 2:Docker MCPカタログとツールキットは、MCPサーバーをコンテナ内で実行することにより、クライアントに安全に接続します

Docker Hub の一部である MCP カタログは、信頼できる MCP サーバーを識別しながら、MCP クライアントを柔軟に構成できるようにすることで、成長を続けるツールのエコシステムを管理するのに役立ちます。開発者は、どのサーバーを任意のエージェントでも使用できるようにするだけでなく、特定のサーバーのスコープをエージェントに限定することもできます。MCP Toolkit は、信頼できる MCP サーバーの任意のセットを 1 つの統合接続である MCP ゲートウェイを通じて公開することで、これをさらに簡素化します。 

開発者は、シークレットの保存方法とシークレットへのアクセスを許可するMCPサーバーを定義して、常に制御します。各サーバーは、完全に構成され、すぐに実行できる Docker コンテナーを指す URL によって参照されます。ランタイムはコンテンツと設定の両方を処理するため、エージェントは、再現可能で検証可能で自己完結型の MCP ランタイムとのみ対話します。これらのランタイムは改ざん防止機能を備え、分離されており、ユーザーによって明示的に付与されたリソースのみにアクセスするように制限されています。すべての MCP メッセージは 1 つのゲートウェイを通過するため、MCP Toolkit は、脅威が MCP クライアントに表示される前に検出するための 1 つの強制ポイントを提供します。 

前の例に戻ると、構成は、構成された MCP サーバー コンテナーの許可されたセットを持つカタログへの 1 つの接続になりました。MCP クライアントには、STDIO 経由で構成された MCP サーバーの管理ビューが表示されます。その結果、MCPクライアントはMCPエコシステムに安全に接続できます。

{
  "mcpServers": {
    "mcpserver": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "alpine/socat", "STDIO", "TCP:host.docker.internal:8811"
      ],
    }
  }
}

概要

私たちは今、MCPツールの採用の進化において極めて重要なポイントにいます。エコシステムは急速に拡大しており、開発者主導であることに変わりはありませんが、エージェントシステムを安全に拡張する方法を模索しているユーザーが増えています。コンテナは、MCPツールの理想的なデリバリーモデルであることが証明されており、最小限の摩擦で分離、再現性、セキュリティを提供します。

Docker の MCP カタログとツールキットは、この基盤の上に構築されており、信頼できる MCP サーバーを共有して実行するための軽量な方法を提供します。ツールをコンテナとしてパッケージ化することで、ユーザーが既存のクライアントからすでにMCPを消費している方法を中断することなく、ガードレールを導入できます。このカタログは、現在、どの MCP クライアントと互換性があるため、ベンダーロックインなしで簡単に開始できます。

私たちの目標は、イノベーションの邪魔にならないように、MCPの採用を可能な限り安全かつシームレスにすることで、この動きの速い分野をサポートすることです。私たちは、MCPの導入を簡単で生産的なだけでなく、デフォルトで安全にするために、コミュニティと引き続き協力できることを嬉しく思います。

さらに詳しく

• MCP カタログとツールキット製品発売のブログをご覧ください 
• Docker MCP Catalog and Toolkit の使用を開始する
• ウェビナーに参加して、ライブの技術ウォークスルーをご覧ください。
• MCPのウェブページをご覧ください 
• Docker Navigator ニュースレターを購読してください。
• Docker は初めてですか? アカウントを作成します。 
• ご質問はございますか? Docker コミュニティがお手伝いします。