MCPサーバーの41%が無認証──それを封筒で包んで守るMCPS（MCP Secure）を読む

MCPサーバーとクライアントの間でやり取りされるJSON-RPCメッセージには、署名がない。誰かが通信経路上でメッセージを改ざんしても、受け取った側にはそれを検知する方法がなく、「このメッセージは確かにこの相手が送った」と後から証明する手段（否認防止）もない——この課題に対処するIETF個人ドラフト「MCPS: Cryptographic Security Layer for the Model Context Protocol」（著者R. Sharif氏、CyberSecAI Ltd所属、rev01は2026年8月21日提出）の本文を確認した。この記事の執筆時点（8月28日）で提出からわずか1週間というできたてのドラフトだ。

3行まとめ

• MCPSは、MCPのコア仕様を変更せず、既存のJSON-RPCメッセージを署名済みの「封筒」で包む形で、エージェント身元検証・メッセージ単位の署名・ツール定義の完全性・リプレイ防止を実現する暗号セキュリティ層のドラフト。ECDSA P-256署名とJSON Canonicalization Scheme（RFC 8785）を暗号技術の基盤に使う
• 中心となる仕組みは「Agent Passport」——エージェントの身元と発行元（origin）にECDSA P-256の鍵ペアを紐づける署名済みの証明書。信頼レベル（trust_level、0〜4の整数）というフィールドを持つ
• L0（検証なし、現行MCPと同等）からL4（相互認証＋リアルタイム失効確認）まで5段階の信頼レベルを定義し、既存のMCPクライアント・サーバーとの後方互換性を保ちながら段階的に導入できる設計になっている

5段階の信頼レベル——L0からL4まで

MCPSが定義する信頼レベルの表はこうだ。

L0 None: No MCPS verification. Equivalent to current MCP behavior. Self-signed passports. / L1 Signed: Messages are signed. Passport signed by ANY Trust Authority. / L2 Verified: Messages are signed. Passport signed by a TA whose root key is in the verifier's trust store. / L3 Strict: L2 plus tool definition signatures MUST be present and valid. TA has verified origin ownership. / L4 Full: L3 plus mutual authentication and real-time revocation checking. TA has performed security audit.

（L0「なし」：MCPSによる検証なし。現行のMCPの振る舞いと同等。自己署名パスポート。L1「署名済み」：メッセージは署名されている。パスポートは任意の信頼機関（TA）によって署名されている。L2「検証済み」：メッセージは署名されている。パスポートは、検証者の信頼ストアにルート鍵があるTAによって署名されている。L3「厳格」：L2に加え、ツール定義の署名が存在し有効でなければならない（MUST）。TAは発行元の所有権を検証済み。L4「完全」：L3に加え、相互認証とリアルタイムの失効確認。TAはセキュリティ監査を実施済み。表内の原文は各セルがパイプ|で区切られた罫線表のため、この記事では改行と罫線を除いた地の文として引用している）

整理すると次のようになる。

信頼レベルの割り当てルールも厳格で、「自己署名パスポートは、他の主張にかかわらず常にL0として扱わなければならない（MUST）」「L4を主張するが未知のTAが署名したパスポートは、L0として扱わなければならない（MUST）」といった、詐称防止のための強制ルールを明記している。

DPoP（RFC 9449）との違いをドラフト自身が説明している

MCPSの著者は、似た目的を持つ既存のOAuth標準DPoP（Demonstrating Proof-of-Possession、RFC 9449）との違いをSection 1.4で明記している。DPoPは「OAuthアクセストークンの所持者が特定の鍵を持っていること」を証明するのに対し、MCPSはこれと似た証明機能を持ちながら3点で範囲を広げている、とドラフトは説明する。

1. セッション単位ではなくメッセージ単位の署名——個々のJSON-RPCメッセージそれぞれに署名し、特定のツール呼び出し・レスポンスの否認防止を可能にする
2. ツール定義の署名——DPoPはアーティファクト（ツール定義など）の完全性を扱わない
3. 信頼レベルのネゴシエーション——DPoPは段階的な信頼階層を定義しない

その上で「実装はMCPSとDPoPを組み合わせてもよい（MAY）。具体的には、Agent Passportの公開鍵をDPoPの証明と同じ鍵にすることで、OAuth認可とメッセージレベルの完全性の両方にまたがる統一されたIDを提供できる」と、競合ではなく併用可能な設計であることも述べている。

リプレイ防止とツールの「ラグプル」検知

Section 7「Replay Protection」は、署名済みメッセージごとに16バイトの暗号学的乱数（16進エンコードで32文字）をnonceとして必須にし、受信側はnonceストアで既出のnonceを記録・拒否する（MUST）と定めている。タイムスタンプの許容窓はデフォルト300秒（5分）、設定可能な範囲は30秒〜3600秒で、クロックスキュー許容（デフォルト60秒）を別途加える設計だ。nonceストアは「メッセージのバイト列全体」ではなく「nonce文字列そのもの」をキーにしなければならない（MUST）とも定めている。理由として、ECDSA署名には可鍛性（malleability）があり、有効な署名(r, s)に対して(r, n-s)という別の署名も同じメッセージに対して有効になってしまうため、メッセージバイト列をキーにするとこの変種がリプレイ検知をすり抜けてしまう、という具体的な攻撃シナリオを回避する設計だと説明されている。

