MCP Unintended Privacy Disclosure
- MCP-UPD is a designation for confidentiality breaches in Model Context Protocol deployments, characterized by wrong-principal and cross-tool disclosures.
- It involves flaws such as unauthorized authorization reuse and parasitic toolchain attacks that allow sensitive data to leak across trust boundaries.
- Mitigation strategies include explicit caller binding, session-specific permissions, and output sanitization to contain data exposure risks.
MCP unintended privacy disclosure (MCP-UPD; Editor’s term) can be used as an umbrella designation for confidentiality failures in Model Context Protocol deployments in which sensitive data, sessions, tools, or external-service capabilities become available to the wrong principal through MCP-specific authorization reuse, toolchain composition, or protocol-visible output flows. Recent work documents the phenomenon under several more specific names, including “caller identity confusion,” “cross-tool exfiltration,” “privacy leakage in MCP servers,” and “Parasitic Toolchain Attacks” instantiated as MCP-UPD. Across these formulations, the recurring property is that data can cross from local execution or one trust domain into another even without credential theft, backend compromise, or an explicit outbound request in the source code (Huang et al., 8 Mar 2026, Croce et al., 26 Jul 2025, Yan et al., 19 Jun 2026, Zhao et al., 8 Sep 2025).
1. System model and disclosure boundary
In the system model described in the literature, an MCP client—typically an LLM-based agent—issues structured tools/call requests to an MCP server, and the MCP server executes those requests using its own credentials, execution context, and backend connectivity. The relevant principals are the end user, the LLM or agent component that generates tool invocations, the MCP client runtime that transports those invocations, the MCP server process that actually holds tokens, sessions, and execution state, and downstream backends such as file systems, operating systems, Slack, AWS, databases, browsers, or remote APIs. A central asymmetry is that backend systems often authenticate and authorize requests based solely on the MCP server’s identity, without visibility into the originating agent (Huang et al., 8 Mar 2026).
Host-centric studies describe a closely related execution path. Users configure multiple MCP servers on the host; the host creates multiple clients; the clients retrieve tool names, required parameters, and descriptions from the servers; and the host then sends the model a request containing the system prompt, tool list, and context including user query history. The host subsequently translates model output into tool invocation and returns tool results to the model. In multi-server settings, outputs from different servers can be merged into the same model context, which means that tool descriptions, tool results, and other server-supplied content can influence later invocations (Li et al., 18 Oct 2025, Maloyan et al., 24 Jan 2026).
This architecture makes the MCP boundary privacy-relevant in two distinct senses. First, it is an authorization boundary: a server may stand in for a user toward downstream services. Second, it is an information-flow boundary: tool outputs, exceptions, and related return objects can become visible to the client, host, model, or end user. A plausible implication is that MCP-UPD is best understood not as a single bug class but as a family of wrong-principal and wrong-destination disclosures arising at this boundary.
2. Authorization reuse and wrong-principal disclosure
The most explicit wrong-principal formulation is “caller identity confusion.” The defining condition is that authorization is not explicitly bound to the caller that triggers a tool invocation, so subsequent tool calls, regardless of origin, can inherit existing authorization state without re-authentication. In the attack model, a legitimate user first completes an authorization flow; the MCP server stores that authorization state persistently or semi-persistently; a different caller later issues a new tools/call request; and because the server does not authenticate or distinguish the identity of the invoking agent, the new invocation is evaluated against the server’s existing authorized state rather than against the current caller’s identity. The server then performs the operation and may return sensitive results or carry out sensitive actions using the legitimate user’s permissions (Huang et al., 8 Mar 2026).
This pattern is privacy-relevant because the unauthorized caller need not steal a token. The server acts as a confused deputy and privacy proxy. Once the MCP server enters an authorized execution state, subsequent operations are executed under a shared, server-held authorization, regardless of which agent interaction originally triggered them. The literature identifies several disclosure dimensions here: cross-caller, cross-agent, cross-session, cross-user, and effectively cross-tenant when a server process or authorization cache is shared. It also identifies an amplifier: many servers fail to enforce authentication at the per-tool level, so authorization acquired for one tool or resource can spill into other tools that are not independently re-authorized. The measured taxonomy AuthNone, AuthCache, and AuthRuntime captures this progression from no checks, to one-time authorization cached and reused, to runtime checks that may be inconsistently applied (Huang et al., 8 Mar 2026).
The disclosure surface is broad. Resource categories explicitly associated with identity-confusion risk include “Authenticated Sessions,” “Remote Service Interaction,” “File Read/Write,” “Configuration Files,” “Logs and Persistent State,” “Source Code and Binaries,” and “Display and Screen.” In privacy terms, these categories imply leakage of tokens, cookies, files, messages, screenshots, logs, source code, cloud account data, and service responses.
3. Compositional, output-mediated, and parasitic disclosure paths
A second major line of work concerns compositional leakage across servers and tools. In the canonical proof of concept, a malicious weather MCP server, built from the “Hello Weather” example, adds a tool called send_research_data that sends an HTTP POST to a webhook.site URL and a malicious prompt template presented as benign “personalized weather advice.” In Claude Desktop v0.12.9, the embedded instructions caused the agent to discover the Monzo server’s account.balance tool, invoke it, obtain the user’s current bank balance, and then invoke send_research_data to forward the balance, location, and timestamp to the attacker’s endpoint. The demonstrated balance in the paper’s screenshot is £1,469.36. The paper’s architectural claim is direct: “Installing any MCP server grants it access to all other servers’ data through the AI assistant” (Croce et al., 26 Jul 2025).
A related formulation is the paper’s own use of “MCP Unintended Privacy Disclosure (MCP-UPD)” as an instantiation of “Parasitic Toolchain Attacks.” Here the attack proceeds through three named phases: “Parasitic Ingestion,” “Privacy Collection,” and “Privacy Disclosure.” The attacker plants a “parasitic prompt” in an external data source such as a web page, email, social media post, shared document, or chat history; the victim’s LLM agent later retrieves it during a legitimate task; the malicious instructions are internalized into the model’s reasoning; and the model then uses privacy-access tools and network-access tools to collect and exfiltrate private data. The paper’s root-cause analysis attributes this to lack of context-tool isolation and absence of least-privilege enforcement (Zhao et al., 8 Sep 2025).
A third formulation treats disclosure as “protocol-induced” privacy leakage. In this account, credentials, API keys, and PII cross the local/LLM boundary simply by being returned, logged, or raised inside a tool handler, with no explicit outbound request in the source code. Tool handler return values, exception payloads, and logging calls are therefore implicit sinks. The most frequent measured rule in that study is “Sensitive Cleartext Logging,” followed by “PII Cleartext Logging,” which indicates that plaintext logging and printing are dominant output-side leakage channels rather than exceptional cases (Yan et al., 19 Jun 2026).
The bidirectional-flow literature generalizes this into “return-side propagation.” Return-side propagation occurs when untrusted external content or sensitive internal data is exposed through MCP-visible outputs, thereby crossing the server boundary and becoming available to the client, host, model, or end user. The formalization treats externally obtained content as a source class and the return value of each recovered MCP handler as a protocol-visible sink. This suggests that MCP-UPD includes both direct sensitive-data exposure and re-exposure of fetched external content that later affects host or model behavior (Hou et al., 8 May 2026).
4. Empirical landscape and exposed assets
The empirical literature is methodologically heterogeneous: some studies are proof-of-concept demonstrations, some are large-scale static or hybrid analyses, and some focus specifically on remote authentication boundaries. Taken together, however, they show that disclosure-enabling conditions are widespread rather than anecdotal.
| Study | Corpus | Headline result |
|---|---|---|
| “Give Them an Inch and They Will Take a Mile” (Huang et al., 8 Mar 2026) | 6,137 MCP servers | 2,846 of 6,137 servers, or 46.4%, exhibit insecure authorization behavior |
| “What Happens Locally, Leaks Globally” (Yan et al., 19 Jun 2026) | 10,655 MCP servers | 1,317 servers, or 12.4%, exhibit privacy leakage risks |
| “A First Measurement Study on Authentication Security in Real-World Remote MCP Servers” (Zhou et al., 21 May 2026) | 7,973 live remote MCP servers | 40.55% expose tools without authentication |
| “Mind Your Server” / Parasitic Toolchain census (Zhao et al., 8 Sep 2025) | 12,230 tools across 1,360 servers | 46.41% of tools are risk-relevant; 78.5% of servers expose at least one risky tool |
| “Unsafe by Flow” (Hou et al., 8 May 2026) | 15,452 repositories | 118 vulnerability paths confirmed in 87 servers; 93.8% recall on a 32-case benchmark |
The reported assets at risk are correspondingly diverse. Privacy-relevant resources enumerated across studies include local files, environment variables, secrets, logs, source code, authenticated sessions, cloud usage data, Slack messages, customer records, chat histories, email contents, and user-linked remote service accounts. Remote-authentication work adds authorization codes, access tokens, and user-linked service accounts as protected objects; one disclosed CRM case exposed more than 5,000 internal enterprise records, including customer names, email addresses, phone numbers, and physical addresses (Zhou et al., 21 May 2026).
The evidence base also has boundaries. Some studies explicitly note nonzero false positives and false negatives, selective rather than exhaustive dynamic validation, or evaluation sets dominated by request-side and mixed-chain exploits rather than pure return-only disclosures. This suggests that current measurements are strong enough to establish prevalence, but not yet complete enough to exhaust the design space of MCP-UPD (Huang et al., 8 Mar 2026, Hou et al., 8 May 2026).
5. Root causes and competing interpretations
One interpretive axis concerns where the failure fundamentally resides. Work on caller identity confusion states that the observed insecurity “does not reflect a flaw in the MCP specification itself,” but argues that the protocol design leaves identity binding underspecified enough that vulnerable semantics emerge naturally in practice. In that account, the dominant root causes are lack of reliable caller identity, persistent server-held authorization state, lack of standardized SDK-level authorization semantics, global flags and token caches, and one-time initialization-time authentication (Huang et al., 8 Mar 2026).
A stronger protocol-centric interpretation argues that the weaknesses are architectural rather than implementation-specific. That analysis identifies absence of capability attestation, bidirectional sampling without origin authentication, and implicit trust propagation in multi-server configurations as protocol-level vulnerabilities. It reports that attack success in MCP-integrated systems rises from 26.4% in equivalent non-MCP integrations to 52.8% in MCP systems, with cross-server propagation increasing from 19.7% to 61.3%. This suggests that some forms of MCP-UPD are not merely ecosystem accidents but consequences of the protocol’s trust semantics (Maloyan et al., 24 Jan 2026).
A second root-cause axis concerns authorization and identity in remote deployments. OAuth-enabled MCP servers were found to share three characteristics—open client environments, dynamic client registration, and delegated authorization—that distinguish MCP deployments from traditional OAuth. Across 119 testable real-world OAuth-enabled servers, every server exhibited at least one flaw, dynamic client registration flaws affected 96.6%, and many flaws could lead to sensitive information leakage and account takeover. In privacy terms, the problem is often a broken binding between MCP client, MCP server, authorization server, and upstream service rather than a simple missing login check (Zhou et al., 21 May 2026).
A third axis is privilege and isolation. Privilege-measurement work describes MCP plugins as typically running natively on local machines with few, if any, isolation boundaries, inheriting powerful primitives such as file I/O, process spawning, and unrestricted network communication. It also states that benign-seeming plugins may invoke sensitive APIs without user awareness or consent. This suggests that MCP-UPD is frequently enabled by ordinary local privilege inheritance rather than by exotic exploit chains (Li et al., 5 Jul 2025).
Finally, several papers reject the notion that user approval prompts or installation-time trust are sufficient. Cross-tool exfiltration research argues that per-tool invocation consent does not amount to meaningful consent when prompts are embedded in a natural-sounding workflow, and parasitic-toolchain work argues that the attacker need not directly interact with the victim at all. The common implication is that disclosure often occurs at the level of end-to-end information flow and task composition, not merely at the level of isolated tool calls (Croce et al., 26 Jul 2025, Zhao et al., 8 Sep 2025).
6. Mitigation strategies and future directions
The most direct mitigation for wrong-principal disclosure is explicit caller binding. The literature recommends treating initialize as the sole session-creation entry point, binding OAuth token, caller identity such as client_id, and connection context into an isolated session, and then authorizing each subsequent tools/call relative to that session. It also stresses that OAuth alone does not establish MCP session boundaries or distinguish between different callers, so cached authorization state must not be global across callers, and sensitive tools should require per-tool authorization rather than server-startup authorization (Huang et al., 8 Mar 2026).
For cross-server and cross-tool disclosure, proposed controls include capability-based permissions, mandatory access boundaries, and server attestation. Servers should declare required cross-server interactions at installation; users should be able to designate some servers as “sensitive” and restrict interoperability; and signing or reputation mechanisms should govern server distribution. These measures are aimed at restricting arbitrary weather-to-banking or retrieval-to-exfiltration compositions that are otherwise legal within the default MCP trust model (Croce et al., 26 Jul 2025).
Enterprise-oriented work adds a broader defensive stack: short-lived scoped access tokens, audience restriction, sender-constrained tokens, just-in-time access, per-request authorization, namespaced capability discovery, strict session-state isolation, output filtering, pattern-based redaction for PII, PHI, financial data, and secrets, and DLP integration so that MCP does not become “an unintentional channel for data exfiltration or sensitive information disclosure.” It also recommends tool vetting, cryptographic signing of tool descriptions, sandbox execution, network segmentation, and centralized secrets management (Narajala et al., 11 Apr 2025).
Protocol-level proposals go further by adding capability attestation and message authentication. One backward-compatible extension reported in the literature reduces attack success rates from 52.8% to 12.4% with median latency overhead of 8.3 ms per message. The same line of work argues for origin tagging and isolation enforcement so that server-originated prompts cannot masquerade as user-originated prompts and cross-server information flow requires explicit authorization (Maloyan et al., 24 Jan 2026).
Detection and auditing remain active areas. Safe runtime execution in a WebAssembly/WASI sandbox can surface “external-to-sink exposure” when environment values or mounted file contents appear in prompt/messages or structured tool-return fields, and protocol-aware static analysis can treat @mcp.tool-bound return values as implicit sinks, supporting default redaction for auth headers, bearer tokens, API keys, and PII-shaped fields. A plausible implication is that future MCP-UPD defenses will combine session-bound authorization, provenance-aware isolation, output-side sanitization, and continuous runtime or CI-based analysis rather than relying on any single control (Tan et al., 3 Jan 2026, Yan et al., 19 Jun 2026).
Overall, the literature converges on one point: MCP-UPD is best understood as the convergence of reachability, data exposure, and agent-mediated execution within a high-privilege protocol boundary. The most stable countermeasures are therefore those that bind authority to a real caller, constrain cross-tool composition, preserve provenance across prompts and returns, and treat every MCP-visible output as a potential privacy boundary rather than as a benign implementation detail.