First-hand information for everyone
A team of security researchers has identified and measured a new class of privacy and security risk that can arise when AI agents call out to external tools. In a large-scale study of servers that implement the Model Context Protocol (MCP) — a growing standard for how models invoke tools and services — the researchers demonstrate how a tool that appears harmless to a user can nonetheless be guided, by attacker-influenced inputs, to read sensitive files on the host system.
What the researchers call “filesystem capability laundering” happens when three things align. First, the server process that executes a declared tool has ordinary host filesystem permissions. Second, an argument passed to the tool can be influenced by untrusted content (for example, via prompt injection into the agent). Third, the tool’s implementation fails to constrain which file paths it actually reads or writes. The result: an apparently benign tool call can return the contents of files the tool was never intended to touch, such as SSH private keys or other credentials.
The study is careful and empirical. The authors built MCP-FSD, a pipeline that (1) crawls public MCP registries and collects server source code, (2) applies lightweight static checks to find tool handlers and path-shaped parameters, (3) infers a conservative “least-privilege” filesystem hypothesis for each tool, and (4) runs controlled dynamic tests that try to reproduce a real disclosure while also verifying whether a sandboxed policy would have prevented it.
Key measurements and findings
- Corpus and triage: The team cataloged 21,097 MCP listings from nine registries and attempted to run locally available, open-source servers. From 4,806 triaged servers, automatic screening flagged 787 servers (16.4%) that appeared to have filesystem-facing behavior despite not being labeled as filesystem services.
- Static signals: Across flagged repositories, the most common static problems included missing path validation and flaws that can be bypassed by crafted path strings or symlinks.
- Dynamic confirmation: Using a three-case validation protocol, the researchers confirmed 150 instances where a crafted sequence of calls could return the contents of a planted “credential” fixture from outside the tool’s intended scope. The three-case protocol first demonstrates the leak on an unconfined process, then shows that normal in-scope operations still work under a proposed sandbox, and finally shows that the same malicious payload is blocked when that sandbox is applied.
- Coordinated disclosure: The authors reported 13 findings to affected projects; two of those reports led to Common Vulnerabilities and Exposures (CVE) entries for Anthropic’s Git MCP Server. The disclosed issues included an unscoped repository creation endpoint (git_init) and a staging operation (git_add) that could stage files outside the repository root and later expose them via a diff.
Why this matters
MCP is becoming a standard glue layer for agent tool use. When an agent asks “should I run X?” the user or client usually approves based on the tool’s declared contract (name, description, argument schema). That approval does not, however, automatically restrict what the server process is allowed to access at the filesystem level. As AI systems increasingly orchestrate many local tools, the gap between the declared contract and the server’s actual host privileges becomes a meaningful attack surface.
Practical takeaways and mitigations
- Developers should apply canonical path containment and always validate that path-shaped arguments stay inside the intended workspace. That includes correctly resolving symlinks and avoiding brittle prefix checks.
- Language SDKs for MCP should offer and encourage standard containment helpers, which is especially relevant in ecosystems where no common primitive currently exists.
- At the protocol level, MCP could be extended to advertise per-tool filesystem expectations (a machine-readable fs_scope). Clients could display that scope before asking for approval, and servers could be launched with kernel-enforced sandboxes that limit filesystem access to the stated roots.
- Operating-system process isolation (sandboxing) proved effective in the study when correctly configured: the team’s three-case tests showed sandboxes that preserve benign functionality while preventing the confirmed disclosures.
Limitations and cautions
The researchers are explicit about what their measurements do and do not show. Their dynamic tests only exercise servers that can be installed and run locally, so the results describe that runnable subset rather than the entire MCP ecosystem. The inferred least-privilege boundaries are hypotheses based on available signals (launch configuration, schemas, source code and descriptions) and can be imperfect: a policy that is too strict might break legitimate behavior, while one that is too permissive might miss violations. The study focuses on disclosures where file contents appear in tool responses; other unauthorized write or state-modification attacks are harder to detect and were not systematically measured here. Several analysis steps also used large language models to help identify candidates and draft policies; those heuristics can make mistakes and warrant human review.
Responsible conduct
To avoid real-world harm, the researchers used planted test fixtures rather than real secrets and ran experiments on controlled installations. They followed coordinated-disclosure practices, and the affected projects were notified so fixes could be issued.
Bottom line
This work highlights a practical mismatch that can arise when AI agents are allowed to use external tools: approving a tool call implicitly trusts the server process, but that trust does not always match the narrow operation the tool was meant to perform. The paper provides reproducible tooling, concrete examples (including two patched CVEs), and sensible mitigation guidance: require canonical containment, add standardized SDK helpers, and use sandboxing to enforce least privilege. As agentized workflows spread, those safeguards will help keep tool calls from accidentally becoming a channel for exfiltrating host credentials.