MCP roots and resource boundaries

Roots describe client-visible workspace boundaries; server-side filesystem access must still be enforced by the actual host.

01 / The operating case

What changes in a real workflow?

A coding server receives a root for one repository but also runs with permission to read adjacent credential files.

Trace the authority boundary
  1. 01Client / task
  2. 02MCP server
  3. 03Tool call + arguments
  4. 04Downstream effect

02 / Decision contract

What the executor must check

Constrain operating-system filesystem permissions and normalize every requested path, including symlinks, before reading or writing.

InputPrincipal · task · action · target
DecisionGrant ancestry · policy · current state
ResultEnforce · record · verify outcome

03 / Failure and evidence

What goes wrong, and what can be proven?

Failure mode

A root hint is mistaken for a sandbox and a path escape reaches an unrelated directory.

Evidence to retain

Record approved root, canonical resolved path, operation and filesystem denial.

04 / Canonical scope

Why this reference stands alone

Server isolation covers process privilege broadly; this page owns path and resource boundary checks.

Protocol or attack trace

Root escape test

Sequence

Client exposes root /work/repo; server requests /work/repo/link/secrets where link resolves outside root.

Negative test

Resolve symlinks and canonical path before access; deny despite lexical prefix match.

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation