The report
An MCP tool may say it reads a repository file while its server process can read a much wider directory tree. A new MCP-FSD study tested this difference with isolated filesystem probes and planted credentials, finding 150 reproducible boundary violations in selected runnable servers. In 136 cases, a tool response contained the exact synthetic secret marker. These were experimental markers, not customer credentials recovered from the internet.
A listing is not a vulnerable deployment
The researchers collected 21,097 registry listings across nine registries, then screened 4,806 for capability signals. They flagged 787 entries whose descriptions suggested filesystem behavior without an obvious filesystem category. This 787 figure is a discovery filter. It is not a prevalence estimate for production exploits, nor the count of successfully abused installations.
The team then executed a narrower set of runnable servers with synthetic files placed beyond the intended boundary. Confirmed outcomes comprised 150 out-of-scope effects, including 136 cases in which tool output revealed a marker. The other 14 had different boundary effects. The study did not demonstrate that a deployed language-model agent had independently discovered and exploited each one, or that the servers were publicly reachable under customer configurations.
How a legitimate Git operation crossed the line
A previously patched Git MCP defect gives a concrete example. The server offered Git staging as an agent-facing operation, but its GitPython path handling could accept a file outside the intended repository. That content could enter Git's local object store and appear in later Git outputs. Staging itself is not proof of a network exfiltration; a subsequent operation or disclosure channel is needed for that claim. The patched 2026.1.14 version uses Git CLI path handling that rejects out-of-repository files.
This makes the difference between tool semantics and process permissions inspectable. A schema-valid path is not automatically inside the workspace. A model being authorized to call git_add does not imply that its server is entitled to open unrelated home-directory secrets. The semantic filesystem-boundary concept separates these layers and their controls.
What should be measured next
A strong evaluation would replay these arguments through actual MCP clients and pinned server versions, then compare behavior with restricted process identities, resolved-path checks and explicit workspace containment. It should preserve both safe Git operations and failures in the test population. The central evidence here is a verified implementation boundary problem, not an estimate of real-world agent-driven secret theft.