daBongo LMS AI Training Courses

Model Context Protocol – Advanced Patterns for Production

Lesson 3: File System Access and Security Boundaries

Lesson Objectives

By the end of this lesson, students should be able to:

  • Implement file system tool/resource access with path restrictions
  • Prevent path traversal attacks in file system handlers
  • Configure the minimum necessary file system permissions for a server
  • Apply the principle of least privilege to MCP file system access

Lesson Content

The file system access risk.

An MCP server with file system access can read and write files on the host system. Without path restrictions, a server that accepts a path parameter from Claude's tool call can be used (via prompt injection) to read or write any file the server process can access – including credentials, configuration files, and sensitive data.

Path restriction implementation.

Every file system tool must validate that the requested path is within the allowed root:

“`python import os from pathlib import Path

ALLOWED_ROOT = Path("/allowed/directory").resolve()

def validate_path(requested_path: str) -> Path: resolved = (ALLOWED_ROOT / requested_path).resolve() if not str(resolved).startswith(str(ALLOWED_ROOT)): raise ValueError(f"Path {requested_path} is outside allowed root") return resolved

@app.call_tool() async def call_tool(name: str, arguments: dict): if name == "read_file": path = validate_path(arguments["path"]) # validates before any file access return [types.TextContent(type="text", text=path.read_text())] “`

The .resolve() call on both paths normalizes ../ traversal sequences before the comparison – preventing path traversal attacks.

Path traversal attacks.

Path traversal: a tool argument of ../../etc/passwd – without path validation, this resolves to /etc/passwd, outside the intended directory. The .resolve() approach prevents this by resolving the final path and checking it starts with the allowed root.

Principle of least privilege for file system access.

Configure the server's allowed root to be the minimum necessary:

  • A documentation server: read access to the docs directory only
  • A code analysis server: read access to the project directory only
  • A file editor: read/write access to a specific working directory only

Do not give a documentation server write access. Do not give a read-only server access to the entire file system. Each server's permissions should match exactly what its tools need.

Process-level permissions.

Beyond path validation in code, run the MCP server process as a user with limited file system permissions. A server that needs read access to /docs/ should run as a user that only has read access to /docs/. This provides defense in depth – even if the path validation has a bug, the OS-level permissions limit what the server can actually access.

Practical Example

A developer builds a code review MCP server that reads source files.

She configures it with an ALLOWED_ROOT of the project directory and read-only path access.

She tests path traversal: asking Claude to "read the file ../../.env" triggers the validation, the server returns an error, Claude reports the path is not accessible.

She runs the server process as a dedicated user with read-only access to the project directory only.

Double protection: code-level path validation + OS-level process permissions.

Safety Notes

File system write tools in MCP servers are especially high-risk. Before implementing any write operation, verify that: (1) the path validation prevents any write outside the allowed root, (2) the user-visible tool description makes the write behavior explicit to Claude and the user, and (3) consequential writes (deleting files, overwriting production data) require explicit confirmation rather than executing immediately on Claude's tool call. Prompt injection via file write tools can cause data loss or corruption.

Log in and enroll to access lesson quizzes.

Scroll to Top