MCP session IDは利用者identityではない: 認証principalでstateを分離する
旧MCP sessionは通信stateを関連付けますが、利用者認証には使えません。Current MCPはprotocol sessionを廃止しており、どちらの世代でもrequest単位の認可とprincipalに結び付いたstate管理が必要です。
Read in EnglishMCP session IDはrequestやstreamを関連付けられますが、呼出者が誰かを決める情報ではありません。Final版2025-11-25のStreamable HTTPでは、serverが初期化時にMCP-Session-Idを発行し、clientは後続requestで返すことができました。それでも公式security guidanceは、全受信requestの認可、sessionを認証に使わないこと、認証済み利用者から導出した情報へsession stateを結び付けることを求めています。
この分離は、盗まれた、または推測されたsession IDによる利用者なりすましと、共有基盤が別利用者のeventやstateを配信する問題を防ぎます。RandomなIDは推測耐性を上げますが、所有者を証明しません。
配布済みprotocol世代を特定する
公式versioningは2026-07-28をCurrentとしています。このrevisionはprotocol-level sessionとMcp-Session-Id headerを廃止し、各Streamable HTTP requestをself-containedにしました。/draftは作業中で利用準備前です。一方、backward compatibilityにより2025-11-25以前の実装も残るため、SDK名から推測せずnegotiated versionを記録します。
| 配布挙動 | 必要な分離証拠 |
|---|---|
Final 2025-11-25のsession header | 全requestを認証し、認証principalとsecureなsession IDの組でstateを保存し、別principalでの再利用を拒否 |
Current 2026-07-28のrequest model | 全requestを認証・認可し、そのrequestのprincipalとscopeから利用可能toolとdataを決定 |
| 明示的application handle | 所持を権限とせず、利用ごとに(handle, principal)を認可 |
| 共有queueやcache | keyと認可にprincipal/tenantを含め、利用者・tenant間の配信を防止 |
旧session実装では、暗号学的に安全なrandom sourceでIDを生成し、必要に応じてexpire、rotateし、URLや通常logへ残しません。各requestでbearer token等を独立に検証し、そのcredentialから内部userとtenantを導出して、sessionが同じidentityに属することを確認します。Clientが送るuser IDをbinding証拠にしてはいけません。
Current MCPでは、暗黙のsession stateの代わりにserver-mintedの明示的handleを使う設計patternがあります。basket_id、browser context ID、workflow IDはconnectionを越え、chat historyやsubagent promptに残り得ます。そのためhandleでobjectを引き、認証principalが利用できるかを毎回確認します。Opaque IDと十分なentropyは推測を難しくしますが、access controlの代わりではありません。
失敗すべきcaseを試験する
異なるtenantにtest user AとBを作ります。Aがstateを作成し、Bの有効credentialとAの旧session IDまたは明示的handleを組み合わせます。Objectの存在まで漏らさず拒否されることが受入条件です。別server node、reconnect、queue delivery、cache済みtools/listでも繰り返します。Sessionやhandleが残っていても、logout、token revoke、scope縮小が反映されることを確認します。
同一principalのconcurrent requestも試験します。正当な共有stateを壊さず、どのload-balancer nodeが処理しても同じ認可になる必要があります。結果は実際のnegotiated protocol version、authentication middleware、state store、deployment topologyと結び付けて記録します。
確認範囲と限界
ここで扱うのはtransport sessionとapplication handle周辺のidentity分離です。同じ利用者の2つのagentがcart、browser、workflowを共有すべきかはapplication policyで決めます。Token audience validation、scope、tenant-awareなdatabase認可、有効なaccess token自体を盗まれた場合の対策も別に必要です。