複数MCP間のdata flow: source、field、送信先の確認
MCPでは各clientが1serverへ接続し、hostが複数clientのcontextを集約します。接続の分離は、あるserverのdataを別serverのtool callへ渡す許可にはなりません。
Read in Englishstable MCP architectureでは、一つのclient instanceは一つのserverとだけ通信し、hostがcontext aggregation、authorization decision、consent、cross-server security boundaryを管理します。この構造により、一つのserverが別serverのprotocol sessionを直接読むことは防げます。一方で、hostやmodelがServer Aの返却内容をServer Bへのtool callへ入れる経路まで、自動的に禁止するものではありません。
security判断の単位は、二つの接続だけでなく、その間のtransferです。private data serverと外部送信serverがそれぞれ正しく認証されていても、組合せによって意図しないdestinationへ情報が渡る場合があります。token audience bindingはserver間でcredentialが流用されることを防ぎますが、customer recordをticket、email、web requestへコピーしてよいかは決めません。
正常な二接続から不適切なtransferが生まれる例
一つのMCP serverがHR directoryを読み、別のMCP serverが外部support providerへticketを作成するとします。利用者はonboarding遅延のsummaryを依頼しました。HRからの結果には氏名、personal email、休暇理由が含まれています。summaryをsupport ticketへ送る業務目的があっても、読取時の承認だけでは、どのfieldをproviderへ渡せるか確定しません。
| transfer要素 | source側の確認 | destination側の確認 |
|---|---|---|
| record identity | 承認されたqueryの対象者か | ticketに個人識別が必要か |
| sensitive field | readerにaccess権限があるか | providerへの提供が承認済みか |
| 派生summary | どのsource fieldから作られたか | 除外情報を推測できないか |
| attachmentまたはURI | 取得が許可されたか | destinationが再取得・再公開しないか |
| credential | Server A向けaudienceか | Server B用に別tokenが発行されるか |
最後の行はstable protocolの要件です。2026年7月版authorization仕様は、serverが自分向けに発行されたtokenであることを検証し、別tokenの受理や中継を禁止しています。この制御はcredentialを分離します。dataの各行には、別途host policyと利用者consentが必要です。
server間handoffで強制する項目
cross-server callごとに、source serverとresource、選択したdata field、destination serverとaccount、予定operation、承認者の五項目をtransfer記録にします。writeまたは外部送信の前に、この五項目を表示します。「toolを許可」という一括確認だけでは、送信先がinternal project、public repository、third-party tenantのどれかを判断できません。
両側へleast privilegeを適用します。readerは現在のqueryに必要なsource scopeだけ、destinationは選択したtargetへのwrite scopeだけを持ちます。credentialは分離し、tokenをmodel contextやtool argumentへ入れません。workflow上可能なら、外部調査、private data分析、外部公開を別sessionへ分け、一つのinjected resourceが三つの能力すべてへ到達しないようにします。
synthetic fieldへ識別可能なcanary値を入れて確認します。許可fieldは選択したdestinationだけに届き、除外fieldはtool argument、destination record、log、error messageのいずれにも残らないことを確認します。destination accountやtenantを変えた場合は拒否されることも試験します。これは推奨するacceptance testであり、今回transferを実行した結果ではありません。
Invariant LabsのGitHub MCP実験は、経路全体を試験する具体的な理由を示しています。public issue内の攻撃者制御文が、private repositoryを読み、public pull requestを作るflowへ影響しました。これはtrust boundaryをまたぐ組合せの問題であり、protocolのconnection isolationが破られたという主張ではありません。
仕様の状態と限界
2026年9月22日に確認した規範的な根拠は、2026年7月28日版のstable MCP仕様です。draft仕様は別に確認し、導入済みの強制制御としては扱っていません。将来のclientでfeatureの表現やnegotiationが変わっても、draftであること自体が現在のdata transferを許可する理由にはなりません。
今回のreviewでは、特定hostの検査、GitHub実験の再現、すべてのmulti-server sessionでdata leakが起きるという検証は行っていません。server isolation、token isolation、data transfer authorizationは三つの別確認であり、sensitive fieldがdestination境界を越える前に、それぞれの証拠が必要です。