Filesystem MCP Server Tool Risk: Ranking read_file, write_file, edit_file and move_file

How the ranking works

Teams connecting agents and coding assistants to a Filesystem MCP server often apply one control to every tool, or none. A ranking makes the decision explicit. We score each tool against five criteria: confidentiality exposure, integrity and tampering impact, reversibility, blast radius, and susceptibility to prompt injection or path traversal.

OWASP's AI Agent Security Cheat Sheet gives an illustrative baseline: read_file as LOW, write_file as MEDIUM, higher-impact actions such as send_email and execute_code as HIGH, and unmapped tools defaulting to HIGH so the system fails closed. The example does not cover edit_file or move_file, and it is a code example rather than a standard. We use it as a reference point only. The placement of edit_file and move_file below is our own analysis.

Two principles from the same guidance shape how to use any ranking. A risk classification is an input to policy, not a grant of permission. And the component that executes the call must still check the actor's authorization and any required approval for that exact action.

Filesystem MCP server risk table

Each row lists the main risk drivers, an example misuse scenario and a suggested default policy treatment. Treat the treatments as drafts to adjust for your allowed directories and data classes.

• write_file | Highest: Drivers: arbitrary content, can create new files or replace existing ones depending on server behavior, hard to reverse without backups. Misuse: injected instructions cause a script, CI definition or configuration file to be written. Policy: block in sensitive directories, escalate for human approval elsewhere outside a designated work area, rate limit.
• edit_file | High: Drivers: modifies existing trusted files, small changes are easy to miss in review, tampering looks like normal development. Misuse: a one-line change to a dependency, permission or endpoint setting. Policy: allow in narrow scoped paths, escalate for configuration, build and security files, retain before and after state.
• move_file | Medium to high: Drivers: two paths to evaluate, can displace files that other systems depend on, can place data in a location with weaker access control. Misuse: a sensitive file moved into a shared or synced folder, or a file renamed to disrupt a process. Policy: evaluate source and destination together, block moves across directory boundaries, escalate the rest.
• read_file | Low to medium, path dependent: Drivers: confidentiality exposure, content returned to the model can be passed to other tools, disclosure is irreversible. Misuse: injected instructions direct the agent to read credentials, then send them onward. Policy: allow in scoped directories, block credential and key paths, redact secrets in returned content, rate limit.

How each tool fails

The common failure is not a flaw in one tool but the authority the server holds. OWASP describes the confused deputy problem, where an MCP server acts with its own, often broad, privileges rather than the requesting user's. It also describes sandbox escapes, where a local server with full host access enables file system traversal and credential theft. Any filesystem tool inherits these conditions, which is why allowed directories and least-privilege credentials matter as much as the tool ranking.

Prompt injection supplies the intent. Repository content such as issues, READMEs, changelogs and error traces becomes instruction when an agent reads it, and so can tool responses. The agent then calls a legitimate tool with attacker-chosen arguments. Path traversal and similar tricks target the argument itself, so the policy decision has to evaluate the resolved path, not only the tool name.

Chaining raises the stakes. OWASP notes that MCP risk is amplified by chained tool calls, where one tool's output feeds another. For filesystem tools the obvious chain is read then write, or read then move. Each call may look acceptable alone. A read_file ranked low can be the first step of an exfiltration or tampering sequence, which is why path scope belongs in the ranking and not only the tool class.

Tool definitions are also a surface. A server that looks benign when approved can later change its tool metadata and steer a connected agent toward sensitive local files, without the server reading them itself.

Enforcing policy in the execution path versus reviewing afterwards

Reviewing activity after the fact tells you what happened. It cannot stop a write_file call that has already replaced a file or a read_file call that has already returned a secret. For tools where the damage is not reversible, the decision has to be made before execution, by the component that runs the call.

That component should fail closed on unknown tools and check the actor's authorization for the exact path and operation. Where approval is required, a simple user_confirmed flag is insufficient. Bind the approval to the current actor and the exact tool call, including the path. Give it a validity window and make it single use, so it cannot be reused for a different call.

Pair this with supply-chain controls. Snapshot tool definitions at approval and require re-approval on change. Run local servers sandboxed and isolated, give each server the minimum permissions it needs, and add AI coding-tool configuration directories to file-integrity monitoring. Review new MCP servers with the same controls used for other software dependencies.

The tradeoff is friction. Escalating every write will push users to bypass the system, so reserve human approval for the rows and paths where reversibility is poor and use rate limits and scoped allow rules elsewhere.

Where Trussed fits

Trussed enforces policy in the execution path for tool calls, including calls to MCP servers. For filesystem tools, each read, write, edit or move can be allowed, redacted, blocked, rate limited or escalated for human approval at runtime, not reviewed after the fact. That enforcement generates continuous, audit-ready evidence mapped to frameworks including HIPAA, NAIC, NYDFS, the EU AI Act and NIST, so a regulated enterprise can show what an agent was permitted to do and what it did. Trussed can be self-managed in the customer cloud, with configurable retention and data residency.

The ranking and table above stand on their own. They can be applied with any enforcement point that sits in the execution path.