Secrets leaking out of MCP servers: detecting protocol-induced exposure

What is this?

The Model Context Protocol (MCP) has become the default way to plug large language models into external tools and data. A late-June 2026 arXiv paper, “What Happens Locally, Leaks Globally”: Detecting Privacy Leakage Risks in MCP Servers (2606.21338), argues that this convenience carries a specific, under-examined risk: sensitive values escape from MCP server code not through an obvious exfiltration call, but through the ordinary mechanics of the protocol itself.

The paper’s central observation is that leakage here is protocol-induced. In a conventional application, a data-exfiltration bug usually involves an explicit outbound request — an HTTP POST, a socket write, a log shipped off-box. In an MCP server, a credential, API key or piece of personally identifiable information (PII) can cross the boundary from the local machine to the LLM simply by being returned from a tool handler, written to a log, or raised inside an exception message. There is no send() in the source code to grep for. The value leaves the trusted local context the moment it lands in something the model will read.

To measure how common this is, the authors built MCPPrivacyDetector, a static-analysis framework, and ran it across 10,655 real-world MCP servers. It reports leakage in more than 10% of them, with confirmed case studies including exposed Bearer tokens, propagated API keys and plaintext authentication credentials.

How it works

The detection problem is harder than ordinary taint analysis for two reasons the paper addresses directly.

First, MCP servers are written in many languages — Python, TypeScript, Go and others — so a single-language analyzer misses most of the ecosystem. MCPPrivacyDetector lifts these heterogeneous codebases into a unified program representation so the same analysis logic applies regardless of source language.

Second, the dangerous “sinks” are not the usual ones. A standard tool looks for network or file-write sinks. Here the sinks are protocol-specific and implicit: the return value of a tool handler, a logging statement, an error object surfaced to the caller. The framework encodes these as sinks, applies context-aware semantic filtering to separate genuinely sensitive values (tokens, keys, PII) from benign strings, and then runs taint analysis to enumerate feasible flows from a sensitive source to one of those implicit sinks.

Sensitive source            Implicit MCP sink            Result
─────────────────           ──────────────────           ──────
env var / secret store  ──►  tool handler return    ──►  value reaches the LLM context
config credential       ──►  log statement          ──►  value written to shared logs
auth token              ──►  exception / error msg  ──►  value raised back to caller

No exploit code is published; the contribution is a measurement study plus a detector. This is the same “the channel defenders inspect least” pattern seen in prompt injection through file metadata and in taint-style server flaws across the MCP ecosystem — the difference is that the leaking path here looks, in the source, like completely normal tool behaviour.

Why it matters

MCP servers routinely run with real secrets: the whole point of a tool is to authenticate to a database, a SaaS API or an internal service on the model’s behalf. When those secrets flow into handler outputs, logs or errors, they become readable by the model — and, through it, by whatever the model is exposed to. Combine that with a model that also sees untrusted content and can act externally and you have the classic lethal trifecta: a leaked token in a tool response is one indirect injection away from being exfiltrated.

The scale is the story. A >10% leakage rate across more than ten thousand servers is not a handful of misconfigured deployments; it is a structural property of how MCP servers are being written today, echoing the broader picture of MCP backend vulnerability patterns and earlier single-server incidents like the Splunk MCP token leak. Because the leak has no explicit outbound call, it also slips past code review and many secret-scanning passes that key on network sinks. This class sits squarely in OWASP LLM02, Sensitive Information Disclosure.

Defenses

The unifying principle is to treat anything a tool handler returns, logs, or raises as data that will reach the model, and therefore as an outbound channel.

Separate secrets from tool output. A handler should return only the result the model needs, never the credential it used to obtain that result; keep tokens and keys in a layer the model never sees. Redact before returning: filter handler return values, log lines and error messages for high-entropy strings and known secret formats, so an exception can’t ship a Bearer token to the caller. Scope credentials tightly so a leaked one is low-value and short-lived, and rotate on any suspected exposure — the same credential-leakage discipline urged for agent skills. Run static analysis of the kind this paper demonstrates in CI, checking specifically for flows into protocol sinks rather than only classic network sinks. And align the deployment with published guidance: the NSA’s June 2026 MCP security design considerations and the mitigations mapped in the broader agent data-privacy work both stress strict output validation and least-privilege boundaries between an agent and its context providers.

Status

Item	Detail
Disclosure	arXiv preprint 2606.21338, late June 2026 (measurement study + detector)
Nature	Protocol-induced leakage of secrets/PII via MCP tool-handler returns, logs and error messages
Detector	MCPPrivacyDetector — cross-language static analysis + context-aware semantic filtering + taint analysis to implicit MCP sinks
Scale	10,655 real-world MCP servers scanned; leakage found in >10%; confirmed Bearer tokens, API keys, plaintext credentials
Affected	MCP server implementations handling secrets (language- and model-agnostic)
Class	OWASP LLM02 — Sensitive Information Disclosure

Findings reflect the cited study. A static analyzer reports feasible flows, not confirmed live exposures — validate flagged paths against your own deployment before drawing conclusions about a specific server.