Section 6.5「Rug Pull Detection」は、暗号資産の文脈で使われる「ラグプル（持ち逃げ）」という言葉を、ツール定義の書き換えに転用している。セッションをまたいでツールのtool_hashが変化した場合、名前・説明・スキーマが利用者に無断で変更された可能性がある、として、実装は少なくとも次のいずれかのポリシーをサポートしなければならない（MUST）としている——ユーザーに確認を求める「Alert」、拒否してエラーコード-33008を返す「Reject」、新しい定義を受け入れる「Accept」（ただしL3・L4では非推奨）。デフォルトはL1・L2で「Alert」、L3・L4で「Reject」が推奨されている。

Agent Passport——エージェントの「身分証明書」

Agent Passportの構造は具体的なJSONスキーマとして示されている。

{
  "mcps_version": "1.0",
  "passport": {
    "id": "ap_<uuid-v4>",
    "agent_name": "<string>",
    "origin": "<string (URI)>",
    "public_key": { "kty": "EC", "crv": "P-256", "x": "...", "y": "..." },
    "capabilities": ["<string>"],
    "trust_level": 0,
    "issuer_chain": ["<string (base64-encoded JSON)>"],
    "key_rotation": { "previous_key_hash": "<string (hex SHA-256)>" }
  },
  "signature": "<string (base64, IEEE P1363)>"
}

鍵ローテーション後も過去の鍵のハッシュを記録するフィールドを持つなど、証明書のライフサイクル管理まで具体的に設計されている。

動機として引用される数字——検証できたものとできなかったもの

ドラフトはMCPの現状の弱点をこう説明している。

Tool definitions (name, description, input schema) are served unsigned. A compromised or malicious server can modify tool descriptions to inject instructions into agent prompts (tool poisoning), or silently change tool behavior between sessions. [...] 41% of MCP servers have zero authentication (TapAuth research, scanning 518 production MCP servers). [...] An independent scan of 39 AI agent frameworks against the OWASP Top 10 for Agentic Applications found that 13 frameworks had no MCP security controls, 17 had partial controls, and only 9 implemented adequate protections.

（ツール定義（名前・説明・入力スキーマ）は署名なしで配信される。侵害された、あるいは悪意あるサーバーは、ツールの説明を書き換えてエージェントのプロンプトに指示を注入したり（ツールポイズニング）、セッションをまたいでツールの振る舞いを密かに変えたりできる。MCPサーバーの41%が無認証である（TapAuth研究、518の本番MCPサーバーをスキャン）。OWASP Top 10 for Agentic Applicationsに照らした39のAIエージェントフレームワークの独立スキャンでは、13フレームワークがMCPセキュリティ制御を一切持たず、17が部分的な制御、適切な保護を実装していたのはわずか9フレームワークだった）

この記事を書くにあたり「TapAuth research」という調査元の実在を確認しようとしたが、Wikipedia検索・GitHub検索の範囲では、518の本番MCPサーバーをスキャンしたというセキュリティ調査組織としての「TapAuth」を裏付ける情報は見つからなかった。「41%が無認証」という具体的な数字自体の真偽は、この記事では確認できていない。

統計の裏取りと暗号実装の評価はできていない

「OWASP Top 10 for Agentic Applications」に照らした39フレームワークのスキャン結果についても、元の調査データにこの記事では直接あたっていない。ドラフト巻末の「Appendix B: OWASP Risk Mapping」は、MCPSの各機能をOWASP Top 10 for Agentic Applications（2026）・OWASP MCP Top 10のリスク項目に対応づける表を掲載しているが、これはあくまでMCPS開発者側の自己申告のマッピングであり、OWASP側がこの対応関係を承認・言及しているわけではない。この点も、この記事ではOWASP側の一次資料まで遡って確認していない。

暗号設計の選択理由についてはドラフト自身が「Appendix C: Design Rationale」で説明している——ECDSA P-256を選んだ理由は「FIPS 186-5で義務付けられ、政府・企業のコンプライアンス要件を満たし、Web Crypto APIでサポートされているため」（Ed25519の方が性能は優れるがFIPS認証がない、としている）、署名エンコードにDER形式ではなくIEEE P1363形式（P-256で常に64バイト固定長）を選んだ理由は「可変長のDERよりパースの曖昧さを排除できるため」。ただし、この記事を書いている自分自身は、ECDSA署名やJSON Canonicalization Scheme（JCS）を使った暗号実装の経験がなく、これらの設計判断が暗号学的に妥当かどうかを評価する立場にはない。このドラフトが提出からわずか1週間というできたての段階にあるため、今後どう改訂されていくか、あるいはワーキンググループでの議論に発展するかも、この記事の一次ソースからは分からない。日本語ではZenn・Qiitaともに、MCPS単体を扱った記事は検索時点で見当たらなかった。

関連記事: MCP（Model Context Protocol）とは / AIセキュリティリスク──プロンプトインジェクション・データ漏洩対策【2026年】

感想・指摘はコメント欄へ。