AIアシスタントを実際のツールに接続する際に最も重要なのは信頼です。MCPコンテナ化は強力な隔離を提供し、故障や侵害されたサーバーの侵入範囲を制限しますが、Docker MCPソリューション全体での信頼とセキュリティを強化し、悪意のあるコードへの曝露をさらに減らしています。MCPエコシステムが数百台から数万台のサーバー(さらにはそれ以上)に拡大する中で、どのコードが実行されているか、どのように構築され、なぜ信頼されているのかを証明するより強力な仕組みが必要です。
提出からメンテナンス、日常使用に至るまで、MCPライフサイクル全体にわたる信頼を強化するために、3つの重要な強化を導入しました。
- コミットピンニング:Docker MCPレジストリ ( MCPカタログの真実の情報源)にあるすべてのDocker構築MCPサーバーは特定のGitコミットに紐づきされており、各リリースが正確に帰属可能かつ検証可能になります。
- 自動化されたAI監査による更新:新しいアップデートワークフローにより、提出されたMCPサーバーが常に最新に保たれ、変更のエージェントティックなレビューにより警戒はスケーラブルかつ追跡可能になります。
- パブリッシャーの信頼度:MCPカタログにより明確な信頼指標を導入し、開発者が公式で検証済みのサーバーとコミュニティ投稿のエントリーを簡単に区別できるようにしました。
これらのアップデートは、DockerでMCPを大規模に構築・利用するすべての人にとって、透明性とセキュリティの基準を引き上げます。
ローカルMCPサーバーのコミットピン
Docker MCP レジストリ内のローカルMCPサーバーは、 source.commitで特定のGitコミットに紐づけられています。そのコミットハッシュは、私たちが構築・公開するサーバーコードの正確なリビジョンを示す暗号学的な指紋です。このピンニングがなければ、 最新 やブランチ名のような参照は、その参照に現在存在するものをビルドし、ビルドは非決定的になり、上流リポジトリが侵害された場合にサプライチェーン攻撃に脆弱になります。Gitタグでさえ、削除して別のコミットを指すために再作成できるので、本当の意味で不変ではありません。対照的に、コミットハッシュは対象となるコンテンツと暗号的に結びついているため、そのコミットの監査結果は永続的な結果となります。
より簡単にするために、作成ツール(便利な MCPレジストリウィザードなど)を更新し、新しいサーバーエントリを作成する際にこのコミットピンを自動的に追加できるようにしました。また、 CIパイプラインにコミットピンの存在を強制しています (ピンが欠落または不形すると検証に失敗します)。この強制は意図的であり、配布されるコードの明確な出所を確立せずに誤ってサーバーを公開することは不可能です。また、追跡可能性のために org.opencontainers.image.revision ラベルを通じて MCP サーバーの画像メタデータにピンを伝播しています。
レジストリでの例は以下の通りです:
# servers/aws-cdk-mcp-server/server.yaml
name: aws-cdk-mcp-server
image: mcp/aws-cdk-mcp-server
type: server
meta:
category: devops
tags:
- aws-cdk-mcp-server
- devops
about:
title: AWS CDK
description: AWS Cloud Development Kit (CDK) best practices, infrastructure as code patterns, and security compliance with CDK Nag.
icon: https://avatars.githubusercontent.com/u/3299148?v=4
source:
project: https://github.com/awslabs/mcp
commit: 7bace1f81455088b6690a44e99cabb602259ddf7
directory: src/cdk-mcp-server
そして、公開されたMCPサーバーイメージのコミットピンを検証する方法の例をご紹介します。
$ docker image inspect mcp/aws-core-mcp-server:latest \
--format '{{index .Config.Labels "org.opencontainers.image.revision"}}'
7bace1f81455088b6690a44e99cabb602259ddf7
実際、 cosign と jq コマンドが利用可能であれば、追加の検証も行えます:
$ COSIGN_REPOSITORY=mcp/signatures cosign verify mcp/aws-cdk-mcp-server --key https://raw.githubusercontent.com/docker/keyring/refs/heads/main/public/mcp/latest.pub | jq -r ' .[].optional["org.opencontainers.image.revision"] '
Verification for index.docker.io/mcp/aws-cdk-mcp-server:latest --
The following checks were performed on each of these signatures:
- The cosign claims were validated
- Existence of the claims in the transparency log was verified offline
- The signatures were verified against the specified public key
7bace1f81455088b6690a44e99cabb602259ddf7
リズムを保つ
一度サーバーがレジストリに登録されると、管理者が上流リポジトリにマージするたびにピンを手動で編集する必要がないように(彼らは時間の使い方がもっと大切なので)、 新しい自動化ワークフロー が毎晩上流をスキャンし、新しいリビジョンがあるときは source.commit を優先し、レジストリ内で監査可能なPRを開いて上流の変更を追跡します。これにより、メンテナンスの手間をかけずにピン(レビュー済みコードへの不変な参照)というセキュリティ上のメリットが得られます。更新は引き続きプルリクエストを通じて流れ、レビューゲートと承認の軌跡で、どの新しいコードがサプライチェーンに入っているかを正確に示します。更新ワークフローはサーバーごとに動作し、各サーバー更新には独自のブランチとプルリクエストが割り当てられます。
しかし、ここで疑問が生じます。今後の変更が安全であるとどうやって分かるのでしょうか?
レビューループの中のAIや、人間が責任者です
提案されたすべてのコミットピンバンプ(および新しいローカルサーバー)は、上りに入った変更に対して エージェント型AIのセキュリティレビュー の対象となります。レビュアー(Claude Code と OpenAI Codex)はMCPサーバーの挙動を分析し、リスクの高いまたは悪意あるコードのフラグを立て、PRに構造化されたレポートを追加し、 セキュリティリスク:高い 、 セキュリティブロックなどの標準化されたラベルを提供します。人間は最終的な判断のためにループに残りますが、エージェントたちは容赦なく、スケーラブルです。
課題は、信頼できないコードが信頼できないエージェントを意味するということです
信頼できないコードを解析するためにCIでAIエージェントを実行すると、根本的な問題に直面します。エージェント自体が攻撃ベクトルになるのです。これらは慎重に作られたコードコメントやファイル名、リポジトリ構造を通じて プロンプト注入 されやすいです。悪意あるPRは、審査エージェントを操作して危険な変更を承認させたり、秘密を漏洩させたり、レビュープロセス自体を改変させようとすることがあります。
レビュー対象のコードを信用することはできませんが、それをレビューするエージェントを完全には信用できません。
孤立病原体
当社の Composeベースの セキュリティレビュアーアーキテクチャ は、AIエージェントを信頼できないコンポーネントとして扱うことでこの信頼の問題に対処しています。エージェントは、厳しく制御された入出力を持つ、厳しく隔離されたDockerコンテナ内で動作します。
- 監査対象のコードは読み取り専用でマウントされており 、エージェントはコードを分析できますが、変更はできません。さらに、監査されるコードは上流リポジトリの一時的なコピーに過ぎませんが、読み取り専用アクセスがあるため、エージェントはコンテナ外で誤って実行される可能性のあるスクリプトを修正することはできません。
- エージェントは孤立した出力ディレクトリにのみ書き込みができます — 出力が書き込まれると、エージェントのCLIラッパーは特定のファイル(Markdownレポートと固定名のラベル付きテキストファイル)のみを抽出し、そのディレクトリに書き込まれる可能性のある悪意のあるスクリプトやファイルは削除されます。
- エージェントは直接インターネットにアクセスできず 、レビュアーコンテナは外部サービスにアクセスできません。
- CIの秘密情報やAPI認証情報はレビュアーコンテナに入りません 。代わりに、別の Dockerネットワーク 上の軽量 リバースプロキシ がレビュアーからのリクエストを受け付け、推論提供者APIキーをアウトバウンドリクエストに注入し、そのキーをレビュー中のコンテナ化コードから遮蔽します。
これらすべては Docker Composeスタック にカプセル化され、ローカルでもCIでもエージェントを実行できる 便利なCLI でラップされています。
最も重要なのは、このアーキテクチャが悪意のあるPRがプロンプト注入によってエージェントを操作した場合でも、被害を封じ込めることを保証することです。エージェントは秘密にアクセスできず、コードを改変できず、外部攻撃者と通信することもできません。
CI統合とGitHubチェック
レビューワークフローはPRが開かれたり更新されたりすると自動的にトリガーされます。外部PRに対してはこれらのワークフローをある程度管理しており、悪意のあるPRが推論APIクレジットを使い果たすのを防ぐために手動トリガーが必要です。これらのレビューはGitHub ステータスチェックとして直接表示され、各サーバーは分析に対して専用のステータスチェックを受け取ります。
その結果、チェックステータスはエージェントが決定したリスクレベルに対応します。重要な発見は合併ブロックの失敗判定となり、高・中レベルの発見は中立的な警告を生み出し、低リスクや情報発見は通過します。私たちはまだこれらの基準を調整しており(担当者により厳格に対応してもらったため)、現在は報告書を手動で確認していますが、最終的には最新のPRを自動承認・統合できるレベルまで調整する予定です。その間、これらの報告はスケーラブルな「炭鉱のカナリア」として機能し、Docker MCPレジストリの管理者に対して、悪意あるものも偶発的なリスクも知らせます。
MCPレジストリリポジトリのエージェントコードはあくまで例ですが(MITライセンスの下で利用可能な機能的なものです)、実際に運用しているセキュリティレビューエージェントはプライベートリポジトリに存在し、追加の隔離が施されていますが、同じアーキテクチャに従っています。
報告書とリスクラベル
こちらは自動レビュアーが作成したレポートの 例 です:
# Security Review Report
## Scope Summary
- **Review Mode:** Differential
- **Repository:** /workspace/input/repository (stripe)
- **Head Commit:** 4eb0089a690cb60c7a30c159bd879ce5c04dd2b8
- **Base Commit:** f495421c400748b65a05751806cb20293c764233
- **Commit Range:** f495421c400748b65a05751806cb20293c764233...4eb0089a690cb60c7a30c159bd879ce5c04dd2b8
- **Overall Risk Level:** MEDIUM
## Executive Summary
This differential review covers 23 commits introducing significant changes to the Stripe Agent Toolkit repository, including: folder restructuring (moving tools to a tools/ directory), removal of evaluation code, addition of new LLM metering and provider packages, security dependency updates, and GitHub Actions workflow permission hardening.
...
レビュアーは、特定の上流コミットによってもたらされた変更点を分析する 差分 分析と、コードベース全体を調査する 完全な 分析の両方を行えます。私たちはPRの鑑別検査とフル分析の両方を定期的に行う予定です。
なぜ行動分析が重要なのか
従来のスキャナーは依然として必須ですが、CVEとの依存関係、構文的誤り(スイッチ文の抜けた区切りなど)、メモリ安全の問題(初期化されていないポインタのデリファレンスなど)に焦点を当てる傾向があります。MCPはコードの挙動も検証することを求めます。最近の悪意ある郵便印を押したMCPパッケージのなりすましを考えてみてください。攻撃者への送信メールを静かにBCCした一行のバックドアです。このようなイベントは、私たちのレジストリが情報提供前に出所と行動を意識したレビューを結びつける理由を裏付けています。
実際の結果
これまでのスキャンでは、MCPサーバーやDocker Hardened Images パイプライン内の類似エージェントの両方で、上流プロジェクトでいくつかの実際の問題を発見しました(続報のブログ記事もご期待ください)。これまで悪意のあるものは遭遇しておらず、セキュリティに関わる論理エラーに限られていますが、これらのエージェントが特定できる問題の細かさと微妙さは驚くべきものです。
Docker MCPカタログにおける信頼レベル
前述の技術的な変更に加え、Docker MCPカタログにパブリッシャーの信頼レベルを導入し、Docker DesktopのDocker MCP Toolkit と Docker MCP Hubの両方で公開しています。各サーバーには「既知の出版社」からのものかコミュニティによって管理されているかを示すアイコンが付けられます。いずれの場合もコードのレビューは続けますが、これらの指標はMCPサーバーの起源に関する追加の文脈を提供するはずです。
図 1:こちらは既知の信頼できるパブリッシャーによって公開されたMCPサーバーの例、AWS Terraform MCPです
図 2:Fetch MCPサーバー、MCPコミュニティサーバーの一例
これはコミュニティにとって何を意味するのでしょうか?
パブリッシャーは現在、コード変更の記録と監査可能な記録に裏付けられた、継続的な上流の改善の恩恵を受けています。コミットピンは 各リリースの正確な帰属を可能にし、夜間のアップデーターはパブリッシャーやメンテナの余計な労力なしにカタログを最新に保ちます。AI搭載のレビュアーは 私たちの警戒心を拡大し、人間のレビュアーが最も重要なエッジケースに集中できるようにします。
同時に、MCPサーバーを利用する開発者はサーバーのパブリッシャーを明確に把握できるため、公式、コミュニティ、サードパーティの貢献を区別しやすくなります。これらの強化は、Dockerエコシステム内でMCPサーバーに貢献または依存するすべての人々の信頼とセキュリティを強化します。
こちらの提出ガイダンスに従って、MCPサーバーをDockerに提出してください!
さらに詳しく
- MCP カタログの探索: コンテナー化されたセキュリティ強化された MCP サーバーを発見します。
- MCP ツールキットの使用を開始する: MCP サーバーを簡単かつ安全に実行します。
- Docker MCP Catalog and Toolkit のドキュメントが見つかります。
