Cross-Server MCP Data Flow: Verify the Source, Fields, and Destination
MCP gives each client one server connection, while the host aggregates context across clients. That connection isolation does not authorize copying data from one server into another tool call.
Read in JapaneseThe stable MCP architecture assigns each client instance to exactly one server and makes the host responsible for context aggregation, authorization decisions, consent, and cross-server security boundaries. This design prevents one server from directly reading another server’s protocol session. It does not prevent the host or model from taking content returned by Server A and placing it in a call to Server B.
The security decision therefore belongs to the transfer, not only to either connection. A private-data server can be correctly authenticated, and an outbound server can be correctly authenticated, while their combination still discloses information to an unintended destination. Token audience binding protects credentials from reuse across servers; it does not decide whether a customer record may be copied into a ticket, email, or web request.
A valid connection pair can create an invalid flow
Assume one MCP server reads an HR directory and another creates tickets for an external support provider. A user asks for a summary of onboarding delays. The HR result contains names, personal email addresses, and leave notes. Sending the summary to the ticket server may be useful, but the original read approval does not establish which fields the support provider may receive.
| Transfer element | Source-side question | Destination-side question |
|---|---|---|
| Record identity | Was this person in the approved query? | Is identity required for the ticket? |
| Sensitive fields | Did the reader have access to them? | Is the provider approved to receive them? |
| Derived summary | Which source fields contributed? | Could the summary reveal excluded facts? |
| Attachment or URI | Was retrieval authorized? | Will the destination dereference or republish it? |
| Credential | Is it audience-bound to Server A? | A separate token must be issued for Server B |
The last row is a stable protocol requirement. The July 2026 authorization specification requires servers to validate that tokens were issued for their own audience and forbids accepting or transiting other tokens. Those controls separate credentials. The data rows still require host policy and user consent.
Controls at the handoff point
Represent every cross-server call as a transfer record with five fields: source server and resource, selected data fields, destination server and account, intended operation, and approval identity. Show those fields before a write or external send. A generic “allow tool” confirmation cannot show whether the destination is an internal project, a public repository, or a third-party tenant.
Apply least privilege to both sides. The reader should receive only the source scopes needed for the current query. The destination should receive only the write scope and object boundary required for the chosen target. Keep the two credentials separate and do not place either token in model context or tool arguments. Where the workflow permits, use different sessions for external research, private-data analysis, and outbound publication so that a single injected resource cannot reach all three capabilities.
Test with synthetic fields carrying recognizable canary values. A permitted field should arrive only at the selected destination; an excluded field must remain absent from tool arguments, destination records, logs, and error messages. Confirm denial when the destination account or tenant changes. This is a proposed acceptance test; no transfer was executed for this review.
Invariant Labs’ GitHub MCP demonstration provides a concrete reason to test the full path: attacker-controlled text in a public issue was shown influencing a flow that read private repositories and created a public pull request. The finding concerns composition across trust boundaries, not a claim that protocol connection isolation failed.
Specification status and limits
The normative basis reviewed on September 22, 2026 is the stable MCP revision dated July 28, 2026. The draft specification was checked separately and is not treated as a deployed control. Draft work can change how future clients express or negotiate features, but a draft label cannot authorize a present data transfer.
This review did not inspect a specific host, reproduce the GitHub demonstration, or prove that every multi-server session leaks data. It establishes that server isolation, token isolation, and data-transfer authorization are three separate checks. All three need evidence before sensitive fields cross a destination boundary.