How can an approved AI tool read files it never declared?
A large preprint found 150 dynamically confirmed MCP-server instances that could reach beyond an inferred filesystem boundary. The audit used planted secrets, not evidence of real-world theft.
The short version
- What happened
- Researchers catalogued 21,097 MCP-server listings across nine registries, but only 4,806 successfully run, triaged servers formed the final measurement snapshot.
- Who it affects
- Developers and staff using local AI tools can expose files through the server process even when the approval prompt describes a narrower action.
- What remains unproven
- This is an unreviewed, selectively runnable open-source corpus. The 16.4% figure is a screening rate, not the prevalence of exploitable MCP servers, and inferred permission boundaries were not independently benchmarked.
Keep in mind
This is an unreviewed, selectively runnable open-source corpus. The 16.4% figure is a screening rate, not the prevalence of exploitable MCP servers, and inferred permission boundaries were not independently benchmarked.
Source analysis · 1 linked source. Primary analysed source date: 15 October 2026.
Read the full report · 4 min The evidence, methods, implications and limitations
A harmless-looking tool can inherit the whole process's access
Approving an AI tool call does not necessarily confine the software behind that tool to the operation described on screen. A new security audit found 150 dynamically confirmed instances in which locally run Model Context Protocol servers could reach beyond an inferred filesystem boundary. The researchers call the gap ‘filesystem capability laundering’: a narrow tool contract masks broader access held by the server process.
For a developer or organisation running agents locally, the practical risk is that untrusted content could steer an apparently ordinary argument toward a credential or other sensitive file. The paper does not report stolen real-world credentials. Tests used planted secret strings in controlled installations, and 13 selected findings went through coordinated disclosure, including two CVEs involving Anthropic's Git MCP Server.[1]
The audit separated screening from proof
The team began with 21,097 server listings from nine registries. Of 7,222 local open-source servers selected for measurement, 4,806 reached the final triage snapshot; 97% were Node or Python projects and one registry supplied 84% of successful starts. Among the triaged set, 787—or 16.4%—showed a filesystem capability despite not being classified as a filesystem server. That is a screening signal, not a vulnerability rate.
Confirmation required three executions. First, an unsandboxed malicious argument had to expose a planted credential or produce another adjudicated out-of-scope effect. Second, a benign in-scope operation had to work inside the inferred sandbox. Third, replaying the malicious case inside that sandbox had to block disclosure. All 150 confirmed instances passed that gate; 136 used exact marker matching and 14 relied on other transcript or write evidence. In separate hand-labelled samples, two static classifiers reached about 97.8% micro-averaged precision and recall, but the broad server-category screen had no independent accuracy benchmark.[1]
The distinction that matters
How the three-case security test worked
A finding counted only when exploitability, normal function and containment could be distinguished.
Exploit test
Run a malicious out-of-scope argument without isolation
Planted secret or other adjudicated effect appears
Benign test
Run the intended operation inside the policy
Normal tool function still succeeds
Containment test
Replay the malicious case inside the policy
Sensitive content is not disclosed
What users and tool builders should take from it
The result supports controls below the chat approval layer: canonical path checks, symlink-safe validation, per-tool read and write scopes, and operating-system isolation for the server process. It does not mean every flagged tool is malicious. The pipeline cannot run every server, may miss effects that never appear in a response, and does not independently measure whether each inferred boundary precisely matches the developer's intended permissions. Nor did it systematically test destructive writes or discover every possible chain between two tools.
Several stages also used language-model judgements, and the paper gives no funding or competing-interests statement in the accessible version. A stronger ecosystem estimate would use expert-labelled permission boundaries across more registries and languages, then test unauthorised writes and multi-tool chains systematically under diverse, reproducible deployment configurations. Until then, the clearest operational lesson is modest: approve the named action, but enforce the server's actual filesystem reach separately.[1]