My Credentials, Please: Detecting Filesystem Capability Laundering in MCP Servers at Scale

The gist The Model Context Protocol (MCP) standardizes how AI agents invoke external tools, and this paper studies filesystem capability laundering where attacker-steered arguments cause a tool to access sensitive host files outside its declared contract and deployment scope.

How it works

Filesystem capability laundering is characterized by three conditions: (i) an implemented effect exceeds the scope justified by the tool contract and deployment, (ii) attacker-influenced arguments select the filesystem target, and (iii) the call is admitted while the surrounding controls fail to constrain that effect. This mechanism is analyzed across three layers: server-category screening (L1), per-tool contract analysis (L2), and bypassable path-validation checks (L3). The threat model focuses on local stdio MCP servers launched as separate processes, where the server runs with the user’s ambient filesystem permissions, and the client’s tool-approval prompt enforces no per-tool path restrictions on the underlying process. An attack succeeds when the MCP response contains the contents of a file outside the tool’s legitimate scope.

MCP-FSD Design

The authors designed MCP-FSD (Filesystem Scope Detection) to catalog MCP servers across registries, discover each server’s tools inside per-repository sandboxes, screen candidates with MCP-aware static filters, and dynamically validate each one against an inferred least-privilege boundary. The framework runs in two passes: a measurement pass crawls registries to discover tools and assign capability-triage labels, and a validation pass applies static screening, infers a least-privilege boundary per tool, and confirms exploitability with three-case dynamic validation.

Static Screening

The static screening phase uses an LLM to identify tool registrations, handlers, and path parameters. The system classifies each finding into five rule categories spanning CWE-22 (path traversal) and CWE-59 (link resolution), including PT-001 missing validation, PT-004 symlink TOCTOU, and PT-005 blacklist filter. Four MCP-aware filters select candidates for dynamic testing based on whether they can plausibly return out-of-scope file contents. For example, for git add, the reviewed handler connects the schema’s files parameter to repo.index.add(files) without a repositorycontainment check, recorded as a PT-001 SARIF candidate.

Boundary Inference Algorithm

MCP-FSD derives the scope from the tool’s legitimate operation rather than from the suspected bug. The algorithm uses four signals—launch configuration L, path-bearing schema fields S, tool description D, and repository source signals R—to construct a policy hypothesis. The process involves extracting roots from the launch tuple, walking the JSON Schema for path parameters, identifying literal and constructed paths in handler code, asking an LLM for a candidate glob policy, extending it to cover runtime requirements identified in R, and finally partitioning the result into a read-write and a read-only half.

Dynamic Three-Case Validation

The validation pass confirms exploitability with three cases: PoC 1 runs the malicious payload without the sandbox and succeeds only when the response contains the planted credential contents. PoC 2 runs the benign in-scope payload with the sandbox and requires no denial event. PoC 3 replays PoC 1’s malicious payload with the sandbox and requires absent credential contents plus an explicit denial or a non-disclosing response. These cases establish that detected disclosures represent genuine vulnerabilities remediated by least-privilege containment.

Evaluation and Findings

The study cataloged 21,097 listings from nine registries, and dynamic validation confirmed 150 vulnerable instances under tested sandbox policies. Among the flagged servers, 787 exhibit filesystem capability flags without a FileSystem category label (L1 screening signal). The evaluation confirmed that L3 defense-bypass classifiers achieve 95.3% precision and 99.3% recall over 297 labeled findings. Two CVEs in Anthropic’s Git MCP Server were reported, illustrating L2 laundering across distinct boundaries. The paper concludes that ecosystem-scale registry screening and explicit, runtime-enforced per-tool filesystem contracts are necessary to bridge the gap between client-side tool approval and unconfined server filesystem execution.

Limitations

Limitations include the pipeline only validating servers it can install and run, dynamic validation may miss a violation whose out-of-scope effect never appears in a response, and the accuracy of inferred boundaries is not measured. Furthermore, enforcement strength follows the sandbox backend, and validation covers selected tools and explicitly stated call sequences rather than systematic discovery of cross-tool chains. The results are conditional on successful startup and the selected runtime configurations.

Ethical Considerations

