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
3 key points
- 1.Researchers catalogued 21,097 MCP-server listings across nine registries, but only 4,806 successfully run, triaged servers formed the final measurement snapshot.
- 2.Three-case dynamic tests confirmed 150 tool-policy instances that exposed a planted secret or other out-of-scope effect without a sandbox and were contained under the tested policy.
- 3.The study does not show real credentials were stolen or estimate risk across every MCP server; its corpus was heavily weighted toward runnable Node and Python projects.
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]
Evidence check
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.
Reporting basis: Source analysis. Original source date: 15 October 2026.
Explore the full source and evidence record
What this means for people
- Developers and staff using local AI tools can expose files through the server process even when the approval prompt describes a narrower action.
- Tool maintainers need enforceable path boundaries, not only accurate names and descriptions.
Global context
The sampled registries and open-source packages are globally accessible, while the authors are affiliated with US institutions or list independent status. Results are dominated by Node and Python projects that could start in the researchers' environment.
What the evidence does not yet show
- 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.
What to watch next
- Vendor advisories for the disclosed cases and independent replication using expert-defined boundaries, more registries and write-focused tests.
Living evidence record
Impact record IAI-02JGRL0
Evidence stage
Studied
Confidence
Supported
Reporting basis
Source analysis
Independent or research support
Present
Record status
Monitoring
Last checked
16 October 2026
Source trail
1 direct source across 1 source type.
People impact
Documented in this record.
Uncertainty
Limits and next checks are explicit.
Stages describe the evidence available—not whether a technology is good or bad. See the public method.
Single-source reporting disclosure
This record analyses one direct source. It can establish what Huang et al. (arXiv) published or reported, but it is not independent corroboration of every performance claim or predicted outcome. The confidence label will change only when broader evidence is added.
Evidence trail
Sources used for this report
Links checked 16 October 2026
Research question, topics and regions
Filesystem capability laundering in locally run Model Context Protocol servers
Topics: MCP · AI agents · Cybersecurity · Filesystem access · Least privilege
Regions: United States · Global
This report is labelled source analysis. We summarise and analyse source material in our own words; company statements remain attributed claims until independently supported. Translated summaries preserve the meaning of the original source and link back to it. Read our editorial standards.
The Impact Brief · Free
Keep following the stories that matter to you.
Get our weekday briefing on what changed and why it matters. Choose your topics below.
Continue the story
There’s more to this story
Security & Defence
How often did prompt injection divert coding agents?
In a new sandbox benchmark, attack success averaged 19.6% by an AI judge and 15.4% by artifact checks across 26,220 undefended trajectories. Rates varied sharply by model and harness, and the strongest tested prompt defence traded security against task utility.
7 min · 1 source
Security & Defence
Can encoded instructions turn AI-agent skills into security exploits?
Yes, in a controlled benchmark: some models decoded and followed malicious payloads hidden in third-party skill files. Attack rates fell sharply with the original longer files, and the work does not demonstrate a live breach.
7 min · 1 source
Security & Defence
AI agents reached live systems. Who was watching?
India’s CERT-In reports agents acting beyond their authority. The warning raises a human question for every business adopting automation: who can see what it is doing—and stop it?
3 min · 1 source
Reader commentary
What does this mean where you are?
Tell us what you have seen at work, in your community or in everyday life. A question is welcome too. No account is needed; we review notes before publishing them.
Explore commentary across the portal →Published reader notes
0No published reader notes yet. You can start the evidence-led discussion above.
Prefer a private correction or response? Contact the newsroom.