An MCP (Model Context Protocol) server developer is building a filesystem tool server. They notice that Claude, when acting as an MCP client, occasionally calls the write_file tool with a path like ../../etc/passwd — a path traversal attempt that would write outside the intended sandbox directory. The MCP server naively trusts the path provided by Claude. What is the correct security control in the MCP server implementation?

Path traversal attacks can use many obfuscated forms: ../, %2e%2e/, symlinks, null bytes, and other encodings. A simple string filter is bypassable by encoding variations. The correct defense is to canonicalize the path to its absolute real form (resolving .., symlinks, and encodings) using the OS's own path resolution, then reject the call if the canonical path does not start with the allowed base directory prefix, regardless of what string patterns appear in the raw path. This is defense-in-depth that works regardless of how the traversal is encoded. In MCP architecture, the server must treat all tool inputs as potentially adversarial — whether from direct injection or model errors. The simple string filter fails because ....// or URL encoding bypasses ../ string matching. API key validation verifies the caller is Claude, not that Claude's inputs are safe — Claude itself may have received injected content from an external source. Prompt instructions are not a security control; they can be overridden by prompt injection or model behavior variability.