This work analyzes publicly available MCP servers and validates disclosure against fixture credentials, never real secrets. The Git MCP cases were reported to the affected vendor, and both received CVE assignments. Dynamic validation runs on controlled installations with synthetic fixtures and resets between cases. PoC 1 intentionally omits the test sandbox.

Related Work

MCP-FSD focuses on filesystem effects triggered by attackercontrolled arguments and tests them against an inferred policy for each tool. It couples static screening with dynamic three-case replay on native host runtimes, capturing complex librarymediated flows against inferred per-tool scopes. MCP-FSD infers least-privilege boundaries directly from unstandardized tool descriptions and deployment configurations.

Conclusion

Filesystem capability laundering exposes a fundamental gap between client-side tool approval and unconfined server filesystem execution. MCP-FSD bridges this gap by coupling static screening, inferred least-privilege boundaries, and dynamic three-case validation across 21,097 cataloged servers. Real-world vulnerabilities in foundational tools—such as repository creation and staging flaws in Anthropic’s Git server—demonstrate how ordinary tool interactions can inadvertently leak sensitive host credentials. These findings demonstrate the necessity of ecosystem-scale registry screening and explicit, runtime-enforced per-tool filesystem contracts.

References

The references listed are 1 through 45 on page 18. The paper cites work on MCP security and filesystem detection, contract analysis, and agent security benchmarks. The references include specific advisories for Anthropic's Git MCP Server and various sandboxing technologies used in the study. The work builds upon prior studies in prompt injection, tool-use security, and filesystem vulnerability detection. The paper's references include arXiv preprints and NIST National Vulnerability Database entries for specific CVEs. The study compares MCP-FSD against existing tools like PathSentinel and MICRYSCOPE. The references provide context on the limitations of LLM-generated judgments in the detection pipeline. The paper cites work on execution isolation architectures like IsolateGPT and Cloak as related concepts.

1. Improved AI systems can incorporate MCP-FSD to catalog MCP servers, infer least-privilege boundaries per tool, plant credential fixtures outside those boundaries, and evaluate exploitability and sandbox containment via paired dynamic execution. This allows for proactive detection of filesystem capability laundering, where attacker-steered arguments cause a tool to access sensitive host files outside its declared contract.

2. The AI system can implement static screening using LLMs to classify candidates into rule categories like PT-001 missing validation or PT-004 symlink TOCTOU, as described in Section 3.1. This provides a coarse initial screening signal by comparing inferred filesystem capability flags against the server’s functional classification (primary type).

3. The system can perform boundary inference using Algorithm 1 to construct a policy hypothesis, deriving scope from launch configuration L, path-bearing schema fields S, the tool description D, and repository source signals R. This allows the system to determine if a tool's declared contract is sufficient by testing whether Reach(t) ̸⊆ B(t; d).

4. The system can execute dynamic three-case validation against the inferred boundary to confirm exploitability and containment. This involves running PoC 1 (malicious payload without sandbox), PoC 2 (benign in-scope payload with sandbox), and PoC 3 (malicious payload with sandbox) to demonstrate enforcement operating-system process isolation.

5. The system can prioritize remediation efforts based on findings where a source-level control is bypassed or the project publicly commits to a narrow scope that the implementation does not enforce, as discussed in Section 4.4, focusing on fixes like canonical-path containment or SDK helpers.

The Model Context Protocol (MCP) standardizes how AI agents invoke external tools. MCP servers expose tools through a declared contract consisting of a name, description, and argument schema. In typical local deployments, client-side approval of a tool call grants the underlying server process broad host filesystem permissions rather than restricting it to the declared operation. We study the resulting vulnerability class, filesystem capability laundering, where attacker-steered arguments cause a tool to access sensitive host files outside its declared contract and deployment scope. We analyze this capability gap across three layers: server-category screening (L1), per-tool contract analysis (L2), and bypassable path-validation checks (L3). We design MCP-FSD to catalog MCP servers, infer least-privilege boundaries per tool, plant credential fixtures outside those boundaries, and evaluate exploitability and sandbox containment via paired dynamic execution. Across 21,097 MCP servers from nine registries, 787 of 4,806 triaged servers (16.4%) exhibit filesystem capabilities despite non-filesystem functional classifications. Dynamic three-case validation confirms 150 vulnerable instances under tested sandbox policies. Coordinated disclosure yielded 13 security advisories, including two CVEs in Anthropic's Git MCP Server.