MCP servers grant filesystem access their contracts do not declare
A research paper posted to arxiv.org describes how AI agents invoking tools through the Model Context Protocol can access host files beyond what the tool's declared contract permits. The paper, titled "My Credentials, Please: Detecting Filesystem Capability Laundering in MCP Servers at Scale", explains that client-side approval of a tool call grants the server process broad host filesystem permissions rather than restricting it to the declared operation, enabling a vulnerability class called filesystem capability laundering where attacker-influenced arguments steer tools to sensitive files.
The Model Context Protocol standardizes how AI agents invoke external tools. An MCP server implements tools that a client discovers through tools/list and invokes through tools/call. The tool’s name, description, and argument schema form its declared contract. However, the MCP specification delegates per-tool filesystem enforcement entirely to individual server implementations or host environments. In typical local deployments, while the client’s approval prompt gates execution based on declared arguments, the spawned server process executes with ambient host filesystem permissions. An ostensibly benign operation can therefore access and expose host credentials through ordinary tool output. The researchers call this vulnerability class filesystem capability laundering: an out-of-scope filesystem capability is exercised under the guise of an innocuous tool contract.
To study this gap, the researchers designed a three-layer analysis. At the server-category layer (L1), they compare inferred filesystem capability flags against the server’s functional classification (primary_type); non-filesystem servers such as memory or code development tools often perform legitimate local persistence, so category mismatches serve as coarse screening signals. At the tool-name layer (L2), a tool’s narrow operation can reach files beyond its intended scope: for example, git_add can stage an out-of-repository file whose contents a later diff returns. At the defense-bypass layer (L3), an existing path check can be defeated: the Filesystem MCP Server’s string-prefix check admitted sibling directories sharing the allowed prefix.
The researchers built 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.
The system involves an MCP server that publishes a tool contract, a client that discovers and invokes the tool, and a host environment that runs the server process. During discovery, the server advertises a contract such as "I offer git_add, which stages files in a repository." During invocation, the client sends arguments, the user approves based on the contract, and the server process runs with ambient host permissions. The contract does not constrain the execution environment; the specification leaves per-tool filesystem enforcement to server implementations or host environments.
The design decision that enables this outcome is the protocol’s choice to treat the server as a trusted execution environment rather than a capability-bearer with bounded authority. The MCP specification defines schemas and annotations for the declared contract but does not mandate that the host operating system restrict the server process to files matching the declared scope. As a result, a server that claims to operate only on a repository can, at execution time, receive a path argument that escapes that repository, and the host filesystem will permit the access because the server process holds broad permissions.
The trade-off is between protocol simplicity and execution safety. By not specifying sandboxing, MCP keeps server implementation lightweight and deployment flexible. Server authors need not negotiate with host sandbox mechanisms; hosts need not implement per-tool isolation. The cost falls on users, whose client-side approval of a tool call grants more authority than the contract describes. The user sees "approve git_add on repo/file.txt" but the server process can read /etc/passwd or ~/.ssh/id_rsa if the argument is crafted to do so.
In the L2 case, the git_add tool’s contract describes staging files within a repository. However, git_add can be steered to stage a file outside the repository; a subsequent git_diff returns the contents of that file through ordinary tool output. The attacker never breaks a sandbox; the tool’s legitimate operation, applied to an argument outside its intended scope, produces an information leak. The contract described a bounded operation; the execution environment did not bound it.
In the L3 case, the Filesystem MCP Server attempted to restrict paths to those sharing an allowed prefix via a string-prefix check, but the check admitted sibling directories with the same prefix. A path validation written at the application layer, without operating-system enforcement, failed because the check was incomplete and the process permissions were not restricted to match.
The incentive structure rewards server authors for functionality over isolation. A server that can read and write broadly is easier to implement and more flexible to deploy. The host environment, typically the user’s own machine, does not enforce least privilege because the protocol does not require it and the operating system defaults to user-level permissions. The user, presented with an approval prompt based on the contract, lacks information about the gap between contract and execution.
A system that separates descriptive contracts from execution permissions, without mandating that the execution environment enforce the contract, will permit capability laundering when arguments are attacker-influenced and the server process holds ambient permissions. The fix—strict sandboxing that restricts the server process to files matching the declared scope—requires host cooperation that the protocol currently does not demand.