Your Coding Agent Can Delete Any File on Disk

Picture this. You ask your coding agent to “tidy up the config files.” It interprets that broadly. It overwrites .env with what it thinks the defaults should be. It moves docker-compose.yml into a subdirectory that doesn’t exist yet. It edits your SSH config. Fifteen seconds, twelve tool calls, and your local environment is wrecked. The agent didn’t go rogue — it did exactly what it thought you wanted, with tools that let it do anything.

12 tools, zero restrictions

The filesystem MCP server is one of the most popular MCP servers in the ecosystem. It ships 12 tools:

Read tools — read_text_file, read_multiple_files, read_media_file, list_directory, list_allowed_directories, get_file_info, search_files, directory_tree

Write tools — write_file, edit_file, create_directory, move_file

Out of the box, every one of those tools is unrestricted. An agent can call write_file a thousand times in a minute. It can move_file your entire project structure into a flat directory. There’s no throttle, no confirmation step, no limit of any kind.

The read tools are relatively safe — an agent scanning your codebase is doing its job. The write tools are where things go sideways. A single rogue loop calling write_file can overwrite dozens of files before you notice. And unlike a database, your local filesystem has no rollback button.

Rate limiting file writes

Intercept sits between your agent and the filesystem server, enforcing a YAML policy on every tool call. Here’s what the filesystem policy looks like:

version: "1"
description: "Policy for modelcontextprotocol/server-filesystem"
default: "allow"
tools:
  # Read tools — no restrictions
  read_text_file:
    rules: []
  read_multiple_files:
    rules: []
  list_directory:
    rules: []

  # Write tools — rate limited
  write_file:
    rules:
      - name: "rate-limit-writes"
        rate_limit: "30/hour"
        on_deny: "Rate limit: max 30 file writes per hour"
  edit_file:
    rules:
      - name: "rate-limit-writes"
        rate_limit: "30/hour"
        on_deny: "Rate limit: max 30 file edits per hour"
  move_file:
    rules:
      - name: "rate-limit-moves"
        rate_limit: "15/hour"
        on_deny: "Rate limit: max 15 move/rename operations per hour"
  create_directory:
    rules:
      - name: "rate-limit-writes"
        rate_limit: "30/hour"
        on_deny: "Rate limit: max 30 directory creations per hour"

  # Global safety net
  "*":
    rules:
      - name: "global-rate-limit"
        rate_limit: "120/minute"
        on_deny: "Rate limit: max 120 tool calls per minute"

The logic is straightforward. Read operations pass through freely. Write operations are capped at 30 per hour. Moves are tighter at 15 per hour — because renaming or relocating files is harder to undo. And a global rate limit of 120 calls per minute catches runaway loops regardless of tool type.

These are deterministic policies, not prompt-based suggestions. The agent doesn’t get to negotiate. When it hits the limit, the call is blocked at the transport layer and never reaches the filesystem server. The agent receives the on_deny message and can adjust its approach.

Getting started

Install Intercept and generate the filesystem policy:

# Install
npm install -g @policylayer/intercept

# Generate the policy
intercept scan -- npx -y @modelcontextprotocol/server-filesystem /path/to/allowed/dir

The scan command connects to the filesystem server, discovers all 12 tools, and generates a policy YAML with sensible defaults — the same one shown above. Edit the limits to match your workflow. If you’re doing a large refactor, bump write_file to 100/hour. If you’re running an agent overnight, drop it to 10.

Then run with enforcement:

intercept -c filesystem.yaml -- npx -y @modelcontextprotocol/server-filesystem /path/to/allowed/dir

Every tools/call now passes through the policy engine. Reads flow through. Writes are counted. Limits are enforced. Your filesystem stays intact.

The policy file is just YAML — version it alongside your code, share it across your team, adjust it per project. No SDK integration, no code changes, no runtime dependency in your agent.

Full filesystem policy →