How to Detect Filesystem Model Context Protocol Tool Calls That Reach Outside Configured Roots

How roots work and where enforcement can fail

In MCP, roots describe the directories a filesystem server is expected to operate within. They are a statement of intended scope. A root does not restrict anything on its own. The boundary holds only if the code that handles each read, write or directory operation actually checks the target against it.

That is why the boundary should be verified rather than assumed from server configuration. MCP servers run with delegated user permissions and often take part in chained tool calls, so a single flaw in path handling can have wide reach. CVE-2025-53109 is a concrete example: versions of the MCP Filesystem server before 0.6.4 or 2025.7.01 could allow access to unintended files through symlinks within allowed directories. A path can look in scope as a string and still resolve somewhere else.

Tool annotations do not close this gap. They are hints, not enforcement, and monitoring tool definitions reveals metadata changes, not changed behavior behind an unchanged definition. Root decisions need to be made on the actual call and its actual arguments.

Signals that a call reaches outside its roots

Start with the resolved path, because every other signal is a way of changing it. A call is out of scope when the canonical target, after all resolution, is not contained in any approved root.

Traversal sequences such as parent-directory segments are the obvious signal, but they are rarely the only one. Encoding variants can hide them: percent-encoded separators, double encoding, alternate Unicode forms and embedded null characters. Relative paths depend on a working directory that the agent may not control. Symlinks inside a root can point outside it, so a lexical check passes while the real target fails. On Windows, drive letters, UNC paths and backslash separators add forms that a POSIX-minded check may miss. Case-insensitive filesystems mean two spellings can name the same file.

Prefix-matching errors deserve explicit attention. A string prefix test treats a sibling directory whose name merely begins with the root's name as inside the root. Compare whole path components, never raw string prefixes. For operations with two paths, such as move or copy, evaluate both source and destination. For writes to files that do not yet exist, resolve the parent directory.

Telemetry fields that make a call reconstructable

Server-side logs alone rarely carry enough context to reconstruct an out-of-scope attempt. OWASP guidance calls for logging every tool invocation with full parameters, user context and timestamps, feeding those records into a SIEM, and alerting on unusual patterns such as new tools being called or abnormal call frequency.

For filesystem calls, that translates into a minimum record: timestamp, caller identity, tool name, requested path, resolved path, matched root (or none), the decision and its reason, and the server and version handling the call. The pair of requested and resolved paths is the most useful detail, because a divergence between them is itself a detection signal. Keep the records in append-only storage, consistent with OWASP's recommendation of immutable audit trails.

Full parameters can contain credentials, file contents or environment variables that agents pass without regard to data classification. Decide in policy what is redacted before storage, and apply that rule consistently so evidence stays useful without becoming a new exposure.

Detection versus enforcement at the tool-call layer

Detection after the fact tells you a file was read. Enforcement in the execution path decides whether it is read. If the check runs only in server logs or in later review, an out-of-root call has already completed by the time anyone sees it. Evaluating arguments before execution is consistent with OWASP advice to validate tool arguments and apply least privilege to what an agent can invoke.

There is a design choice between checking inside each server and checking at the call layer in front of all of them. A server-side check depends on every server implementing it correctly, and CVE-2025-53109 shows that implementations can fail. A call-layer check applies one policy across servers, though it must resolve paths the way the server will, or it risks disagreeing with the server about the target.

Trussed enforces policy on tool calls and MCP servers in the execution path, with allow, redact and block outcomes enforced at runtime, not reviewed after the fact. Each enforcement decision generates audit-ready evidence, mapped to frameworks including NIST. A team can run the same logic with its own components, but the requirement is the same: the decision and the record come from one point.